Jump to content

austinpop

Premium
  • Content Count

    4361
  • Joined

  • Last visited

About austinpop

  • Rank
    Credo In Aures

Personal Information

  • Location
    Austin, TX

Recent Profile Visitors

22189 profile views

Bookmarks

  1. Network behavior with SL large buffers
    AudioLinux and NUC Troubleshooting and Tuning

    So I have been scratching my head about this SQ boost running squeezelite with large input stream (from LMS) and output stream (to USB device, i.e. DAC) buffers. After all, think about these points:

    1. In ramroot mode, the OS (i.e. the / filesystem) is loaded into a RAM disk (/dev/zram0)
    2. The squeezelite executable (the exe for you Windows types) is now living on the RAM disk at location /usr/bin/squeezelite, i.e. also on zram0
    3. When you "run" it, you create a new process, with its own virtual address space, and the loader starts loading pages from the file... which is already in memory!
    4. Once you start streaming the music, it looks like squeezelite has an input_stream buffer (receive from LMS/Roon) and an output_stream buffer (send to USB device, i.e. DAC/DDC)
    5. These buffers are also in memory. All that -b does is preallocate a large buffer from the get go.

    So what is different about the default case (no -b) with the large buffer case? Why does the latter sound better? In both cases, all I/O is from memory already, or from the network. So I did some monitoring.

     

    I ran a 24/96 track, that is 11.5 mins long. File size is 188MB. With FLAC compression, it's effective bit rate as shown by MP3tag is:

     

    Screen Shot 2018-12-08 at 2.56.28 PM.png  2274 kbps

     

     

     

    I streamed this file in 3 configs, with the server running Roon Core:

    1. RoonBridge
    2. squeezelite default
    3. squeezelite -b 1572864:1572864

    Between each run, I cleared the filesystem cache by running: echo 3 > /proc/sys/vm/drop_caches

     

    I used the command iftop -i eno1 to look at network traffic. The 3 columns show the average over the last 2, 10, and 40 secs respectively. I'm showing the numbers for the bottom of the screen, which are the aggregates for the entire machine on the eno1 (ethernet) interface. The first row is outbound, the second is inbound. 

     

    RoonBridge

     

    Screen Shot 2018-12-08 at 12.35.10 PM.png

     

    As you can see, Roon is consistently streaming the file from the Core on the server to RoonBridge on this endpoint at a little over 4Mbps. Actually, it is most likely the RAATServer instances on each side that are transferring data. I wouldn't worry about precision - I don't know what the overhead of the iftop tool is, but you can see it's greater than the effective bitrate of the audio, so at this rate, Roon always ensures that the buffer feeding the USB interface is never empty. Which from a flow control and efficiency perspective, makes perfect sense. At this rate, the transfer should still complete well before the song, but I didn't run long enough to check.

     

    Default buffers (no -b flag)

     

    Screen Shot 2018-12-08 at 12.31.40 PM.png

     

    Ditto for the default squuezelite case. Yeah the rate is a little lower, but effectively we're just streaming fast enough to avoid underrunning the output buffer. Again, seems logical.

     

    Large buffers (-b 1572864:1572864)

     

    Here's were it gets interesting. For the first few seconds, it's firehose mode on the network! Look at the 2 sec average (1st column) because this mode doesn't (or dudn't if you're Texan) last very long. Essentially we're sending the whole file over.

    Screen Shot 2018-12-08 at 12.33.02 PM.png

     

    After that, it's crickets (quiet) on the network. Again - focus on the 2 and 10s averages, as I didn't wait long enough for the 40s average to clear.

    Screen Shot 2018-12-08 at 12.33.29 PM.png

     

    Conclusions?

     

    Well, there's still no explanation. Why does "large buffers" sound better? In all these cases, everything (OS, executables, runtime input and output buffers) is in memory. So what gives?

     

    Well, one answer - from the user/listener perspective is: who cares!? If it sounds good, use it and enjoy!

     

    From the designer's perspective, it's a head scratcher. Could it be that the things listed below result in lower "noise?"

    • preloading the file in the first few seconds of playback quiesces the IRQ rate and IRQ processing during the rest of the track?
    • by preloading in a big gulp from the network, squeezelite is making system calls (socket send(), recv(), select() etc) at a much lower rate?
    • Even without large buffers, this workload runs at an astonishingly low CPU util. Here's one example in the RoonBridge case:
      Screen Shot 2018-12-08 at 5.38.01 PM.png
      and this is in the large buffer case:
      image.png

    Ultimately I didn't find anything I can point to, that would suggest better SQ. Clearly, something about the system operation in the large buffer case sounds better.

     


  2. JS on upstream noise
    Sonore opticalRendu

    The understanding of "isolation" in digital audio has been my passion for at least 10 years. There is a LOT of misunderstanding on the subject floating around in audio circles.  Here is a quick summary of my current understanding and how the current products fit in with this.

     

    There seems to be TWO independent mechanisms involved: leakage current and clock phase noise. Various amounts of these two exist in any system. Different "isolation" technologies out there address one or the other, but very rarely both at the same time.  Some technologies that attenuate one actually increase the other. Thus the massively confusing information out there.

     

    Leakage current is a property of power supplies. It is the leakage of AC mains frequency (50/60 Hz) into the DC output. It is usually common mode (ie exists on BOTH the + and - wires at the same time, this makes it a bit difficult to see. There seems to be two different types, one that comes from linear supplies and is fairly easy to block, and an additional type that comes from SMPS and is MUCH harder to block. An SMPS contains BOTH types. They are BOTH line frequency.

     

    Unfortunately in our modern times where essentially all computer equipment is powered by SMPS we have to deal with this situation of both leakage types coming down cables from our computer equipment. There are many devices on the market (I have designed some of them) for both USB and Ethernet, most can deal with the type from linear supplies but only a few can deal with the type from SMPS.

     

    Optical connections (when the power supplies are completely isolated from each other) CAN completely block all forms of leakage, it is extremely effective. Optical takes care of leakage, but does not deal with the second mechanism.

     

    Clock phase noise

     

    Phase noise is a frequency measurement of "jitter", yes that term that is so completely mis-understood in audio circles that I'm not going to use it. Phase noise is a way to look at the frequency spectrum of jitter, the reason to use it is that there seems to be fairly decent correlation to sound quality. Note this has nothing to do with "pico seconds" or "femto seconds". Forget those terms, they do not directly have meaning in audio, what matters is the phase noise. Ynfortunately phase noise is shown on a graph, not a single number, so it is much harder to directly compare units. This subject is HUGE and I'm not going to go into any more detail here.

     

    Different oscillators (the infamous "clocks" that get talked about) can have radically different phase noise. The level of phase noise that is very good for digital audio is very difficult to achieve and costs money. The corollary is that the cheap clocks used in most computer equipment (including network equipment) produce phase noise that is very bad for digital audio.

     

    The important thing to understand is that ALL digital signals carry the "fingerprint" of the clock used to produce them. When a signal coming from a box with cheap clocks comes into a box (via Ethernet or USB etc) with a much better clock, the higher level of phase noise carried on the data signal can contaminate the phase noise of the "good" clock in the second box. Exactly how this happens is complicated, I've written about this in detail if you want to look it up and see what is going on.

     

    The contamination is not complete, every time the signal gets "reclocked" by a much better clock the resulting signal carries an attenuated version of the first clock layered on top of the fingerprint of the second clock. The word "reclocked" just means the signal is regenerated by a circuit fed a different clock. It may be a better or a worse clock, reclocking doesn't always make things better!

     

    As an example if you start with an Ethernet signal coming out of a cheap switch, the clock fingerprint is going to be pretty bad. If this goes into a circuit with a VERY good clock, the signal coming out contains a reduced fingerprint from the first clock layered on top of the good clock. If you feed THIS signal into another circuit with a very good clock, the fingerprint from the original clock gets reduced even further. But if you feed this signal into a box with a bad clock, you are back to a signal with a bad fingerprint.

     

    The summary is that stringing together devices with GOOD clocking can dramatically attenuate the results of an upstream bad clock.

     

    The latest devices form Sonore take on BOTH of these mechanisms that effect sound: optical for blocking leakage and multiple reclocking with very good clocks. The optical part should be obvious. A side benefit of the optical circuit is that is completely regenerates the signal with a VERY low phase noise clock, this is a one step reclocking. It attenuates effects from upstream circuits but does not completely get rid of them. This is where the opticalModule comes into play, if you put an opticalModule in the path to the opticalRendu you are adding another reclocking with VERY good clocking. The result is a very large attenuation of upstream effects. It's not completely zero, but it is close.

     

    The fact that the opticalRendu is a one stage reclocking (which leaves some effects from upstage circuits) is why changing switches etc can still make a difference. Adding an OpticalModule between the switch and opticalRendu reduces that down to vanishingly small differences.

     

    So an optical module by itself adds both leakage elimination and significant clock effects attenuation. TWO optical modules in series give you the two level reclocking .

     

    An opticalRendu still has some significant advantages over say an ultraRendu fed by a single opticalModule, the circuitry inside the opticalRendu has been improved significantly over the ultraRendu. (it uses new parts that did not exist when the ultraRendu was designed). In addition the opticalRendu has the reclocking taking place a couple millimeters away from the processor which cuts out the effects of a couple connectors, transformers and cable. The result is the opticalRendu has some significant advantages.

     

    An opticalModule feeding an ultraRendu does significantly improve it, but not as much as an opticalRendu. So you can start with an opticalModule, then when you can afford it add an opticalRendu, also fed by the opticalModule and get a BIG improvement.

     

    I hope this gives a little clarity to the situation.

     

    John S.

     

     

     

     


  3. System state April 2019
    A novel way to massively improve the SQ of computer audio streaming
    7 hours ago, seeteeyou said:

    Thread gone quiet lately?

     

    6 hours ago, lmitche said:

    We are busy listening to music on our absolutely awesome NUC/Audiolinux systems. The recent software upgrades are fantastic! SQ exceeds my best expectations.

     

    While I have a different configuration, I agree with Larry - we're at a point now where most of us are happy with the excellent SQ we are enjoying. Here is what my current system looks like:

     

    Audio-topology-qx5.png

     

    I am alternating between AL and Euphony as the OS for the Server and the Endpoint. With the recent changes, AL has almost, but not quite, caught up in SQ with Euphony. I own both, so continue to monitor improvements and can easily switch back and forth as needed.

     

    One very interesting finding, which I will expand on in an upcoming review, is that with the improvements in my network chain with the bridged JCAT Net Femto card and the SOtM switch, the SQ through the Ethernet interface of the DAC is now very close to the SQ through the USB input. This is true across the Ethernet DACs  at my disposal, the Ayre QX-8, the QX-5, and my current DAC under review. The USB path still wins out, but by a smaller margin than ever before. Of course, with USB you can also play with alternated endpoints like Squeezelite, buffers, etc. Still, this suggests that there may be an alternate path to great SQ using just reclocking switches and Ethernet DACs. This has the benefit of being a low-spaghetti solution.

     

    I am currently trying to see if I can systematically force my entire chain to 100Mbps. Like many here, I am finding 100Mbps to sound better than 1Gbps.

     

    Eric @limniscate and I rediscovered the advantage of 100Mbps in a recent listening session on his system, which he recently upgraded with the fabulous Maggie 20.7's. In addition to enjoying the music, we wanted to test the effect of the SOtM switch powered by an SR7 DR rail, on the Ethernet input of the DAC under review. We set up the USB chain as the baseline:

    • Wall (router) > Zenith SE > tX-USBultra (SR7 DR) > DAC

    Note - we used SOtM dCBL-Cat7 ethernet cables and Lush USB cables for all experiments.

     

    We next tried the SOtM switch upstream of the SE:

    • Wall (router) > SOtM switch (SR7 DR) >  Zenith SE > tX-USBultra (SR7 DR) > DAC

    Oddly enough, this sounded worse. Upon investigation, we found from the lights on the SE's Ethernet port that in the baseline case, when connecting directly to his router, his SE was negotiating down to a rate of 100Mbps. With the switch in the path, the switch was auto-negotiating 1Gbps both to the router, and to the SE. Net net (pun intended!) - the SE in the baseline case was running at 100Mbps and sounding better.

     

    Next, we tried a direct path from the SE to the DAC via Ethernet:

    • Wall (router) > Zenith SE (bridged) > (via Ethernet) > DAC

    This sounded significantly worse than the USB path. Soundstage depth was lacking, and the overall presentation was flat and boring. Since the DAC only supports 100Mbps, in this case both ports on the SE were at 100Mbps.

     

    Then we added the SOtM switch between the SE and the DAC:

    • Wall (router) > Zenith SE > SOtM switch (SR7 DR) > DAC

    In this case, the speed negotiated by the ports were:

    • SE LAN: 100Mbps (to router)
    • SE streamer: 1Gbps (to switch)
    • Ethernet DAC: 100Mbps (to switch)

    This was by far the most dramatic improvement I've ever heard from an Ethernet switch. Comparing this path to the baseline USB path, the USB path still won. The gap was small running Roon as the endpoint, but widened again when using squeezelite (the so-called experimental option on the Zenith SE).

     

    As I try to force 100Mbps end to end, I find myself wishing for a 100Mbps/1Gbps config option on the SOtM switch. While a case can be made that the speed should properly be configured on the nodes, many OSes like InnuOS and Euphony don't allow any way to override the auto-negotiate setting of the Ethernet interface. Even on AL it is a bit fiddly, and best left to the Linux experts.

     

    As far as what is next on my system - not much! I am finally very happy with my digital path upstream of my DAC. The next big thing for me is power supply improvements. I am eagerly awaiting (and awaiting, and awaiting) my 3-rail SR7 DRXL, which will allow me to run my NUC, tX-USBultra, and SOtM switch on SR7 rails. That should be it for me until I can try the Uptone EtherRegen switch against the SOtM and TLS switches.

     

    I so want to be DONE. I say that, but knowing myself, tweaking will likely continue!


  4. i7 BIOS settings
    AudioLinux and NUC Troubleshooting and Tuning

    Someone asked me to share my NUC7i7DNBE BIOS settings via PM, but I'm posting here, just in case I got overzealous, and need to turn something back on. OR - anything I missed.

     

    Again, this is specific to the above model, although I'm sure very similar to other NUC7i7DN models.

     

    My NUC7i7DNBE BIOS settings

    • Power > Primary Power Settings > Low Power Enabled

    • Security > Security Features >

      • Intel Trusted Execution Technology: off

      • Intel Virtualization : currently on, probably need to turn off

      • Intel VT-d : currently on, probably need to turn off

    • Performance > Processor

      • Hyperthreading: off

      • Turbo boost: off

      • Realtime performance tuning: off

      • Silicon debug: off

    • Devices

      • SATA: off

      • PCI M.2: off

      • HDMI Audio: off

      • TPM 2.0 Presence: off

      • Serial port: off

    • Boot

      • Secure boot: off

    Please share any differences or suggestions.

     


  5. JS on ATX
    cheap/chinese LPSU's - minefield?

    Here is some (maybe unwelcome) details on switching supplies etc.

     

    First off there are two very different types of "switching things": The ones that plug into a wall (ie the input is AC mains, 120/230V AC, 50/60Hz), and ones you find on a board which take DC in (say 12V) and output DC (usually lower voltage).

     

    These behave quite differently and I think it is important to not ascribe the same properties to both.

     

    The AC line input ones I'm going to call "SMPS", the other I'm going to call "switching DC/DC converter", you can also call this a switching regulator.

     

    An SMPS takes the raw AC line and switches it, breaks it up into tiny time slices, since this is slicing the AC line, it the amplitude of these slices is still going up and down at line frequency.  The frequency of the slices is somewhere between 30KHz and 100KHz. A lot of old ones worked at 30KHz but modern ones seem to like 60KHz. On the other side of the transformer there is a diode bridge, and caps and some circuit that measures the voltage.The output of the voltage sensor is fed back to the circuit that slices the line voltage which modulates the slices so that on the other side you get pretty flat DC. So you don't need the giant capacitor banks to smooth out the line AC, as the line voltage goes up, less power is sent to the transformer, and as the line goes lower more power goes to the transformer.

     

    So why even bother doing all this? Primarily is the reduction in size, weight and cost of the transformer, and also the vast reduction in capacitors after the diode bridge. Line transformers have to be large heavy and expensive to work at 50/60 Hz. The transformers that work at the high switching frequencies are much smaller, cheaper and lighter weight.

     

    The switching DC/DC converter takes DC in, slices it up and feeds an inductor with the pulses (note: NOT a transformer). These frequently run in the 400KHz to 1MHz range. Again a sensor looks at the output voltage and adjusts the slices to get the output voltage required.

     

    Again why do this? Primarily because switching DC/DC converters conserve POWER and linear regulators conserve CURRENT. So waht does this mean? Lets look at a linear regulator, lets say the load is pulling 1 amp, this means the input current is also 1A. If you have a large voltage across the regulator you have to dissipate a lot of power. If your input is 12V and your output is 1V at 1A, the input is 12V at 1A, so 12W in and 1W out, that means the regulator has to burn up 11W!! The switching regulator is constant POWER, the input power is the same as the output power, thus for above  the input is only 1W instead of 12W, the current is 1/12 W. Non of these circuits are perfect so there is SOME power lost in the switching regulator, usually not very much.

     

    The "noise" that comes out of an LPS and an SMPS are very different. An LPS with a decent regulator has broadband noise usually measured in micro-volts (uV), the best ones are around 1uV, the worst can get up to 60uV. If you look at this on a scope you usually see a flat line, you have to increase the gain dramatically to see this noise. An SMPS (and DC/DC converter) have ripple at the switching frequency, usually measured in milli-volts (mV), this is much easier to see on a scope, but is very hard to see using normal settings. Say you have a scope set to measure 12V,  you will see a flat line, 20mV won't even show up on that line. You have to go to AC coupling and turn the gain up. Not as much as with a LPS, but still a lot more than a normal setting.

     

    In most circumstances either of these noise levels is not going to make any difference, since almost everything you are powering with an external box, will have their own regulators, THOSE are what really matter.

     

    Now there are two other aspects of a power supply that DO seem to have an affect on what is powered, they are a lot harder to understand than noise, and nobody ever puts measurements for these in a spec sheet so there is no way to compare. These two things are output impedance and leakage current.

     

    The output impedance is what the voltage does when a change in load current happens. This is particularly important for quick changes in load current. Slow gradual changes can easily be handled by the PS, but quick changes cause the output voltage to change, frequently it will then slowly recover to the original value. This is most important for devices like computers which have large, quick changes in current draw. In many cases the regulators in the device can't handle this voltage change either and it winds up getting to the circuitry.

     

    There is no generalization about this with LPS VS SMPS. Both types have some that have very low output impedance (this is good) and some have high output impedance. Since nobody measures this or puts it in spec sheets there is no way to know. The only correlation seems to be that the specialty, expensive LPS tend to have very low output impedance. I have done a bunch of measuring of PS and have found some SMPS that beat a lot of the less expensive LPS. But you can't tell which they are, they don't look any different, they don't cost more, they just are better. BTW some of the SMPS that are touted as being low noise have horrible output impedance.

     

    The other property is leakage current. I'm not going to go into details on this, I have written tons of posts on this. For this there is a BIG difference between SMPS and LPS. The both have leakage, but the type that comes from an SMPS seems to be much more damaging to digital audio than what you get out of an LPS. The SMPS DO vary a fair amount, again hard to tell which are the lower ones. The largest amount of leakage I have ever measured is from an SMPS that talks about how low its noise is.

     

    A switching DC/DC converter does not generate leakage, it does not STOP leakage, but it does not generate its own. If a switching DC/DC converter is fed from an SMPS, whatever that SMPS produces is what will be on the output of the converter.

     

    One thing about SMPS that is talked about a lot is noise from the SMPS being "backwashed" into the AC mains. This used to happen many years ago, but modern SMPS don't seem to have this issue at all. Because this is something people can understand I think this gets the credit when I think in most cases the real culprit is the leakage current.

     

    So what does all this mean for a computer? The primary effect from powering a computer from an LPS seems to be the reduction in leakage current, NOT ripple on the output of the supply. There are fairly inexpensive ways to deal with leakage current, so in most cases using LPS ATX supply is mostly wasting money.

     

    If you have a computer directly driving a USB DAC there are some waysto prevent most of the leakage from getting through. But in my opinion a better way is to use a renderer powered from an LPS. In this case all you have to do is prevent the leakage coming over the Ethernet connection from getting onto the USB connection. Fortunately this is very easy to achieve and quite inexpensive.

     

    So the upshot is that you can achieve most of what advantage there is in using an ATX LPS in other ways for a LOT less money.

     

    John S.


  6. AL boot from Optane SSD
    AudioLinux and NUC Troubleshooting and Tuning

    I was helping out @bobfa to get his Roon Server to boot off of an Optane NVMe SSD. Since he was able to get it done successfully, the side benefit was my notes, which resulted in a HOW-TO Guide, included below.

     

    Please note: 

    1. this is for people comfortable with operating on the Linux command line, and editing files, etc - i.e. power users. I've tried to make it fairly cook-book-y, but use at your own peril. I cannot provide tech support! This assumes you've already installed the Optane stick into the M.2 NVMe slot of your box.
    2. I don't claim this is the best or most optimal way to achieve this outcome. @hifi25nl please advise if there are any easier ways.

     

    How to setup a Roon Server to boot from and persist data to an Optane SSD

     

    by @austinpop


    Phase 1: Clone the USB boot stick onto the Optane SSD

    • Boot from the USB stick (do not load into RAM). Leave stick in the box.
    • su to root privileges
    • ramroot remove
    • Run lsblk to find the device name of the stick and SSD on your system. Example:

      NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
      sda           8:0    1 59.5G  0 disk
      ├─sda1        8:1    1  488M  0 part /boot
      └─sda2        8:2    1  5.4G  0 part /
      nvme0n1     259:0    0 27.3G  0 disk


      Now you know the USB stick is /dev/sda
      Similarly, you know the SSD is /dev/nvme0n1
    • Run parted
      • Should default to USB stick. Just to be sure:
      • select /dev/sda
      • print to look at start and end sizes for / and /boot on the USB drive. Example output:
        (parted) print
        Model: SanDisk Ultra USB 3.0 (scsi)
        Disk /dev/sda: 30.8GB
        Sector size (logical/physical): 512B/512B
        Partition Table: gpt
        Disk Flags:
        Number  Start End     Size File system  Name Flags
        1      1049kB  513MB   512MB   fat32           boot, legacy_boot, esp
        2      513MB   6280MB  5767MB  ext4


        From the example above:
        /boot start is 1049KB and end is 513MB
        / start is 513MB and end is 6280MB
      • select /dev/nvme0n1
      • print to look at partitions. If this is a fresh SSD, there will be no partitions, just free space
      • If there are existing partitions, and you want to start over, remove all existing partitions using:
        • rm 1
        • rm 2
        • etc.
      • mklabel gpt
      • mkpart to enter interactive prompts to create a partition. First, the boot partition
        • Partition name: boot
        • Filesystem type: fat32
        • Start: 1049kb
        • End: 513mb
        • set 1 boot on
        • set 1 legacy on
        • set 1 esp on
      • print - you should now see the boot partition listed.
      • mkpart - now the / (or root) partition
        • Partition name: audiolinux
        • Filesystem type: ext4
        • Start: 513mb
        • End: 6280mb
      • print - you’ll now see 2 partitions listed
      • mkpart - finally, create a data partition for the rest of the SSD
        • Partition name: data
        • Filesystem type: ext4
        • Start: 6280mb
        • End: 100%
      • print - you’ll now see 3 partitions listed, consuming the whole SSD
      • quit
    • Now on command line, clone the / and /boot partitions from the stick to the SSD.
      • dd if=/dev/sda1 of=/dev/nvme0n1p1 bs=64k conv=noerror,sync status=progress
      • dd if=/dev/sda2 of=/dev/nvme0n1p2 bs=64k conv=noerror,sync status=progress
    • Run blkid . Example output:

      /dev/nvme0n1p1: UUID="9913-922E" TYPE="vfat" PARTUUID="24749f11-45ea-4c47-bad8-aa20da9832a0"
      /dev/nvme0n1p2: LABEL="audiolinux_mini" UUID="63e1e2ac-109d-46c2-80a6-bdc4b5e390aa" TYPE="ext4" PARTUUID="adca1e52-6f59-48e9-86d7-dbb2604b9071"
      /dev/nvme0n1p3: UUID="8d2ad706-b716-47d8-a164-68a351dbbf8b" TYPE="ext4" PARTUUID="48306461-aae1-41be-b4e9-44fcc2d2f595"
      /dev/nvme0n1: PTUUID="765ab813-3bec-4807-b824-b0bf5cd5af26" PTTYPE="gpt"
      /dev/sda1: UUID="9913-922E" TYPE="vfat" PARTUUID="52959088-5904-415f-b64c-14bd755c42f5"
      /dev/sda2: LABEL="audiolinux_mini" UUID="63e1e2ac-109d-46c2-80a6-bdc4b5e390aa" TYPE="ext4" PARTUUID="166ad16d-098d-4453-ab07-7c5255b4d451"

       
    • note that because we cloned the sda1 and sda2 contents to nvme0n1p1 and nvme0n1p2, these partitions now have the same UUID (in blue), but different PARTUUID (in green and red).

    • Note (copy) the PARTUUID of the /dev/nvme0n1p2 partition. This is the / or root partition on the Optane SSD. We need to fix the PARTUUID in the boot loader entries.

    • mount /dev/nvme0n1p1 /media/linux1 - Let’s mount the boot partition temporarily to fix loader entries

    • cd /media/linux1/loader/entries

    • Edit all 6 of the *.conf files in this directory

      • Change the PARTUUID from 166ad16d-098d-4453-ab07-7c5255b4d451 to the PARTUUID noted above. In this example, it would be adca1e52-6f59-48e9-86d7-dbb2604b9071

    • Finally, create a filesystem on the data partition
      • mkfs.ext4 /dev/nvme0n1p3
    • sudo reboot, then remove USB stick


    Phase 2: Boot from Optane SSD and configure Roon data to be persistent

    • During reboot, go into BIOS to put the NVMe Optane SSD as the first boot device
    • At the prompt, do NOT boot into ramroot mode - just this time, because we want to edit the /etc/fstab file
    • Once you are booted up...
    • su for root privileges
    • systemctl stop roonserver - make sure Roon is not running
    • mount /dev/nvme0n1p3 /media/linux1 - Let’s mount the data partition temporarily to copy over existing Roon data
    • cp -rp /var/roon/* /media/linux1
    • umount /media/linux1
    • rm -rf /var/roon/*
    • blkid to get UUID of the /dev/nvme0n1p3 partition
      Example:
    • /dev/nvme0n1p3: UUID="8d2ad706-b716-47d8-a164-68a351dbbf8b" TYPE="ext4" PARTUUID="48306461-aae1-41be-b4e9-44fcc2d2f595"
    • Edit /etc/fstab and add the line (change UUID to yours):
      • UUID=8d2ad706-b716-47d8-a164-68a351dbbf8b /var/roon ext4 nofail,noatime,rw 0  2
    • Then mount /var/roon  Now the contents of /var/roon live on the Optane data partition, and are persistent, even during ramroot.
    • Now reboot, and this time, allow boot into RAM.
    • Start Roon Server from the menu, go forth and prosper!

    Final notes:

    • This configures the Roon database to be persistent, so if you make library changes, like adding albums, or editing etc, there is no need to do a ramsave
    • The Roon executables, however, continue to live in /opt/RoonServer/ which is still in the root partition and gets loaded into rmroot. So if you do a Roon update, those changes will occur in RAM, and will not persist unless you do a ramsave after the update is finished.
    • While it is possible to put the Roon executables on the SSD, I have found SQ to be better if the executables reside in RAM. YMMV.

  7. AL Tips and Tricks
    AudioLinux and NUC Troubleshooting and Tuning

    Random Tips and Tricks

     

    Here are some random tips and tricks for AL headless. Since these are for system changes, don't run this in ramroot mode. ssh into the system, and run as root. Finally, make sure the USB stick is inserted. Been burned by this before! 9_9

    • First, disable ramroot
      • ramroot remove
         
    • Fix the time zone:

      • timedatectl set-timezone America/Chicago (pick yours - look in directory /usr/share/zoneinfo)
         

    • Start NTP daemon (to keep the system time in sync)

      • Edit the file: /etc/systemd/timesyncd.conf

        • Change previous [Time} stanza to:
          [Time]
          NTP=0.arch.pool.ntp.org 1.arch.pool.ntp.org 2.arch.pool.ntp.org 3.arch.pool.ntp.org

          FallbackNTP=0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org 3.pool.ntp.org

      • Run timedatectl set-ntp true

      • It may take a few minutes for the sync to occur, after which your system date and time will be accurate.
         

    • Set hostname

      • hostnamectl set-hostname <NAME> 
         

    • List detailed system HW info

      • (pop out of root to run yaourt)

      • yaourt -S inxi

      • Once installed, run: inxi -Fc0
         

    • Reducing the size of the RAM root partition
      You might want to do this for a couple of reasons - to reduce boot time, and to increase free memory - for example, to run squeezelite with larger -b buffer. As you do each step, monitor the used space on the / filesystem with command df.

      • Uninstall unwanted packages

        • List all installed packages: pacman -Qe

        • For each package you want to uninstall, e.g. in my case, I don't use HQPlayer.

          • pacman -R hqplayer-network-audio-daemon hqplayer-embedded

          • Warning: don't go nuts here. Most of the packages are there so you can build any new packages you may want to install. I would just focus on the audio packages like Roon and HQPlayer.

      • Delete pacman temp files

        • clean

      • Clean up journal

        • Check current journal size: journalctl --disk-usage

        • Pick a max size you’re comfortable with, say 32M

        • Trim journal down to that size: journalctl --vacuum-size=32M

        • Set threshold for future growth:

          • Edit /etc/systemd/journald.conf

          • Uncomment (remove #) and change line to SystemMaxUse=32M

      • Delete core dumps

        • rm -rf /var/lib/systemd/coredump/core*

        • rm -rf /run/systemd/coredump/core*
           

    • Once you're done making changes:

      • ramroot -F enable
         

    • Monitor free memory at run time

      • Monitor memory in use with free and/or top

      • After RoonBridge has been running for a long time, when you run free, you'll notice that the size of the FS cache - see the buff/cache column in the output of free - has grown quite large. If you want to reclaim this space and make it free again, say to run squeezelite with large -b values, run:

        • echo 3 > /proc/sys/vm/drop_caches


  8. New SACD extract
    SACD Ripping using an Oppo or Pioneer? Yes, it's true!
    On 10/8/2018 at 6:58 PM, servoyguru said:

    Is there another binary specifically compiled on a Mac (& with latest bug fixes) available ...

     

    Hi, here are three new compilations of SACD_EXTRACT based on setmind's latest sources for the most common OSes.

    For everyone's convenience, I have included his new SACDExtractGUI.

     

    SACDExtractGUI v0.1-5-g97d05f95
    
    sacd_extract version [email protected]

     

    Linux x64 package: [email protected]_git_2018-10-08.zip

    Quote

    MD5:        2957A5E1E161D0D1CB3D848992CA7C66
    SHA256:        04FB009F4933B14B93C9B0694235A78C9C8A9F0BD1827F53E79002152939C340

     

    macOS x64 package: [email protected]_git_2018-10-08.zip

    Quote

    MD5:        E0AF480A4B3D08D76F24441B4397CA05
    SHA256:        AAC5BFE99A96DEE328FBAFED928A60A8A35672C3EAD5567CBF7BAF4BDE8BDE6B

     

    Windows x64 package: [email protected]_git_2018-10-08.zip

    Quote

    MD5:        B35F2AD43D149F957D9567561AF4D731
    SHA256:        011C1F03C4A6380B98FAD2C86F7ED3C577C25F448C6DFA7D53F5870EB2952080

     

     

    Happy ripping & USE THEM AT YOUR OWN RISK!


  9. Charley’s take on DAC design
    HOW DOES A PERFECT DAC ANALOG SIGNAL LOOK DIFFERENT THAN A CHEAP DAC
    6 hours ago, mansr said:

    What makes the Pono Player so special? I gather it uses your interpolation filters. Anything else?

     

    Hi Mansr,

     

    The thing that I see over and over and over in this thread is an irrational belief in the importance of the DAC chip itself. Just about everything affect the sound of an audio product, but when it comes to DACs, I would rank (in order or sonic importance the general categories as follows:

     

    1) The analog circuitry - 99.9% of all DACs are designed by digital engineers who don't know enough about analog. They just follow the app note. The specs on the op-amps are fabulous and digital engineers are inherently seduced by the beauty of the math story. There are minor differences in the sound quality between various op-amps, but it's kind of like the difference between a Duncan-Heinz cake mix and a Betty Crocker cake mix. 99.8% of the op-amps are used a current-to-voltage converters with the inverting input operating as a virtual ground. This is probably the worst way to use an op-amp as the input signal will cause the internal circuitry to go into slewing-limited distortion. http://www.edn.com/electronics-blogs/anablog/4311648/Op-amp-myths-ndash-by-Barrie-Gilbert

     

    With discrete circuitry, the only limit is your imagination. You are free to adjust the topology of the circuit, the brands of the parts, the active devices, the bias current in each stage - anything you can think of. Think of this as going to a world-class patisserie in Paris and seeing all the different things that can be made.

     

    2) The power supplies - 99.9% of all DACs use "3-pin" power supply regulators, which are pretty much op-amps connected to a series pass transistor. Everything in #1 applies here.

     

    3) The master clock - jitter is a single number assigned to measure the phase noise of an oscillator over a fixed bandwidth. It is far more i important to know the spectral distribution of the timing variations and how they correlate to audible problems. 99.9% of all DACs use a strip-cut AT crystal in a Pierce gate oscillator circuit. It's pretty good for the money but the results will depend heavily on the implementation, particularly in the PCB layout and the power supplies (#2).

     

    It's hard to rank the rest of these so I will give them a tie score.

     

    4) The digital filter - 99.9% of all DACs use the digital filter built into the DAC chip. About a dozen companies know how to make a custom digital filter based on either FPGAs or DSP chips.

     

    4) PCB layout - grounding and shielding, impedance-controlled traces, return currents, and return current paths are all critical. For a complex digital PCB, 8 layers is the minimum for good results.

     

    4) The DAC chip - almost everything these days is delta sigma with a built-in digital filter. Differences between different chips is one of the less important aspects of D/A converter designs. Both ESS and AKM have some special tricks to reduce out-of-band noise, which can be helpful, but not dramatic.

     

    4) Passive parts - the quality of these can make a large difference in overall performance, especially for analog. Not many digital engineers sit around listening to different brands of resistors to see what sounds best.

     

    These are just a few of the things that make differences in the way that a DAC will sound.

     

    Hope this helps,

    Charles Hansen


  10. Preliminary review of SR-7
    A novel way to massively improve the SQ of computer audio streaming

    First Impressions of Paul Hynes SR-7

     

    It's a funny thing. When my SR-4 was delivered just before Christmas, I was leaving on vacation, so @limniscate got to spend a week with it before even I did. Well, now the tables are turned. He left on vacation the day after his long-awaited SR-7 arrived, so he graciously lent it to me.

     

    I've got about 100 hours of burn in on the unit, so I thought I'd post some initial impressions. The usual caveats apply: these impressions may change as the unit continues to burn in, and/or with more experiments over longer periods.

     

    First things first. While we talk about SR-7s as if they were well-defined PSUs, it's important to note these are custom PSUs, and can be specified with may variables.  So let's first clarify exactly what Eric's build is. It is an SR7MR2DRXL, with 2 HD (6A) modules. Let's unpack what that means:

    1. MR2 => this is a 2 rail PSU. According to Paul's price sheet, "the SR7MR uses a custom manufactured mains transformer with up to 500VA rating depending on the overall rail requirements." I haven't opened the unit to inspect what the VA rating of the transformer is, but it is hefty for sure.
    2. DR => dual regulators. Per Paul, "... DR versions where two of the high performance voltage regulators are cascaded to a give supply line and rectification interference rejection exceeding 150 dB from DC to 100 KHz. This provides lower overall noise levels than the standard power supplies and better dynamic performance."
    3. XL => "...XL ultra low impedance (< 1 milliohm) connectors and fine silver internal wiring between capacitor banks, regulator modules and the output connectors."
    4. HD modules => "up to 6A continuous, 30A transient current with a maximum output of 80W continuous"

    A final point before I get into my impressions. The last time we did a similar comparison was in Chicago during AXPONA, at @Johnseye's, with @lmitche and @Forehaven. John reported here: https://www.computeraudiophile.com/forums/topic/30376-a-novel-way-to-massively-improve-the-sq-of-computer-audio-streaming/?do=findComment&amp;comment=808332. One of the interesting findings had to do with comparing the SR-4 to the SR-7 when both rails were active, and I wanted to test that again in my setup.

     

    While I listened with multiple tracks, I'll zoom in on one, perhaps familiar to more people, to discuss my findings. The piece is Limehouse Blues from Jazz at the Pawnshop. I have the 24/192 version. From about 3:00 to 4:00 is a vibraphone (?) solo, followed from 4:00 onwards by a set of chords on piano and double bass. Take a listen if you want to familiarize yourself with it. I'll wait. ?

     

    My baseline setup at this time is:

    • TLS OCXO switch (LPS-1.2) > Zenith SE > tX-USBultra (SR-4) > Mytek Brooklyn DAC+ (JS-2)
    • Mutec Ref 10 reference clock > tX-USBultra

    After listening on the baseline config, it was time for some comparisons.

     

    Comparison 1 - Swap SR-4 with one rail of SR-7 to power tX-USBultra:  To be honest, I was not expecting much of a difference here, given our findings in Chicago. Not so this time! As good as the SR-4 is, this was a noticeable improvement. In the vibraphone solo, the notes took on an almost luminous tone, the texture of the instrument was more palpable. Beyond that, the sense of the space (the Pawnshop club) was much more real. There was a lot more micro-detail - background conversation, movement, etc. Finally, the image seemed more spacious. I always describe this effect as a sharpened focus, as if you have a cleaner, sharper lens into the music.

     

    Comparison 2 - now use the 2nd rail of the SR-7 to power the Brooklyn DAC+ in place of the JS-2: This was even more of a jump in SQ! Everything I described above improved even more. There was significantly more palpability and excitement to the space. The key additional ingredient was another bump in dynamics. To describe this, focus on the immediate aftermath of the vibraphone solo starting right around 4:00. The chords by the piano, double bass, and drums now just throb with energy. It's hard to describe how the same music I was listening to in the baseline config just has a new level of energy and excitement to it. Since this scenario is using both rails of the SR-7, I was vigilant for the excess bass we heard in Chicago. There was none. Bass was tight and satisfying.

     

    Comparison 3 - now go back to SR-4 to power the tX-USBultra: The point of this experiment is to address the finding from Chicago. Does using both rails of the SR-7 compromise the SQ? How does SQ change when replacing one of them for the SR-4? Answer: the SQ degrades approximately the same magnitude as the improvement in comparison 1.

     

    Tentative Conclusions:

    • Despite the superlative performance delivered by the JS-2 and SR-4, the SR-7 found a way to improve on it quite significantly. Now I understand why @romaz speaks so highly of this PSU!
    • I did not hear any noticeable SQ penalty for using both rails of the SR-7 in the chain. This is contrary to what was observed in John's system. Perhaps the use of DR in both rails of Eric's system provides a level of resilience from cross-rail intermodulation noise.
    • While I could not isolate and evaluate the sonic impact of DR and XL, there is no doubt the combination of SR7, DR, and XL results in a PSU par excellence!

    Over the next few weeks, I'll revisit this and add more findings from running the SR-7 in Eric's system. Stay tuned!

     

     

     

     


  11. JS on word clock sample rates in DACs
    A novel way to massively improve the SQ of computer audio streaming
    On 8/21/2017 at 6:21 PM, austinpop said:

     

    I am not a clock expert, but I think the answer is no.

     

    Word clock is usually used to refer to clocks that are equal to or (sub-) multiples of the audio data rates of 44.1 or 48 KHz.

     

    The sCLK-EX mods actually supply a 25MHz clock to the switch. As I understand it, this is neither a conventional word clock, nor a reference clock. At this point, I only know of SOtM providing this kind of clock improvement.

    In this case the 25 MHz IS a reference clock. To my mind a reference clock is one that is used as the reference to a PLL, frequently a PLL used in a frequency synthesizer of some sort. In the case of an Ethernet switch chip the 25MHz feeds a PLL which generates the 125MHz clock which is actually used for the Ethernet data rate. (both 100Mb and 1Gb use 125 Mega Samples per Second on the wire).

     

    So Yes it is being used as a reference clock. MANY clocks in digital systems are used this way. USB chips definitely do this (you feed 24MHz in and the data rate is at 480Mb/s), most of the clocks in a motherboard are generated by PLLs from lower frequency "reference clocks".

     

    A fair number of DAC chips also have PLLs that generate the internal clocks from an external reference clock.

     

    The Sotm clock board has a reference oscillator and a PLL based frequency synthesizer  that can generate 4 independent frequencies. If you want to you can also use it with an external reference clock. 

     

    John S.


  12. Ayre QX-8 technical details
    New Ayre 8 series DAC
    10 hours ago, thyname said:

     

    Ryan: wow! that says a lot. Maybe I should wait for the QX-8 and not buy the QX-5 now.

     

    Also, can you comment on the differences on the Ethernet chip / card between the QX-8 and QX-5?

     

    And perhaps on the differences between the two in general?

     

    Thanks!

     

    9 hours ago, austinpop said:

     

    That’s exciting!

     

    Echoing the question about difference with the QX-5,let me also add - please also compare with the Codex, as this is an obvious upgrade path.

     

    I’m particularly interested in comparisons of the power supplies used in all 3.

     

    I'd be happy to!  While the QX-5 is still what we consider our giant slayer, we wanted to have a series that was a little easier on peoples' pockets so that more people could enjoy what Ayre does.  Of course, much to our annoyance, costs and economies still exist when we're trying to fit everything into a smaller budget, so we couldn't do EVERYTHING the QX-5 does, but we feel we did a good job of it.  Of course, that remains for you to decide.

     

    A main differences between the QX-5 and QX-8 without going too far into detail are: the QX-5 has our passive line filtering technology (AyreConditioner) built-in while the QX-8 does not.  The QX-5 has 4 separate transformers with different windings used to drive the many parts of the QX-5 (Ethernet, USB, Digital, Analog) and the QX-8 has a single transformer with separate windings to drive these different parts of the circuit.  The DAC chip used to drive the QX-5 is the ES9038PRO while the QX-8 uses the ES9038Q2M.  The QX-5 has custom-made SC-cut crystals from Morion, the QX-8 has more traditional oscillators that we chose as having the best measurements we could find "off the shelf" -- they're still customized for our frequency needs, of course.  PCB materials, components used, and the amount of voltage regulation on the two units also differs based on what we could get into the QX-8's budget as is typical with differently-priced lines.  Finally, the number of inputs differs between the two units, though I believe most homes wouldn't need more than what the QX-8 has available.  Both units still use our new asynchronous solution for S/PDIF, have the same base module for the Ethernet (though the boards they mount to differ), have linear power supplies, and asynchronous USB DACs that we're known for; not to mention we're all waiting impatiently to be able to buy the first EX-8s (which the QX-8 is based on) when we have enough for employee sales to start.

     

    Regarding the Codex, that may be the closer relative of the QX-8, using similar components and materials.  Obviously, the QX-8 has quite a few more functions and power requirements to drive everything along with a newer DAC chip, but are both evolved designs based on the Pono player we designed the audio circuit for.  The Codex only offers asynchronous USB while the QX-8 offers that and more, depending on what you want added to it.

     

    So to answer on what you should get...I guess it depends.  The QX-8 is a great unit that I'd be absolutely happy with, but I also would be happy with everything we make, or we wouldn't make it.  The QX-5 is of course even better, and I imagine you'd be hard pressed to find something that outshines it.  So, like everything, it comes down to if you think the QX-5 is better enough to spend the money on it.  I'm sorry I don't have a better answer than that, I'd love to say we figured out how to make something twice as good at half the price!  Maybe someday.


  13. JS on phase noise and jitter
    USB jitter - why does it matter?
    1 hour ago, Sound Hound said:

    hi folks,

     

    I'm putting together an 8 channel system with DDX amps for experimenting with ambisonics and multiway active setups.

    since my background is computers and I've only recently forayed into audio, I'm a bit mystified by jitter and precision clocking.

    I get that galvanic isolation and a separate, clean power source are important to the audio bits beyond the computer.

    but I don't understand why the USB connection between such needs to have more than a reliable/accurate transfer of data.

    does the jitter transmit stray signals into the latter stages?  if not, then the only place high precision clocks are warranted is in driving the DAC or DDX stage.

    surely any USB implementation is sufficient with the data adequately buffered.

    reclockers?! iPurifiers?!   pah - audio voodoo!

    I'm cynical but ready to be enlightened!

    thanks....

    Hi Sound Hound,

    I have been working on this for years, I'm getting close to a complete end to end measurement, but test equipment to properly measure this stuff doesn't exist, I'm having to design and build my own as I go along. I can measure pieces of the chain now and the rest hopefully coming soon. Part of the slowness was getting laid off and retiring and moving to a new state. I now have a working lab again and am working on the next piece of test equipment.

     

    The hypothesis goes thusly:

     

    ALL crystal oscillators exhibit frequency change with power supply voltage change. This is known and well measured. A cyclical change in voltage causes a cyclical change in frequency which shows up in phase noise plots. For example if you apply a 100Hz signal to the power supply of the oscillator you will see a 100Hz spur in the phase noise plot. 

     

    A circuit that has a digital stream running through it will will generate noise on the power and ground planes of the PCB just from the transistors turning on and off that are processing that stream. This effect is very well known and measured. Combine this with the previous paragraph and you have jitter on the incoming data stream producing varying noise on the PG planes that modulates the clock increasing its jitter.

     

    The above has been measured.

     

    But shouldn't ground plane isolation and reclockers fix this? At first glance you would think so, but look carefully at what is happening. What is a reclocker? A flip flop. The incoming data with a particular phase noise profile goes through transistors inside the flip flop. Those transistors switching create noise on its internal PG traces, wires in the package and traces on the board. This noise is directly related to the phase noise profile of the incoming data. This PG noise changes the thresholds of the transistors that are clocking the data out thus overlaying the phase noise profile of the local clock with that of the clock used to generate the stream that is being reclocked. This process is hard to see, so I am working on a test setup that generates a "marker" in the phase noise of the incoming clock so it becomes easy to see this phase noise overlaying process.

     

    This process has always been there but has been masked by the phase noise of the local clock itself. Now that we are using much lower phase noise local clocks this overlying is a significantly larger percentage of the total phase noise from the local clock.

     

    Digital isolators used in ground plane isolation schemes don't help this. Jitter on the input to the isolator still shows up on the output, with added jitter from the isolators. This combination of original phase noise and that added by the isolator is what goes into the reclocking flip flop, increasing the jitter in the local clock. Some great strides have been made in the digital isolator space, significantly decreasing the added phase noise which over all helps, but now the phase noise from the input is a larger percentage, so changes to it are more obvious.

     

    The result is that even digital isolators and reclocking don't completely block the phase noise contribution of the incoming data stream. It can help, but it doesn't get rid of it.

     

    For USB (and Ethernet) it gets more complicated since the data is not a continuous stream, it comes in packets, thus this PG noise comes in bursts. This makes analysis of this in real systems much more difficult since most of the time it is not there. Thus any affects to an audio stream come and go. Thus just looking at a scope is not going to show anything since any distortion caused by this only happens when the data over the bus actually comes in. To look at anything with a scope will take synchronizing to the packet arrivals. Things like FFTs get problematic as well since what you are trying to measure is not constant . It will probably take something like wavelet analysis to see what is really happening.

     

    The next step in my ongoing saga is to actually measure these effects on a DAC output. Again I have to build my own test equipment. The primary tool is going to be an ADC with a clock with lower phase noise than the changes which occur from the above. AND it needs to be 24 bits or so resolution. You just can't go out and buy these, they don't exist. So I build it myself.

     

    I have done the design and have the boards and parts, but haven't had time to get them assembled yet. Then there is a ton of software to make this all work. Fortunately a large part already exists, designed to work with other systems but I can re-purpose it for this.

     

    So it's not going to be right away, but hopefully not too off in the future I should be able to get to actually testing the end to end path of clock interactions all the way to DAC output.

     

    John S.

     

     

     

     


×
×
  • Create New...