Jump to content

Johnseye

  • Content Count

    2036
  • Joined

  • Last visited

  • Country

    United States

5 Followers

About Johnseye

Personal Information

  • Location
    Third Coast

Recent Profile Visitors

7176 profile views

Bookmarks

  1. Nenon's Mundorf
    Building a DIY Music Server

    Time to make some cables. 

     

    Cables.thumb.jpg.a12a46dd16a6daef6c659d1286e264df.jpg

     

    I use Mundorf 15.5AWG silver/gold wire in organic cotton sleeves, soldered by WBT silver solder, and shielded with JSSG360. 

    More about these cables in the following posts:

    On 1/4/2020 at 9:53 AM, Nenon said:

    Happy New Year, everyone!

     

    On the subject of DC cables:

    I have experimented with a lot of DC cables - different materials (i.e. silver, copper, silver/gold, different geometries (i.e. starquad, twisted pair, etc.), different insulators (i.e teflon, cotton, etc.), different brands (i.e. Neotech, VHAudio, Mundorf, etc.), different gauges, and even with different connectors where possible. I can write pages and pages on my experience with DC cables so far, but here are my two recommendations.

     

    1. For a budget DC cable, it's hard to beat the 16 AWG Ghent Audio Neotech 7N copper cable  with JSSG360 shielding. It's a no brainer and easy recommendation. 

     

    2. My absolute favorite is the Mundorf 15.5 AWG Silver / Gold wire - https://www.partsconnexion.com/MUNDORF-72180.html. Wrap each wire in a cotton sleeve (not mandatory), twist the two wires together, solder it with good solder (I use WBT solder with silver content), and you will be amazed. 

     

    I had an audio designer/manufacturer at my house a couple of weeks ago, and I was telling him how big of a difference the DC wires make. I currently use 6 rails on my computer. I told him to pick one of the 6 cables, and I will replace the Silver/Gold cable with the 16 AWG Neotech 7N copper / JSSG360 from Ghent. He picked a random rail. I replaced one of the cables on that rail, and our jaws dropped. The silver/gold wire sounded so much better. Don't get this the wrong way, though. The Ghent cable is a huge upgrade to any stock cables. But the silver/gold takes your system to another level. 

     

    I don't know how they compare to the Paul Hynes cables, but I would put them against anything out there and don't think they would embarrass. They do take some break-in time, though. But they sound great from day one.

     

    These cables are easy to make if you can solder. Hit me on PM if you have questions how to make them. I've made a few for friends and am willing to make a few more just so we can spread the word out. But my spare time is more valuable and I don't plan to spend it making cables :). Just a couple, so we can gather more feedback in different systems. 

     

    On 1/4/2020 at 8:22 PM, Nenon said:

     

    I don't want to derail this thread with DIY cables, there are plenty of other threads on that, but for completeness, here is what you need for 1 foot cable:

     

    Wire: https://www.partsconnexion.com/MUNDORF-72180.html - 2 feet

    Cotton: https://www.partsconnexion.com/COTTUBE-72533.html - 2 feet

    Whatever connectors you need, i.e. https://www.vhaudio.com/oyaide-dc.html

    Techflex cable sleeving to decorate the cable: https://www.vhaudio.com/heatshrink.html#techflex - 1 foot + a little extra

    And some heatshrink: https://www.vhaudio.com/heatshrink.html#heatshrink - 2 pieces to go over the connectors

    I use WBT solder: https://www.vhaudio.com/heatshrink.html#solder - 1 foot is plenty

     

    For the JSSG360 shielding, you would need some tinned copper braid. Plenty of options on that:

    https://www.partsconnexion.com/tinned-copper-braid.html

    https://www.amazon.com/gp/product/B003HGHQYM/

    the 1/4'' should be fine for a two wires cable.

    and some plumbers tape: https://www.amazon.com/gp/product/B06XCWQ4D2/

    There is a lot of info how to do the shielding, please search the forum.

     

    Making the cable:

    Cut two wires to your preferred length.

    Insert each wire in its own cotton sleeve.

    Slightly twist the two wires together. BTW, I just realized I have not twisted mine. 

    Insert the twisted wires in the first tinned copper braid.

    Wrap the tinned copper braid with plumbers tape.

    Insert in the second tinned copper braid.

    Do the JSSG360 shielding - connect the first braid and the second braid on each side. 

    Insert in the techflex cable sleeving.

    Add heatshrink at both ends.

    Solder the connectors (don't forget to insert the back part of the connector before soldering). 

    Heat the heatshrink in place. 

     

    Hope that helps. Please share your impressions if you try it. 

     

    Here is how the cables look inside:

    Cable-inside.jpg.0df7cd892456a2865abd8ebe6070ac11.jpg

     

    I need 4 umbilical cords for this build. 

    - The regulators for the PinkFaun USB bridge with ultraOCXO clocks are inside the power supply chassis. That one would need a GX16-2 to DC2.5 connector.

    - The other 3 umbilical cords are for connecting the two chassis (for the 3.3VDC, 5VDC, and 12VDC ATX connector). 

    The Voltages feeding the 3.3V and 5V regulators are the same. So it is safe to use the same connectors and cables (GX16-3 pin in this case). They are slightly different, because one of these rails is 5A, the other is 1.5A. But nothing would explode if you mistakenly swap them. However, as it can be seen on the picture below, the 1 foot cables are short enough, and it would be difficult to connect them wrong... swapping out #2 and #3 from the picture below would require some creativity as one of the cables would be almost impossible to reach. 

    The fourth cable is a GX16-4 pin. That's a higher voltage, and it's important to make it impossible to plug it in the wrong hole. Hence, the 4-pin connector. 

    There is a fifth cable in the picture - the long one - that is going to an external Sean Jacobs LPS and will power the CPU/EPS. I like that, because we not only have a dedicated rail for the CPU but also a dedicated toroidal transformer. That provides an extra level of power isolation. And the CPU is the best to isolate. Of course that means another power cord, fuse, vibration treatment, etc.

     

    Cables-connected.jpg.bfc14d913d277f2057d001e0bea9ff4d.jpg

    Btw, these cables are very flexible and stay the way you bend them without fighting to go back to their original position. They are the best DC cables I have heard. Highly recommended.

     

    EDIT: Here is a step by step guide on how to make these cables:

    7 hours ago, elan120 said:

    Cables...

     

    After having the EPS and ATX power supply built, I now move into cable making phase, while working on the first cable, I decided to record the sequence in more details to share here, hopefully this will help more people interested in trying out the long discussed Mundorf solid core silver JSSG360 DC cable.

     

    1. Slide cotton tube over the Mundorf solid core silver hook up wire.

    20200611_180506.thumb.jpg.29c41a12e9cb98725a0177b687825801.jpg

     

    2. Solder wires to the connector.  In this cable, I have GX16-4 on one end and Oyaide DC-2.1G on the other end.  I started this wire from the GX16-4 side.

    20200611_204529.thumb.jpg.148db99a185ee9efa16facbf4c6ed758.jpg

     

    3. After the wires are soldered, slide a short heat shrink tubing over the cotten tubes to help protect the end.

    20200611_205422.thumb.jpg.9fee1ca12cc902050088abc552747c5f.jpg

     

    4. Reassemble the GX16-4 connector.

    20200611_210127.thumb.jpg.db318e2b240640c8b66a46ddf3c439a9.jpg

     

    5. Twist the two wires.

    20200611_210426.thumb.jpg.2d27443cdc5f02e586fc7d1b1e8cd6cd.jpg20200611_210445.thumb.jpg.bf44f2f6d7788d461ec871b36bee84e5.jpg

     

    6. Getting the Oyaide DC-2.1G side ready.  Slide the connector outer shell over the wires, cut two pieces of heat shrink tubing.  The smaller diameter one is to protect the positive lead after wire is soldered to the connector, and the larger diameter heat shrink tubing is to help protect the cotton tube ends.

    20200611_231138.thumb.jpg.012c50d54a005d20466aa7a94ccd5ee9.jpg

     

    7. Solder wires to the connector.  It is easier to solder the negative lead to the connector first, and then solder the positive lead.

    20200611_232608.thumb.jpg.992a6bdca3ab22c25f784d307f5990da.jpg

     

    8. Heat shrink the smaller tubing over the positive lead solder join.

    20200611_232751.thumb.jpg.437e27a2d062b16a0552954334caf86e.jpg

     

    9. Slide the larger heat shrink tube over the end of cotton tube.

    20200611_233113.thumb.jpg.29dd065e7c1eb6ea3361b58b74148f50.jpg

     

    10. Test the connector to make sure wires soldered is open.

    20200611_233258.thumb.jpg.6e3a20a0a9c9f200cb0823e2672b1aa3.jpg

     

    11. Slide the outer shell over the connector.  It is a good idea to check continuity again after the connector is reassembled.

    20200611_234118.thumb.jpg.251181f2c250d44fd3dd0bc857e4c8d0.jpg

     

    12. Base cable completed.

    20200611_234209.thumb.jpg.052b34f386015801a9dbe80b44fd6054.jpg

     

    13. Now we will start working on JSSG360 shielding by sliding the tinned copper braid over the base cable from the Oyaide connector side.

    20200612_093553.thumb.jpg.a96658f9793f1492683456638f2880b2.jpg

     

    14. Wrap the tinned copper braid with teflon thread tape.  It is easier to work with using 1" wide gas pipe tape.

    20200612_093746.thumb.jpg.423f6862de232fb57feadca5668097d6.jpg

     

    15. Teflon tape wrapped cable.

    20200612_095027.thumb.jpg.c4ffbbceaf86a93229800935ebfffba2.jpg

     

    16. Before sliding the second layer tinned copper braid, wrap a short section of teflon tape over the end of first tinned copper braid to protect the end and prevent the wires from braid from interfere with the second layer tinned copper braid while sliding over the first one.

    20200612_095143.thumb.jpg.230eea0ee71552ef16cf3989495bc288.jpg20200612_095236.thumb.jpg.fb06e5783c6b3c928f7e376cb4693b9d.jpg

     

    17. After the second layer tinned copper braid is slided over the first layer, don't forget to remove that short section teflon tape.

    20200612_095613.thumb.jpg.78844fcf0babc03a2a58ea23dffbe0fc.jpg

     

    18. Cut one piece of adhesive lined heat shrink tubing and slide them over the end of two tinned copper braids.

    20200612_100518.thumb.jpg.79943deb194b7f4af70f08e14b47f54c.jpg

     

    19. Apply heat to heat shrink tubing.

    20200612_100714.thumb.jpg.23258548dcf4fb2db0b2e3bf900be361.jpg

     

    20. Do the same two steps (18 and 19) above for the Oyaide connector side.

    20200612_100901.thumb.jpg.d1bce813ffe2d52212845588d8cefa46.jpg20200612_101130.thumb.jpg.e3d53661204425bc3d4220184faa0065.jpg

     

    21. Check continuity between the tinned copper braid and the connector to ensure it is open.

    20200612_101239.thumb.jpg.b9a1836cd95462b854524ee4fbd55ccc.jpg

     

    22. JSSG360 shielding completed.

    20200612_101439.thumb.jpg.69744519def464f5db6680ae8f4e2a55.jpg

     

    23. Next is to dress up the cable by cutting the Techflex sleeving to proper length and then slide over the JSSG360 shielding completed cable.

    20200612_101706.thumb.jpg.bade5913f8e15b9f9de490f29bd6d423.jpg

     

    24.  Final step is using the same adhesive lined heat shrink tubing to bond them together.

    20200612_104717.thumb.jpg.3f8970a9d7cdb7379952143b9f300cb9.jpg

     

     

    Hope these are clear and simple to follow.  Enjoy building them.

     

    I will now move on to work on ATX and EPS cables.

     

     

    Okay, let's fire up this guy now... if I don't post in a while it either exploded or I am really enjoying the music :)


  2. Mundorf JSSG360
    A novel way to massively improve the SQ of computer audio streaming

    Cables...

     

    After having the EPS and ATX power supply built, I now move into cable making phase, while working on the first cable, I decided to record the sequence in more details to share here, hopefully this will help more people interested in trying out the long discussed Mundorf solid core silver JSSG360 DC cable.

     

    1. Slide cotton tube over the Mundorf solid core silver hook up wire.

    20200611_180506.thumb.jpg.29c41a12e9cb98725a0177b687825801.jpg

     

    2. Solder wires to the connector.  In this cable, I have GX16-4 on one end and Oyaide DC-2.1G on the other end.  I started this wire from the GX16-4 side.

    20200611_204529.thumb.jpg.148db99a185ee9efa16facbf4c6ed758.jpg

     

    3. After the wires are soldered, slide a short heat shrink tubing over the cotten tubes to help protect the end.

    20200611_205422.thumb.jpg.9fee1ca12cc902050088abc552747c5f.jpg

     

    4. Reassemble the GX16-4 connector.

    20200611_210127.thumb.jpg.db318e2b240640c8b66a46ddf3c439a9.jpg

     

    5. Twist the two wires.

    20200611_210426.thumb.jpg.2d27443cdc5f02e586fc7d1b1e8cd6cd.jpg20200611_210445.thumb.jpg.bf44f2f6d7788d461ec871b36bee84e5.jpg

     

    6. Getting the Oyaide DC-2.1G side ready.  Slide the connector outer shell over the wires, cut two pieces of heat shrink tubing.  The smaller diameter one is to protect the positive lead after wire is soldered to the connector, and the larger diameter heat shrink tubing is to help protect the cotton tube ends.

    20200611_231138.thumb.jpg.012c50d54a005d20466aa7a94ccd5ee9.jpg

     

    7. Solder wires to the connector.  It is easier to solder the negative lead to the connector first, and then solder the positive lead.

    20200611_232608.thumb.jpg.992a6bdca3ab22c25f784d307f5990da.jpg

     

    8. Heat shrink the smaller tubing over the positive lead solder join.

    20200611_232751.thumb.jpg.437e27a2d062b16a0552954334caf86e.jpg

     

    9. Slide the larger heat shrink tube over the end of cotton tube.

    20200611_233113.thumb.jpg.29dd065e7c1eb6ea3361b58b74148f50.jpg

     

    10. Test the connector to make sure wires soldered is open.

    20200611_233258.thumb.jpg.6e3a20a0a9c9f200cb0823e2672b1aa3.jpg

     

    11. Slide the outer shell over the connector.  It is a good idea to check continuity again after the connector is reassembled.

    20200611_234118.thumb.jpg.251181f2c250d44fd3dd0bc857e4c8d0.jpg

     

    12. Base cable completed.

    20200611_234209.thumb.jpg.052b34f386015801a9dbe80b44fd6054.jpg

     

    13. Now we will start working on JSSG360 shielding by sliding the tinned copper braid over the base cable from the Oyaide connector side.

    20200612_093553.thumb.jpg.a96658f9793f1492683456638f2880b2.jpg

     

    14. Wrap the tinned copper braid with teflon thread tape.  It is easier to work with using 1" wide gas pipe tape.

    20200612_093746.thumb.jpg.423f6862de232fb57feadca5668097d6.jpg

     

    15. Teflon tape wrapped cable.

    20200612_095027.thumb.jpg.c4ffbbceaf86a93229800935ebfffba2.jpg

     

    16. Before sliding the second layer tinned copper braid, wrap a short section of teflon tape over the end of first tinned copper braid to protect the end and prevent the wires from braid from interfere with the second layer tinned copper braid while sliding over the first one.

    20200612_095143.thumb.jpg.230eea0ee71552ef16cf3989495bc288.jpg20200612_095236.thumb.jpg.fb06e5783c6b3c928f7e376cb4693b9d.jpg

     

    17. After the second layer tinned copper braid is slided over the first layer, don't forget to remove that short section teflon tape.

    20200612_095613.thumb.jpg.78844fcf0babc03a2a58ea23dffbe0fc.jpg

     

    18. Cut one piece of adhesive lined heat shrink tubing and slide them over the end of two tinned copper braids.

    20200612_100518.thumb.jpg.79943deb194b7f4af70f08e14b47f54c.jpg

     

    19. Apply heat to heat shrink tubing.

    20200612_100714.thumb.jpg.23258548dcf4fb2db0b2e3bf900be361.jpg

     

    20. Do the same two steps (18 and 19) above for the Oyaide connector side.

    20200612_100901.thumb.jpg.d1bce813ffe2d52212845588d8cefa46.jpg20200612_101130.thumb.jpg.e3d53661204425bc3d4220184faa0065.jpg

     

    21. Check continuity between the tinned copper braid and the connector to ensure it is open.

    20200612_101239.thumb.jpg.b9a1836cd95462b854524ee4fbd55ccc.jpg

     

    22. JSSG360 shielding completed.

    20200612_101439.thumb.jpg.69744519def464f5db6680ae8f4e2a55.jpg

     

    23. Next is to dress up the cable by cutting the Techflex sleeving to proper length and then slide over the JSSG360 shielding completed cable.

    20200612_101706.thumb.jpg.bade5913f8e15b9f9de490f29bd6d423.jpg

     

    24.  Final step is using the same adhesive lined heat shrink tubing to bond them together.

    20200612_104717.thumb.jpg.3f8970a9d7cdb7379952143b9f300cb9.jpg

     

     

    Hope these are clear and simple to follow.  Enjoy building them.

     

    I will now move on to work on ATX and EPS cables.

     

     

     

     


  3. A novel way to massively improve the SQ of computer audio streaming
    A novel way to massively improve the SQ of computer audio streaming
    On 12/10/2018 at 5:44 PM, seeteeyou said:

    A123 LiFePO4 batteries are well known for their quality, that's why Ian Canada's latest project might do the trick when we're powering multiple units of NUC

     

    https://www.diyaudio.com/forums/power-supplies/327105-develop-ultra-capacitor-power-supply-lifepo4-battery-power-supply-31.html#post5623486

     

    Just back from a few weeks away for work and catching up on developments here. Also today I had time to complete a new power supply I wanted to try out. It's Ian Canada's new LifePO4 power supply which includes 2x isolated 13.2v DC outputs (among the 5 possible rails) and I was interested to try this to power my 2 NUCs with a higher voltage than my SR4s can supply.

     

    First impressions are this is an excellent solution. More punch, dynamics and a very clean sound, so this is a keeper for me. The board is $189.99 and the A123 26650 LifePO4 batteries are extra. This project involves DIY and some soldering but a is a very nice, relatively low cost and worthwhile option for powering NUCs. There is a Mk II version of the board now available.

     I am not affiliated with Ian Canada just sharing what I have found. For more info see DiyAudio thread: 

    https://www.diyaudio.com/forums/power-supplies/327105-develop-ultra-capacitor-power-supply-lifepo4-battery-power-supply.html
     

    "This LifePO4 pure battery power supply is a completed solution to provide battery based clean power voltage rails. When it's turned off, all batteries will be charged automatically. The charging progress is managed and monitored by Smart battery management. Comparing with an active power supply such as a voltage regulator, it has much better load transient response and less noise. Includes five independent voltage rails - 2x 3.3V isolated voltage rails. 2x 3.3V-13.2V isolated voltage rails, which can be configured as 3.3V, 6.6V, 9.9V or 13.2V separately. 1x 5V 2A linear LT3042 regulated non-isolated rail."

     

    Now I have 2x SR4s to repurpose for other tasks! 

    IMG_6651.thumb.jpg.8072cf011f817d316a97315edcdc00bf.jpg

    IMG_6652.thumb.jpg.ca363ad2da6abd798c2c507382bc3d50.jpg


  4. Audiolinux Server configurations, Software, Hardware, and Listening Impressions
    Audiolinux Server configurations, Software, Hardware, and Listening Impressions

    I will try to make a summary of different configurations, in order of CPU load.

     

    First the standard audiolinux kernel is now linux-rt-bfq without NUMA enabled. You can install it from menu as usual, even if the version number is the same.

    This is because system performance is better in this case.

    With NUMA disabled CUDA acceleration in HQPlayer will not work. You can install the one with NUMA enabled downloading the files from https://www.audio-linux.com/ftp/packages/kernel/last/linux-rt-bfq-numa/ Contact support if you have some doubt.

     

    Ok, this is the sequence of configurations:

     

    1) Extreme/Extreme2 boot + Extreme priority

    2) Standard boot + Extreme priority

    3) Standard boot + Standard priority

    4) Standard boot + disabled manual priority assignment. This can be done as root with:

    systemctl disable rtapp.timer

    systemctl disable rtirq

     

    If you have a powerful processor and a good cooling system option 1) could be the best but with weak processors I would try to scale down CPU utilization using the other options, for example using option 3)

    If you have chosen to use a not powerful power supply because you think this choice is better for sound, you cannot use your system the same way as a 1000 Watt system...you should find the right balance between power and latency.

     


  5. Audiolinux Server configurations, Software, Hardware, and Listening Impressions
    Audiolinux Server configurations, Software, Hardware, and Listening Impressions

    Menu 109 with new Expert Menu:

     

     1 "Minimize your system"

    This is a custom AudioLinux script for disabling automatically some services and some kernel modules. Please use with care. You can list all loaded modules with the command

    lsmod 

    and all enabled systemd services with 

    systemctl list-unit-files --state=enabled


     2 "Realtime expert configuration"

    After pressing Yes you can edit the realtime special configuration script
    This is really for experts. Please select No if you are not sure what this is


     3 "Disable realtime expert configuration"


     4 "Alsa system wide configuration file"

    After pressing Yes you can edit the Alsa system wide configuration file
    You can save with F2. Pressing F10 you will exit from editor and the file will be copied to /etc/asound.conf

    Default is

    pcm.!default {
            type plug
            slave.pcm hw
    }

     

    As for CPU governors, Audiolinux does not really need to add balanced, conservative, powersave, etc. since there is the custom option already in the menu where you can define minimum and maximum CPU frequency manually (Turbo ON or OFF)
     


  6. Audiolinux Server configurations, Software, Hardware, and Listening Impressions
    Audiolinux Server configurations, Software, Hardware, and Listening Impressions

    Since my point of view is personal... I will stick to the facts here.

     

    In Euphony most of applications are open source and the base system is very similar to Audiolinux, but with a lot less options.
    Sound differences can be related only to different configurations, there is not such a thing like an OS that sounds better than another OS, when both are linux and specifically Archlinux...They are also speaking of an "Euphony OS" ...
    Moreover, it seems that you cannot connect with keyboard and monitor, you cannot interact with the base OS: this is a very big limitation.
    Also Stylus, as I pointed out in another post, is probably MPD with a different interface that the one used in Cantata for example. The web service is called mpdweb (...) 

     

    This is a partial summary of differences:

    1) Kernel is the same family, but in audiolinux is now 4.19.25-rt16-9-rt-bfq, where Euphony is at 4.18.7-rt5-3-rt-bfq
    Another difference could be that audiolinux kernel has NUMA enabled, otherwise CUDA acceleration in HQPlayer will not work

    2) Euphony blacklist some modules in /etc/modprobe.d/blacklist.conf

    blacklist snd_hda_intel
    blacklist snd-hda-intel
    blacklist iwlmvm
    blacklist iwldvm
    blacklist iwlwifi
    blacklist bnep
    blacklist btusb
    blacklist bluetooth
    blacklist joydev
    blacklist mousedev
    blacklist iTCO_vendor_support
    blacklist iTCO_wdt
    blacklist ip_tables
    blacklist mei_me
    blacklist intel_rapl
    blacklist intel_powerclamp

     

    Audiolinux will have a menu option to enable/disable some kernel modules. This service is already there but a menu option has not yet been added. You can edit the file manually, but please pay attention to what you do, you could loose keyboard or mouse connection.

    3) Euphony does not use the special pstate-frequency service but the cpupower service. The result should be the same, since last kernels are using intel pstate as default, but if you want to test it you should disable pstate-frequency
    systemctl disable pstate-frequency
    and enable cpupower
    systemctl enable cpupower
    Configuration is located at /etc/default/cpupower
    In Euphony this is set to
    governor='performance'
    (without the #)
    Reboot

    4) Realtime manual assignments are very similar to audiolinux Standard (not Extreme).

    5) Kernel line has no special parameters. I see only threadirqs, that is useless with realtime kernels, since threaded irqs are enabled by default

    6) There is an alsa configuration in /etc/asound.conf with inside

    pcm.!default {
            type plug
            slave.pcm hw
    }

     

    You can try to add this. HQPlayer and MPD are already using alsa directly without mixer. The differences in sound with Roon could be related to the fact Roon is using alsa mixer unless this configuration file is specified.


    7) No special ram tmpfs configurations in /etc/fstab, so no special ram assignments for loading music files, excluding the options available on MPD etc.

    --> No other relevant differences detected. It has to be noted that /etc/resolv.conf is not pointing to Google servers or some other DNS servers but...

     

     


  7. Audiolinux Server configurations, Software, Hardware, and Listening Impressions
    Audiolinux Server configurations, Software, Hardware, and Listening Impressions

    Audiolinux Tweaking
    Here's a tweak to improve Roon and other audio players using alsa mixer, this degrades sound quality, Mpd and HQPlayer connect without alsa mixer.
    To disable it:
    Create a file in /etc directory:

    asound.conf

    the following parameters for the file:

    pcm.!default {
            type plug
            slave.pcm hw
    }

    Hopefully you should hear increased clarity, dynamics.....

    It's been stated that audiolinux can sound thin / harsh/ lacking warmth etc...
    Well it's transparency can reveal weaknesses in the hardware. Good thing is that it's ultra tweak-able and can be tuned to your processor /equipment.
    Too harsh?
    Try setting realtime priority to standard and boot to standard mode.
    Still too harsh? then try tweaking the pstate_frequency parameters the directory is at: /etc/pstate-frequency.d
    open: 00-auto.plan
    change parameters:
    from max to: balanced

    open 02-balanced.plan
    set:

    PLAN_CPU_PSTATE_GOVERNOR=powersave (using the powersave algorithm the processor will not run as hot)
    PLAN_CPU_MAX=100
    PLAN_CPU_MIN=99
    This will keep the processor at a constant full speed (you can play with these percentages as long as they are constant eg. 75/74)
    Try turbo on and off whichever sounds best.

    Don't forget to disable ramroot first or ramsave after editing files and reboot.

    Thanks Piero for assistance.

     


  8. Audiolinux Server configurations, Software, Hardware, and Listening Impressions
    Audiolinux Server configurations, Software, Hardware, and Listening Impressions

    With new menu version 108 there is a new option "MPD --> select DAC and play from memory"

     

    If you want to play a file from RAM you have these options:

    1) Copy the files to audiolinux USB stick if in ram mode

    2) MPD with the commands reported below (now easier with the new menu option)
    3) Squeezelite with some output parameters

     

    HQPlayer (max 250 ms cache) and Roon (cache unknown)  have not this possibility and there is no way to implement it from outside. 

    ...At least another player is declaring that it can play from RAM, but it is really using MPD...

     

    This can be done also manually, editing the file /home/audiolinux/.mpdconf
    See MPD parameters here: https://linux.die.net/man/5/mpd.conf

     

    audio_buffer_size <size in KiB>
    This specifies the size of the audio buffer in kibibytes. The default is 2048, large enough for nearly 12 seconds of CD-quality audio.
    buffer_before_play <0-100%>
    This specifies how much of the audio buffer should be filled before playing a song. Try increasing this if you hear skipping when manually changing songs. The default is 10%, a little over 1 second of CD-quality audio with the default buffer size.

     

    Possible configuration:
    audio_buffer_size "100000"
    buffer_before_play "100%"


  9. Bridging
    A novel way to massively improve the SQ of computer audio streaming

    Bridging still helps!

     

    More than 2 years into its tenure, I yet again found that the technique that launched this thread - Ethernet bridging - makes a big difference in my system.

     

    Background

     

    Of late, I had not been using bridging in my system, for 2 reasons:

    1. from just over a year ago and until recently, I had moved from my SOtM trifecta to a Zenith SE-based all-in-one approach, so there was no network path between my Roon server and my Roon endpoint, since they were both running on the same machine.
    2. I moved my rig to another room when I put in a dedicated circuit, so my faithful Dell server was not conveniently located to run an Ethernet cable directly from its location to the listening room. All the rooms in my house have Ethernet home runs (in-wall) back to a wiring closet, so this is where my modem, router, and NAS live - far away from my listening room.

    The NUC era

     

    With my recent return to the distributed model (I've come full circle), I resurrected my Dell server (now running AL in RAM, with Roon DB in Optane SSD, and all other SATA devices disconnected) to be my Roon Core, but due to its location, could not accommodate a bridged setup.

     

    Here is the baseline layout. A couple of notes:

    • while I have it, the TLS DS-1 has usurped my i7 NUC as the endpoint
    • While not shown, the tX-UBSultra is reference clocked by the Ref 10
      • Side note - for me, the tX-U reference clocked by the Ref-10 is still a HUGE improvement vs. going direct to the DAC from the NUC/AL/RAM endpoint.

    Since my evaluation DS-1 has freed up the i7 NUC to try as a server, I recently reported in Larry's Audiolinux Server thread on comparing this i7 NUC as a Roon Server with the Dell. The latest post in that sequence is here: https://audiophilestyle.com/forums/topic/55247-audiolinux-server-configurations-software-hardware-and-listening-impressions/?do=findComment&amp;comment=917305

     

    Which leads me to bridging. Since my system has been in so much flux, my most recent configuration looks like this:

     

     

    Baseline topology

                                               
                                              Router (HDPlex 100W) ---------- NAS (SMPS)
    ------                                           |
    |      | ______________________ |

    |      |
    |      |------------------------------- i7 NUC (sPS-500 @ 19V)
    |      |
    |      |-------------------------------- DS-1 (SR-4) > tX-U (LPS-1.2) > QX-5 > amp
    |      |
    |      |_____ JSGT ground

    ------

    TLS

    OCXO

    Switch (LPS-1.2)

     

    Note that with this configuration, my i7 NUC is in my listening room, configuring a bridge on it was trivial.

     

    Bridged topology

     

    As you would expect, with bridging, the topology now looks like:

                                               
                                              Router (HDPlex 100W) ---------- NAS (SMPS)
    ------                                                         |
    |      |                                                        |

    |      |                                                        |
    |      |------------------------------- i7 NUC (sPS-500 @ 19V)
    |      |
    |      |-------------------------------- DS-1 (SR-4) > tX-U (LPS-1.2) > QX-5 > amp
    |      |
    |      |_____ JSGT ground

    ------

    TLS

    OCXO

    Switch (LPS-1.2)

     

    Listening Impressions

     

    I won't belabor the point. The bridged configuration sounds noticeably better. There is more air around instruments, a larger image, and a small reduction in "harshness," which at this point in my system is strictly a relative term, as my baseline system does not sound harsh by any means!

     

    For me, the lesson was that while all the other optimizations that this thread has covered after bridging - power, clocking, OS, isolation, etc - all make a positive difference, it doesn't remove the additional benefit that bridging still seems to provide.

     

    Explanations - none. But do try for yourselves and see what you think.

     


  10. AudioLinux and NUC Troubleshooting and Tuning
    AudioLinux and NUC Troubleshooting and Tuning
    11 hours ago, BigAlMc said:

    @ray-dude & @austinpop,

     

    Awesome work guys and great discovery.

     

    At the very real risk of pushing my luck it would be great if we could have a simple 'how to' guide for the technically incompetent (like me) showing how to set buffer size for:

     

    Squeezelite endpoint

    Roon bridge endpoint

     

    And ideally in both the 4gb and 8gb flavours that are likely most prevalent.

     

    The obvious question is whether the 4gb flavour has sufficient ram spare to make a difference in SQ via this buffer setting or whether 8gb is worth the investment?

     

    Either way this is terrific stuff and an excellent area of exploration. Even if I need to read it twice in order to understand half of it! ?

     

    Cheers,

    Alan

     

     

    Alan, I have 8GB, so I've not tried to cram things into 4GB.  With the SQ improvement we've heard with crazy large buffer sizes (still unclear why 2GB buffer is better than 20MB buffer for small audio files), I suspect you'll want to consider 8GB

     

    Couple hygiene items above the usual AudioLinux install stuff (make sure to do this will ramboot off so you have all the changes on your USB stick)  I'm learning that one can't edit posts here, so if there are typos or incorrect information, my apologies in advance that I'm unable to correct.

     

    * Set IRQ priority for the DAC USB to the highest: https://www.audio-linux.com/html/realtime.html

     

    Run: rtstatus

    This will show you the real time priorities for various applications and IRQs (HW interfaces)

     

    Run: rtcards

    This will show you your audio cards.  In my case, my DAC is card0, and sits on USB1 IRQ=123    IR-PCI-MSI 344064-edge xhci_hcd

     

    Edit: /etc/rtirq.conf

     

    Change

    RTIRQ_NAME_LIST="usb"    <--- All the USBs have high priority
    RTIRQ_PRIO_HIGH=90

     

    to

    RTIRQ_NAME_LIST="xhci_hcd"    <---- Only the DAC interface has high priority
    RTIRQ_PRIO_HIGH=95

     

     

    If you like, you can also make your ethernet a high priority by having it be:

    RTIRQ_NAME_LIST="xhci_hcd eno1"

    (order matters)

     

    This may be helpful if you run Roon Bridge (which streams data continuously).  I am using SqueezeLite (more on that later), which buffers the data up front, so I do not have ethernet as a priority (I don't want random ethernet stuff impacting the system during playback)

     

     

    * Set app priority for squeezelite and RoonBridge to be second highest

    I have squeezelite as the highest priority application.  The order in the list reflects priority order if you have multiple apps running.  In practice, you'll only have one running, so not something I worried about.  I set the max priority for applications to be a hair less than the max priority for the IRQ to the DAC.

     

    Edit:  /etc/rtapp/rtapp.conf

    APPLICATIONS="squeezelite RoonBridge jackd mpd hqplayer hqplayerd RoonAppliance mediacenter24 networkaudiod deadbeef a2jmidid ardour-5.12.0 rosegarden audacity"

    MAX_PRIORITY="93"

     

     

    At this point, if you're running Roon Bridge, you should be able to reboot and confirm that everything is still working fine.

     

     

    Now to the buffer stuff.

     

    Alas, Roon seems to be a black box when it comes to buffers.  Per Rajiv's findings, it streams data from core to the end point continuously, and I'm not aware of a way to impact that.  Given how Roon works (multi-zone, responsive UI, etc.) that is unlikely to change.  All that behavior is made better (from a user experience stand point) by having minimal buffers.

     

    If you want to play with buffers and try to isolate ethernet activity from streaming to the DAC, squeezelite is the end point of choice right now.  Alas, that comes with some "endearing quirks" (skipping, issues when seeking within a track, latency, etc), Whether the delta between convenience and SQ is something you can try and see if it is worthwhile for you.  For me, I'm leaving the system on Roon Bridge (for civilian use), except when I'm playing with maximizing SQ.  Squeezelite is a bit too quirky right now to impose on people that don't care about SQ.

     

    First step is to install squeezelite (if you have AL headless...it is already installed on the full version).  From the AL site: https://www.audio-linux.com/html/user_guide1.html (copy/pasted here)

     

    Quote

     

    Software Install – Squeezelite-R2;

    Commentary:
    The install process asks you some questions:
    It will ask you if you wish to edit some files = n, on all occassions.
    When asked whether to continue building = y
    If asked for a password = audiolinux or audiolinux0
    Proceed with installation = y
    When completed successfully it will report: No database errors have been found!

    Steps:
    > Type: yaourt -Sy
    This will update the system
    > Type: yaourt -S squeezelite-r2-git
    This will load the squeezelite software
    > Type: su
    Enter the root password
    > Type: squeezelite -l
    Identify the USB output you are going to use
    > Type: vi /etc/conf.d/squeezelite
    Update squeezelite to use that output
    > Type: systemctl daemon-reload
    > Type: systemctl start [email protected]
    > Type: systemctl status [email protected]
    Should be shown as running
    > Type: systemctl enable [email protected]
    It will now start automatically at boot.

     

     

     

     

    If you're tweaking squeezelite parameters to experiment in your system, I found it is easier to do it from the command line.  You start squeezelite, test it, hit control c to kill it, modify the parameters, start it again, rinse and repeat.

     

    To do this, go to alconf and select "Stop and disable all running audio services"

     

    From the command line, after some more experimentation, here is my current squeezelite config of choice in my system:

     

    /usr/bin/squeezelite -o front:CARD=Blu2,DEV=0 -b 4097152:97152 -d all=info -a 1000000:4 -c pcm -x -p 93

     

    For you, you may need to change some of the parameters.  

     

    The -o parameter is the output device.  You get this info for your DAC by running: squeezelite -l

     

    the -b parameter is the buffer memory that squeezelite preallocates for input from the network (first number) and output to the day (second number).  The unexplained finding is that bigger buffers are better.  I have it set so that the bulk of the buffer is allocated to the ethernet side.  The thinking here is that since we're hearing bigger buffers are better, and having an asymmetric buffer allows us to allocate more buffer space to the ethernet side.  Why 4GB vs 2GB matters for 20MB music files is a crazy making question, but I'm blaming Roon Core because they're not here to defend themselves ;)

     

    The -d parameter just sets the debug output level so you can see what squeezelite is doing as you experiment.  

     

    The -a parameter manages the buffer between squeezelite and the OS (and eventually to the DAC).  This is still a mystery to me, but above are my current settings of choice (1MB allocated to the buffer, with a periodicity of 4).  I'm still working on my Italian to suss out what all these mean, and there is more learning/experimentation to do here.

     

    -c says squeezelite only accepts PCM, and -x says no downsampling.  Shouldn't effect SQ, I just have them for hygiene.

     

    -p sets the real time priority for the squeezelite output thread.  Since I set this 93, and I have the IRQ real time priority set to 95.  From rtstatus, everything else is 50 or below.

     

     

    Once you have a config that you're happy with, you need to edit and add it to the following file: /etc/conf.d/squeezelite

     

    parameters="-o front:CARD=Blu2,DEV=0 -b 4097152:97152 -a 1000000:4 -c pcm -x -p 93"

     

    If you go to alconf and select "START and enable Squeezelite" next time you reboot, squeezelite will be started with these parameters

     

     

     

    Aside from the tactics, here is my high level strategy/thinking for the recipe (all hypothesis driven, we haven't figured this stuff out yet).  I would love to hear criticism/correction/redirection on this from others.

     

    Goal:

    Get an end point as focused as possible on moving data from ethernet to a USB DAC, with as little variability and as much predictability as possible (aka, as close to precision real time data streaming to DAC as possible)
        - Maximize processing/memory allocated to bridging bits from server to end point, to preload data as quickly as possible
        - Have an end point doing as little as possible when streaming data to DAC (everything turned off, front load network access, etc)

        - Highest priority given to end point talking to DAC (DAC USB IRQ, squeezelite thread, etc)

        - Use a stripped down semi-real time OS (AudioLinux) doing as little as possible
        - Minimize power use (RF, etc.) by shutting everything unneeded off, running in memory, etc.

        - Use the highest power silicon on a chip system with reasonable power use you can find, and manage the trade off between lower latency (good) and higher power (bad) 

     

    (as an aside, I'm OK with absolute latency, I just don't want the latency to vary...my working theory is that low latency systems are a proxy for having less variability, because they have faster CPUs, more cache, better components, etc, and less contention and more headroom at any given time)


    Approach:

     

    * NUC with high quality DC inputs, so you have all the goodies combined into single Silicon on a Chip implementation (assertion:

    there is less variability with SoC)
    * AudioLinux running headless, tuned for real time, OS running in RAM (max speed, lowest latency)

    * End point software that allows tuning and optimization and buffering (squeezelite)

    * Maximum buffers between server and end point (-b parameter), to preload data to memory over the network as quickly as possible

        - Isolate data streaming to DAC streaming from rest of chain as much possible, for as much of the music playing time as possible

    * Maximum buffers and priority between end point and DAC (-a parameter)

        - Feed DAC the steadiest/most stable/least variable data stream as possible during music playback

    * Have as little as possible other things happening during music playback

        - minimal network access, no storage access, unused features disabled, lower priority for all other things running in OS, etc
     

     

    All the above is hypothesis, but a snap shot of my current thinking.  Many here have been working and experimenting and thinking about this stuff much longer than I have, so I would give their experiences and gut intuition much more credence (I'm still working my way up the learning curve with this kit).

     

     


  11. AudioLinux and NUC Troubleshooting and Tuning
    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


  12. Massively improve the SQ of computer audio streaming?
    Massively improve the SQ of computer audio streaming?
    12 minutes ago, Superdad said:

    1>I2S>Holo Spring L3 (set to NOS).  So two questions:

    1) Short buffer or long buffer recommended?  Or something in the middle;

     

    For ASIO drivers usually and Thesycon ASIO driver, like in above case and in Spring case, leave HQPlayer "Buffer time" setting at "Default" meaning it'll use what ever driver proposes. In driver's control panel then select the buffer size. I use safest mode and biggest buffer the driver supports (which is not very big to begin with)...

     

    When you are using 352.8k PCM, from USB driver and interface point of view it is same as using native DSD256. So given buffer size X it is twice longer in time compared to same size at DSD512.

     

    12 minutes ago, Superdad said:

    2) If I turn off filters and dither entirely (yes, for NOS artifacts and all), does your DAC bits setting still have any effect?  Are there other HQP settings still doing some DSP when PCM filters & dither are off?

     

    Yes, because it defines how many non-zero bits are being sent to the DAC. If dither is off, it defines at what bit depth the samples are rounded at. Volume control and such are always active. If you are careful with the settings you can get bit-perfect output though. But that has of course never been any kind of focus area. (you can also get "bit-perfect" upsampling too where every Nth output sample value matches original)

     


  13. A novel way to massively improve the SQ of computer audio streaming
    A novel way to massively improve the SQ of computer audio streaming

    Just had to share another Gotham JSSG360 cable experience.  After the success from replacing my music PC CPU 12V power cable to Gotham JSSG360, I got very motivated to continue this path, and last night, I replaced SATA power cable to Gotham JSSG360 as well, after letting it burn-in overnight, I was very pleasantly surprised today how much SQ improvement this cable yielded.  Since these are not difficult cables to make, if you have not try them, I would highly recommend having them replaced, you will likely be as pleasantly surprised as I am.

     

    Below are few pictures of this cable:

     

    Pins crimped.  Note, my SSD only require 12V input, so the 4 available wires only 5V and 12V pins were used. 

    20181109_162013.thumb.jpg.c201c880f644271faa67752ca3c6cd10.jpg

     

    SATA connector with pins inserted:

    20181110_105350.thumb.jpg.f72849fc4e6e1ac9c33489994bf4cc14.jpg

     

    Completed cable:

    20181109_170607.thumb.jpg.d7ba122c48ae945505a56356bb598df3.jpg

     

    Cable installed:

    20181110_114230.thumb.jpg.a77c758b44d6d386968d29dce56d7398.jpg

     

     

     


  14. Ethernet length
    A novel way to massively improve the SQ of computer audio streaming
    7 hours ago, Johnseye said:

     

    Right.  If I incorporate a NUC as endpoint, which I'm likely to try now, I would use a 6" or 1' ethernet cable.  Likely 360 shielded.

    I would recommend against using such sort Ethernet cables, I have been doing a LOT of experimentation with Ethernet interfaces recently and found that many PHYs need a certain amount of capacitance on the pairs in order to work properly, a 6" cable just doesn't have enough. I had a situation where a 3ft cable worked fine, a 1ft was marginal (significant packet loss) and 6" did not work at all. I soldered some small value caps across the pairs and presto the 6" cable worked great. This tends to support the "not enough capacitance" theory.

     

    So going for very short Ethernet cables may not be a good thing. I personally would not go shorter than 2ft of cable between PHYs.

     

    Of course not ALL devices are going to have this problem, but I found it on a high percentage of the devices I was testing.

     

    John S.


  15. A novel way to massively improve the SQ of computer audio streaming
    A novel way to massively improve the SQ of computer audio streaming

    Big thanks to both @austinpop and @lmitche for this Gotham JSSG360 cable idea!

    I am slow in adapting this idea, but finally made the same cable, and think this is a great upgrade.  Now I need to find time making a 24pin ATX cable as well.

     

    Here are few detail pictures I took during cable making:

     

    Pins crimped:

    20181103_123856.thumb.jpg.b43e5c210ad70e85e59b44fe4f5bbd33.jpg

     

    Pins inserted to connector prior to heat-shrink cable shields:

    20181103_124526.thumb.jpg.c76c14b734e5de2a73353201d49a84d6.jpg

     

    Both cables completed:

    20181103_131648.thumb.jpg.73583169ee3ee644fb3a6ead62ef3fc9.jpg

     

    8 Pin cable installed:

    20181107_215725.thumb.jpg.e8f270dfeafecc13ba917e8708afbf63.jpg

     

    4 Pin cable installed:

    20181107_215742.thumb.jpg.db4ea38f68be5e8863ee5e1ef78e2326.jpg

     

     


  16. A novel way to massively improve the SQ of computer audio streaming
    A novel way to massively improve the SQ of computer audio streaming

    This would be my last guide on the AudioLinux GUI version.  If Rajiv find these guides useful, please put them in the index.

     

    Installation guide 5: Automount 

    Foreword:

    1. It is not necessary to do this guide.  If  you are using RAMBoot, and mount the drive interactively (as shown in the previous guides), and do not show down your AudioLInux (entirely possible because some NUC only runs at 10W)

    2. Wrong lines in the fstab file may make your USB disk not bootable.  So be careful.

    3. This example works if the file system of the target hdd is NTFS.

     

    This guideline is divided into 3 parts:

    A) Find the UUID of the local hard disk to be mounted:

    1. Click the icon to launch terminal

    Mount_A1_LaunchTerminal.png.6ab4f5cd630efff068b9a024e71b8af3.png

    2. Type blkid to find the UUID of the target hdd

    Mount_A2_FindUUID.thumb.png.7c686de3eb4e01d2d5b0e07a0db8a60c.png

    In this example, the target hdd is SLC_240 is the 01D....

     

    B) Update the file /etc/fstab

    1. Click the red folder  (Must be the red one, not the blue one)

    Mount_B1_LaunchRedFolder.png.17e817078ab273ae280de12ff16d9092.png

    2. Click computer

    Mount_B2_ClickComputer.thumb.png.5e644d19edab639e00d1bb41d1372514.png

    3. Click file system

    Mount_B3_ClickFileSystem.thumb.png.220304421c850785a3def421bd88d52d.png

    4. Click etc

    Mount_B4_Click_etc.thumb.png.aed94e8e7cf2f060165d5142e9e00716.png

    5. Scroll down, until fstab is found.  Click to open it

    Mount_B5_Edit_fstab.thumb.png.b5da4cd8e46698e6720fdca3639ef37a.png

    6. Update the fstab file.

    Mount_B6_Update_fstab.thumb.png.da2287858f57d6d62d4ea5ad1972ad46.png

    red part: subs. your own parameter for the value after UUID

    blue part: may be changed but not recommended.  Please refer to the official site for the details.

    orange part: should not be changed.

    Save the file.

    Reboot.

     

    C) Check

    Open the Start here folder.  Click samba (if the blue part wasn't changed) and check if files in your hard disk is being displayed.  Your screen should be different from mine.

    Mount_C_Check.thumb.png.103d14d0285535d0eed2de0db6501d0f.png

     

    * If the check if OK, then the auto-mount is successful.  Now you may use say, HQPlayer, to your music files.

     

    Enjoy.

     

     

     

     

     

     

     


  17. A novel way to massively improve the SQ of computer audio streaming
    A novel way to massively improve the SQ of computer audio streaming

    txUSBUltra with Gotham JSSG360 DC cable mod:

     

    After the success from replacing stock DC cable for sCLK-EX clock inside my PC with Gotham JSSG360 cable, my motivation for trying the same in txUSBUltra got extremely high, my curiosity is now well satisfied after some time spent this afternoon.  This cable once again has elevated my system with improved SQ and I would highly recommend to give it a try.

     

    Below are few pictures I took while doing the cable replacement.  Hopefully they will be useful if you plan on doing this mod as well.

     

    Stock cable and tx-USBhubIn removed:

    20181026_104822.thumb.jpg.25f21c64481dd1af0da0286bfaef4a61.jpg

     

     JSSG360 from sCLK-EX to txUSBhub installed:

    20181026_120828.thumb.jpg.5f85b9d568cb546948ba057651f6427d.jpg

     

    txUSBhub reinstalled:

    20181026_122359.thumb.jpg.c18eefafab8e3a06a96cedb4cccb90c8.jpg

     

    JSSG360 from external DC input to sCLK-EX installed, ready to reinstall back to original txUSBUltra enclosure:

    20181026_144628.thumb.jpg.cee5b55b8a4d33516568092163b74188.jpg

     

     


  18. A novel way to massively improve the SQ of computer audio streaming
    A novel way to massively improve the SQ of computer audio streaming

    A further update...

     

    I was able to obtain a NUC7i7DNBE motherboard today to compare against my NUC7CJYH.


    To compare the differences, this new board has a 4-core i7 running at a base frequency of 1.9GHz along with an 8MB SmartCache while my other board uses a 2-core Celeron with a base frequency of 2GHz and only a 4MB cache (not a SmartCache).  The new board uses an integrated Intel I219LM Ethernet controller while my Celeron board uses a Realtek 8111H Ethernet controller.  With the more expensive NUC, better parts are used.  Both boards utilize an SoC architecture meaning the integrated LAN and USB ports have direct, low latency access to the CPU similar to the PCIe bus.  The NUC7i7DNBE board has the capability of being internally powered via a 2X2 Molex connector whereas the Celeron board can only be powered via a 2.5x5.5mm barrel connector although at this time, I am powering the new NUC board via the same barrel connector as my Celeron board.

     

    My first order of business was to compare this more powerful i7 NUC against my even more powerful HP Workstation as a RoonServer.  Even though Intel suggests you can uprate the TDP of the i7 on the NUC from 15w to 25w, there is no way to do this in the BIOS and so it is probably something you have to do within Windows and so at this time, I am forced to keep this NUC at the 15w TDP setting.  The BIOS allows me to turn Turbo and Hyperthreading on and off.  I can also select "All Cores" or only "1 Core" as being active.  As  a RoonServer, both Turbo and Hyperthreading were turned on and "All Cores" were selected.  I also selected "Maximum Performance" rather than "Power Saving."  

     

    The Kingston HyperX RAM that failed to work in my Celeron NUC somehow works fine in this i7 NUC and so it would appear there is a compatibility issue with this particular HyperX RAM and the Celeron NUC even though both the HyperX and Ballistix memory are 1.2V DDR4-2400 SODIMMs.  Just like with the Celeron NUC, I have elected to use only 4GB of memory with this new NUC.

     

    There is a BIOS setting that allows only "trusted" OS's to boot.  This needs to be unchecked, otherwise, the AudioLinux USB stick fails to boot.  With this setting unchecked, AudioLinux and RoonServer boot into memory just fine.  When compared against my Celeron NUC as RoonServer, the improvement in SQ with this i7 NUC is immediately evident.  The thinness is gone.  However, compared against my much more powerful HP workstation, the HP still sounds better overall.  There is a slight harshness with the HP possibly due to the more powerful and noisier hardware which includes a PCIe SSD but dynamics are better and more dimensional and tone is fuller.  The harshness isn't readily noticeable with my very best recordings but I suspect it could be fatiguing with certain tracks and with prolonged listening.  While this particular i7 NUC isn't powerful enough to satisfy as a RoonServer, it has now shown me that perhaps a higher power diskless (or at least SSD-less) RoonServer is indeed the way to go.

     

    I then assessed the i7 NUC as a Roon endpoint.  The first thing I did was to assess this NUC with "All Cores" turned on versus only "1 Core."  With only a single core operational, this core now gets the entire 8MB of SmartCache to itself.  Well, "All Cores" sounds better than "1 Core" and so it would seem that RoonBridge is a multithreaded app and that the ability to parallel process among multiple cores is more important than having a big cache.

     

    I then compared Hyperthreading and Turbo "off" vs "on."  The difference is more subtle but to have Hyperthreading and Turbo turned "off" sounds better (smoother) and so they were kept off.

     

    With the i7 NUC compared against the Celeron NUC as a Roon endpoint, I"ll cut to the chase and state the i7 NUC is better.  Tone is richer and fuller and more dimensional.  There is also a more effortless quality to the presentation of the i7 NUC.  Here's the problem, this i7 NUC board cost me $530 while the Celeron NUC board cost only $120.  Is the i7 NUC worth more than 4X the Celeron NUC?  Because the Celeron NUC already sounds so darn good, I could make a case for sticking with the Celeron NUC.  At the price point of the Celeron NUC, I am not aware of a product that performs anywhere close to it, however, for those looking for that last ounce of extra performance, I'm sure there are those who will find the i7 NUC to be worth the extra expense.


  19. A novel way to massively improve the SQ of computer audio streaming
    A novel way to massively improve the SQ of computer audio streaming

    A further update...

     

    Larry was kind enough to send me updated USB sticks (one with RoonServer and one with RoonBridge) for testing.  They are a noticeable step up in SQ compared to the original USB stick he sent me.  Someone asked how this compares to TLS's Dream OS.  The version of TLS's Dream OS I have is older and is not headless (it has a GUI) while Larry is using the latest headless version of AudioLinux which further incorporates his own tweaks and so Larry's version is quite a bit better.  TLS's Dream OS, however, has been updated/improved by Adrian in the recent months (I don't have Adrian's latest version) and so the latency figures he posted on his site will undoubtedly be improved upon once his DS-1 starts shipping.  

     

    I have tried running my Celeron NUC with 4GB vs 8GB.  I am unable to detect any meaningful difference in SQ between either configuration.  Larry did some testing and found the latency figures were the same with 1 RAM stick vs 2.  There's certainly no reason to spend the money on 8GB of RAM.  

     

    I am currently using Crucial's Ballistix DDR4 which is slightly lower latency than their standard offering.  This only cost $7 more than their standard RAM and so I figured, why not.  I have not done any A/B comparisons with Crucial's cheaper RAM to know if this sounds better although I just purchased Kingston's HyperX DDR which is even lower latency than the Ballistix DDR4 to compare against.  Unfortunately, either this memory is defective or it is incompatible.  I can't get it to run and so back it goes.  I can vouch that Crucial's Ballistix DDR 2400 works fine and sounds great.

     

    I then tried Larry's latest USB stick with RoonServer on my Celeron NUC.  This enables the Celeron NUC to function as a single box RoonServer + renderer.  Just like with my other NUC, this did not sound great.  If you don't compare, you can fool yourself into thinking this sounds good but as soon as I move RoonServer back to my Mac Pro and allow the Celeron NUC to function purely as a RoonBridge, it becomes easy to hear that the Celeron NUC as a single box server/renderer sounds thin and strained.  Roon most definitely benefits from distribution of tasks across multiple machines.

     

    Unfortunately, I have not been successful in running headless AudioLinux on my Mac Pro and so I turned to my HP Z820 Workstation.  This PC incorporates an 8-core 3.4GHz Xeon with 25MB of SmartCache and 150w TDP as well as 32GB of RAM and fortunately, I was able to successfully run headless AudioLinux + RoonServer completely in RAM with this monster PC.  As I posted previously, when I used my older Celeron NUC with TLS's Dream OS as RoonServer and my newer "Larry" NUC as RoonBridge, transients sounded fast and snappy but the sound signature was thin, even with my SR7 powering both units.  With my Mac Pro as RoonServer, sound was fuller and richer and was easily the better sounding RoonServer machine.  This has led me to buy into Pink Faun's premise that for your RoonServer machine, "more is more."  

     

    As good as my Mac Pro sounded as my RoonServer, the HPZ820 workstation running AudioLinux + RoonServer in RAM simply sounded better.  A LOT BETTER and it was one of those OMG moments!  Deeper, richer tone with better dynamics, better bass, better transients, better separation and better articulation.  Bingo!

     

    I will next try an i7 NUC to see how it competes against my much more powerful HP Workstation to see if there is a drop off in SQ.  At this point, I'm not sure where the sweet spot will be for a RoonServer but at the very least, I now have a new SQ benchmark that is considerably better than anything I have ever heard in my system.

     

    At this time, this is what I would suggest for those who are interested in following this path:

     

    High power server > bridged LAN > reclocked switch > low power NAA 

     

    Instead of a switch, Larry is using WiFi and he is pleased with it and so that may be a good option also.

     

    Some have PM'd me regarding the use of players other than Roon.  At this point, I have only tested Roon.  Roon is ideal since it allows you to distribute tasks among multiple machines and I believe that to be key here.  Ideally, you want both a high power and a low power computer with the 2 isolated by a really good switch and with a bridged LAN connection isolating these devices from outside traffic.  At this point, it remains my belief (and I'm happy to be proven wrong) that x86 CPUs (either Intel or AMD) are where it's at.  I simply haven't heard an ARM-based machine sound this good.  As previously stated good power is paramount.  While I'm sure high-level clocking will add to the goodness, right now, the only high-level clocking I have is in my switch and yet, this sounds simply superb.  


  20. A novel way to massively improve the SQ of computer audio streaming
    A novel way to massively improve the SQ of computer audio streaming
    22 hours ago, seeteeyou said:

    And then the BEST part is an internal (lower impedance) Molex connector in addition to an external (higher impedance) DC connector, therefore it should be easier to try power cables with higher gauge number / lower resistance.

     

     

    Whoa, thanks for bringing this up!  Larry and I had been discussing trying out the Intel NUC7i7DNBE board as a RoonServer:

     

    https://www.intel.com/content/www/us/en/products/boards-kits/nuc/boards/nuc7i7dnbe.html

     

    I actually selected this particular board purely because it is only 1 of 2 i7 NUC boards that Akasa is making a fanless chassis for at this time.  This is a commercial class NUC board and as you stated, it accepts 12-24V but what is more important to me and what I didn't realize until you brought it up is that this is one of only a few Intel NUC boards that can be powered via a 2x2 Molex connector which is a better alternative to the high impedance 5.5mm x 2.5mm barrel connectors that most NUCs and small audio endpoints use. 

     

    22 hours ago, seeteeyou said:

    NUC7i3DN and NUC7i5DN came with only 1.5MB cache per core, and we're still getting 2MB cache per core from NUC7i7DN.

     

    This is not entirely accurate but the news is good.  The NUC7i3DN and NUC7i5DN you mentioned above actually incorporate 3MB of SmartCache.  Probably for cost reasons, most Celerons and budget CPUs incorporate L2 or L3 caches that are not SmartCaches which means the 4MB of cache used by the Celeron J4005 CPU in my NUC shares this cache evenly among its cores.  Since this is a 2-core Celeron, then each core gets 2MB of cache.  If only a single core is being utilized by an app, that core can only access 2MB of cache and not the entire 4MB. 

     

    The advantage of Intel's SmartCache is the entire cache can be used by whichever cores are active and so with a single-threaded app that uses only a single core, that single core now has the potential of accessing the entire cache.  With the NUC7i3DN or NUC7i5DN, this means a single core can access the entire 3MB of cache and generally speaking, the larger the cache, the lower the CPU latency.  With the NUC7i7DNBE board I have been eyeing, the i7-8650U CPU that it utilizes has a very healthy 8MB of SmartCache!

     

    What is further appealing with the NUC7i7DNBE board is that the CPU's TDP can be downrated to 10w just like my current Celeron NUC.  What I am hoping is that SpeedStep and Turbo can also be turned off through the BIOS.  If this is possible, this would allow me to very closely mimic the Celeron CPU in my NUC but with a much larger and smarter cache.  This would mean that this board could be well suited as both a RoonServer board and a RoonBridge board.  As a RoonServer board, as this board has the capacity for 32GB of RAM, it should be possible to store both the entire OS as well as the entire Roon database in memory allowing for a completely diskless RoonServer.  Obviously, this would mean you would need a NAS to store your music files but at this time, this is my preference anyway provided I have access to a good network switch.


  21. SOtM
    A novel way to massively improve the SQ of computer audio streaming

    @flkin  - thanks for your valuable impressions of the Pink Faun 2.16 and Antipodes CX/EX servers.

     

    And Roy, it's always fascinating to hear about your continuing saga! I feel you and Larry are on track to unlock another "massive" leap in sonic performance.

     

    23 hours ago, romaz said:

    During this time, I also had access to SOtM's latest sMS-200ultra Neo.  When I last owned an sMS-200ultra, it was before I owned the Ref10 and so I felt it was important to revisit the latest incarnation of the sMS-200ultra to see how it would compare to the NUC.  As a similarly small device designed from the ground up for audio, I always felt these types of devices should rule the world.  WIth the sMS-200ultra Neo connected via Habst cable to my Ref10, even though I no longer had an original sMS-200ultra on hand for direct comparison, I very much liked what I heard and it was indeed better than what I recall my sMS-200ultra sounded like.  Where I felt the original sMS-200ultra sounded incisive, airier, and more detailed compared against my microRendu, there was a beguiling smoothness and naturalness to the microRendu that was also very pleasant.  What is interesting is that the ultraRendu has gone more in the direction of the sMS-200ultra and in some ways, sounds even more detailed and more mechanical whereas the new Neo has gone more in the direction of the original microRendu as it has given up some of its incisiveness for a harmonically richer and more natural sounding presentation.  In isolation and when powered by my SR7, my immediate inclination is that the new Neo is a winner and it definitely is.

     

    Comparison of sMS-200ultra vs sMS-200ultra Neo

     

    In the flurry of activity pre- and post-RMAF, I have not had a chance to report on a comparison Eric @limniscate and I did. We were able to compare the sMS-200ultra Neo (the same one Roy mentioned above) with Eric's vanilla unit. Both units have a reference clock input, so we were able to run both with a reference clock from the Mutec Ref-10. We did this in my system, so the chain was:

    • Vanilla: Router > TLS OCXO switch > Zenith SE (Roon Server) > TLS OCXO switch > sMS-200ultra > tX-USBultra > DAC
    • Neo:      Router > TLS OCXO switch > Zenith SE (Roon Server) > TLS OCXO switch > sMS-200ultra Neo > tX-USBultra > DAC

    In both cases, the sMS was running the Roon Ready application. The nice thing about this test is we did not have to rely on auditory memory to do this comparison; we were able to A/B them in real time.

     

    Sure enough - there is a difference in sound signature between the two. I would not characterize this as a large, knock-your-socks-off difference. But certainly, SOtM have managed to alter the tonality of the Neo to be mellower, and not as "bright." I think Roy is spot on when he says it's reminiscent of the smoother tonality the original mR has. The Neo has smoother treble, and slightly improved lower mids and upper bass. As I said, it's reasonably subtle, but very welcome. 

     

    The second finding is even more interesting. May had suggested I try their beta firmware, where they have a new kernel that they have tweaked. She wouldn't (and hasn't) tell me what exactly has changed, but I have to say, I felt the beta version sounder better for sure. In fact, it seemed to be doing the things Roy and Larry are reporting with their experiments - more dynamic and more expansive.

     

    If you want to try it - AT YOUR OWN RISK, obviously -  here are the instructions from May. I strongly recommend you make a backup of your SD card before you do.

     

    1. Go to the following link

      URL: <your eunhasu ip address>/beta.php

    2. Enable the Beta server and save.

    3. Go to the Eunhasu upgrade page.

      URL: <your eunhsu ip address>/upgrade.php

    4. Click the kernel check. After that, reboot the device and test.

     

    After testing,

     

    5. Go to the beta page again.

      URL: <your eunhasu ip address>/beta.php

    6. Disable the Beta server and save.

    7. Reboot the unit and use.


  22. A novel way to massively improve the SQ of computer audio streaming
    A novel way to massively improve the SQ of computer audio streaming

    @flkin, thank you for taking the time to report your findings in great detail.  Your data points, especially against the Antipodes CX+EX, are of great interest to me personally.  Ultimately, it is how one component compares to another component that I find the most valuable perspective and you did that very well!  

     

    Based on your initial favorable comments about the Pink Faun 2.16 some months ago,  I had phoned Pink Faun in the Netherlands to try and better understand their philosophy.  I want to say that I spoke with Jord but I can't remember for sure.  Regardless, we spoke for nearly 1.5 hours and I came away intrigued by their approach.  Here were my main takeaways:

     

    1.  Because upsampling with HQP is a key component to their 2.16 server, they believe that more power (and not less power) is better because "faster" = lower latency.  This appears to be Sound Gallerie's approach with their SGM 2015 (and now, their new SGM Evo) and so if a comparison is to be made, ideally, it should be against the Evo.  Having heard how good the SGM 2015 sounds, I think they have made a good case for this "more is more" approach.

     

    2.  Unlike everyone else, Pink Faun feels AMD sounds better than Intel which is why they went with the specific 8-core AMD CPU, chipset and board that they did.  Based on your own favorable comparative assessments of the 2.16, it would appear that their decision to go in this direction has been well founded.

     

    3.  The 2.16 can incorporate up to 6 independently powered OCXOs depending on the buyer's preference (CPU, chipset, LAN, USB, SPDIF, I2S, etc).  Wow.

     

    4.  The 2.16 has the potential for up to 20 linear rails of power (depending on the needs of the user) coming off of 2 large transformers.  Moreover, the power supply has an energy storage capacitance of >800,000uF.  This is more storage capacitance than my Soulution amplifier!  There was a time when I thought something like this was overkill but not any longer.  There's a reason why a Paul Hynes SR7 sounds better than an SR4 for a tiny component like a tX-USBultra that barely draws a few watts and according to Paul, it has to do with having plenty of overhead so that the supply is always operating within its optimum power band.  Unless it's a typo, it looks like the new Sound Galleries Evo will have a storage capacitance of 3.76 million uF.  Let the server PSU wars begin.

     

    5.  The 2.16 consumes 100 watts at idle and runs fairly warm and so it requires a well ventilated space.  Because the OCXOs need to be kept heated to sound their best and because it can take a long time to heat up the OCXOs, the 2.16 should ideally be kept constantly running.  I don't think the 2.16 is going to win any "eco" awards.  This is a legitimate concern and probably the biggest downside of the 2.16 for me since my equipment is stored in a cabinet.

     

    6.   Pink Faun is presently testing their own low-power mini streamer based off an ASUS Tinker Board which is even smaller (and potentially lower latency) than a NUC.  This streamer will have both USB and SPDIF output capability and can be powered by a 5V/2A supply.  Color me intrigued on this device.  At the time of my conversation with them, there was no word yet on how good this sounded.

     

    Now, taking into account your own findings, it would appear the 2.16 is the best server you have heard/owned to date and you certainly have put it against some tough competition.  Here are a few of my own recent findings and comments and so perhaps, I can add to the body of information that could help the community at large.

     

    @lmitche was kind enough to configure a low power NUC for me with his optimized version of headless AudioLinux running on it (thank you, Larry!).  The model I purchased (NUC7CJYH) cost me $120 and incorporates my preferred J4005 2-core Celeron with a 10w TDP and a 4MB L2 cache (2MB of cache per core).  My previous NUC had only 1MB of cache per core.  This particular model has no eMMC drive and so once AudioLinux boots into RAM via a USB stick, Larry configured it so that I can remove the USB stick and so this is a completely diskless NUC endpoint running RoonBridge.  Where my previous NUC's OS consumed 5.8GB of memory, this more compacted version of AudioLinux consumes <3GB of memory.  Most would assume that this NUC should sound better than my NUC and indeed, that is correct.  The improvement is considerable and so kudos to Larry.

     

    During this time, I also had access to SOtM's latest sMS-200ultra Neo.  When I last owned an sMS-200ultra, it was before I owned the Ref10 and so I felt it was important to revisit the latest incarnation of the sMS-200ultra to see how it would compare to the NUC.  As a similarly small device designed from the ground up for audio, I always felt these types of devices should rule the world.  WIth the sMS-200ultra Neo connected via Habst cable to my Ref10, even though I no longer had an original sMS-200ultra on hand for direct comparison, I very much liked what I heard and it was indeed better than what I recall my sMS-200ultra sounded like.  Where I felt the original sMS-200ultra sounded incisive, airier, and more detailed compared against my microRendu, there was a beguiling smoothness and naturalness to the microRendu that was also very pleasant.  What is interesting is that the ultraRendu has gone more in the direction of the sMS-200ultra and in some ways, sounds even more detailed and more mechanical whereas the new Neo has gone more in the direction of the original microRendu as it has given up some of its incisiveness for a harmonically richer and more natural sounding presentation.  In isolation and when powered by my SR7, my immediate inclination is that the new Neo is a winner and it definitely is.  However, in comparison, I still found my NUC to be better and not by a small margin.  If I were to provide 2 descriptors that sum up what this NUC offers, especially when powered by a DR SR7 rail, it is "presence" and "energy."  It was this same presence and energy that drew me to the Innuos Zenith SE and now draws me even further with this NUC.

     

    But here is where things get interesting.  As I previously reported, I found my best SQ when this NUC was used purely as a Roon endpoint (renderer) while server duty was taken over by a separate server.  While this NUC was capable of full server and endpoint duty and while playback occurred smoothly, SQ sounded strained.  While my Zenith SE filled the bill very nicely as a RoonServer, when I placed SOtM's new sNH-10G network switch between my RoonServer and Roon Endpoint, it no longer seemed to matter what I used as a RoonServer.  In other words, my unoptimized Mac Pro with its noisy 12-core Xeon, 64GB of RAM, dual GPU, and 1TB of PCIe SSD storage sounded just as good.  If there was a difference, it was too small to worry about it.

     

    WIth my 2nd NUC in hand, I now had the luxury of trying my original NUC as the RoonServer.  Even though I couldn't hear much difference between Zenith SE and Mac Pro as RoonServer, would this NUC running AudioLinux in RAM result in an improvement?  Of course, with only 8GB of memory, there isn't much room for any kind of a Roon database and so I configured this NUC for Tidal streaming only through Roon.  Even with the lower latency you get by running your OS completely in memory, there are definitely latency penalties by using a Celeron vs a 12-core Xeon when it comes to all the tasks that RoonServer is responsible for.  For example, browsing through my Tidal library occurred much more slowly through the NUC.  Nonetheless, it is SQ that matters and here is what I found.

     

    With my original NUC powered by a 12V rail from my SR7 and functioning as RoonServer and with my new "Larry" NUC powered by a DR 12V rail from my SR7 and functioning as RoonBridge, transients had better snap and seemed faster.  However, with my Mac Pro functioning as RoonServer, there was better dimensionality with richer, deeper and more natural tone.  In this instance, the Mac Pro was sounding better overall than my NUC as RoonServer.  How could this be?

     

    A couple of thoughts...

     

    1.  I no longer have SOtM's sNH-10G switch in my possession as that switch is now with Rajiv.  While SOtM thought they would be shipping this switch by now, they are having difficulty procuring enough chassis and so it remains unclear when their switch will be available and so I am presently using TLS's very fine switch but I don't think this switch isolates as well as SOtM's switch and so this may be accounting for some of the differences I am hearing.

     

    2.  When it comes to the heavy lifting required by RoonServer, I believe Pink Faun's philosophy is the correct one.  More power = faster = lower latency.  I continue to argue that with a "one trick pony" RoonBridge device, blazing speed and power are unnecessary and even unwanted and so I am very intrigued to see what Pink Faun's new Tinker board mini streamer will sound like but when it comes to RoonServer and especially if the user plans to upsample with HQP or employ DSP room correction, the more power the better.  The challenge with a high power RoonServer is they are more difficult to power well (just look at what went into the 2.16) and so there will be cost, energy, and heat considerations to take into account.

     

    I believe there is growing consensus from the likes of Antipodes and Pink Faun that for ultimate SQ, you need to distribute tasks between multiple machines.  In my current situation (without SOtM's switch), it would seem that both server and renderer matter and that attention needs to be paid to both which is an unfortunate bursting of my bubble, however, I continue to strongly believe that the renderer has the greater overall impact.  If I were to assign a level of importance, in the absence of upsampling or convolution, I would say the renderer has at least 80% impact while the server has at most 20% impact.  This bodes well because a good renderer costs a lot less than a good server and so I am hoping this observation stands the test of time.

     

    For those who plan to upsample or employ DSP-based room correction, I feel you have less choice.  If SQ is your top priority and if finances permit, then it would seem that the 2.16 should be on your short list but then so should Sound Galleries' offerings.  Otherwise, you might just find this cheap AudioLinux-based NUC to be the worldbeater that the audiophile community has been waiting for.

     

    A final word on convolution.  I have explored this with AudioVero's Acourate convolution software and I expect to explore it further because I do feel it has merit but there are consequences.  With the help of Uli Brueggeman from Germany, I was able to map my room and at various seating positions, we were able to determine my room's frequency response and where my nodes are.  He created idealized convolution profiles for me that I plugged into HQP and while I was able to effectively flatten my frequency response, it seemed to occur at the expense of harmonic richness and depth.  In other words, altering the audible frequency response of my room had an impact on the harmonic frequencies that was akin to trading accuracy for emotional impact.  The biggest negative was the soundstage became flatter.  The good news is that Uli is capable of creating graded profiles and so it's possible I will come across a profile I like.  The reason I bring this up is to highlight the pros and cons I have found with room correction.  If you're going to do it, definitely do it in the digital domain because with analog EQ, there will be resolution penalties but even in the digital domain, there are challenges.  If you employ it at the server level, then you will require a powerful server.  If you buy a device specifically designed for digital room correction like a Lyngdorf, DEQX, or Kii Three, then you're stuck with the DACs that are built in to those devices and thus far, I have not liked what I have heard.  If at all possible, I feel it's better to optimize the room rather than to digitally shape the sound but I also realize that this isn't always possible.  

     


  23. A novel way to massively improve the SQ of computer audio streaming
    A novel way to massively improve the SQ of computer audio streaming
    9 hours ago, auricgoldfinger said:

    I have a question for SOtM DIY experts:  Can anyone tell me the brand/model of the DC connectors shown in the photos?  I am looking for 2- and 4-pin versions.

     

     

    DC4_1.jpg

    DC4_2.jpg

    DC4_3.jpg

    DC4_4.jpg

    DC4_5.jpg

    Just got some time to reply, and John is right, this is a Molex SPOX 5263/5264 series connectors.

     

    Here is the link to the 2 pin connector housing:  https://www.digikey.com/product-detail/en/molex-llc/0050375023/WM18873-ND/280418

     

    https://www.mouser.com/ProductDetail/Molex/50-37-5023?qs=%2fha2pyFaduisWt94a8OgjEoApiagYBxbijA3U51rJRnIAZpTNTSgGg%3d%3d

     

     

    Here is the link to the 4 pin connector housing:  https://www.digikey.com/product-detail/en/molex-llc/0050375043/WM17405-ND/259392

     

    https://www.mouser.com/ProductDetail/Molex/50-37-5043?qs=%2fha2pyFaduisWt94a8OgjJMimFPCrw7mErdTKL70gj%2fU%2bOorLaCLjg==

     

    https://www.mouser.com/ProductDetail/Molex/08-70-1040?qs=sGAEpiMZZMs%2bGHln7q6pm%2bS0pk2Wo0XxlsVVgyOJ5xA%3d

     

     

    Here is the link to the crimp receptacle:  https://www.digikey.com/product-detail/en/molex-llc/0008701040/WM17406-ND/259393

     

    https://www.mouser.com/ProductDetail/Molex/08-70-1040?qs=sGAEpiMZZMs%2bGHln7q6pm%2bS0pk2Wo0XxlsVVgyOJ5xA%3d

     

     

    Here is the link to the Molex crimper (don't look at the price - ouch):  https://www.digikey.com/product-detail/en/molex-llc/0640160201/WM17552-ND/2074098

     

     

     

    image.thumb.png.6d258b3006c5ed7f9ec5698871632cb5.png


  24. HQPlayer
    HQPlayer Linux Desktop and HQplayer embedded

    Geoff,

     

    The process that I go through is to uninstall the previous one and install the new one.

     

    To uninstall run "dpkg -r hqplayerd"

    To install the new version it requires two commands.  The first one is to download the latest version of HQPe that appropriate for the OS you are using under and the install command.  If I remember correctly the version of Linux that you are running under WSL is Ubuntu Xenial.

     

    [For Ubuntu] wget https://www.signalyst.eu/bins/hqplayerd/xenial/hqplayerd_4.1.1-9_amd64.deb

    [For Debian] wget https://www.signalyst.eu/bins/hqplayerd/stretch/hqplayerd_4.1.1-9_amd64.deb

     

    To install the package "dpkg -i hqplayerd_4.1.1-9_amd64.deb"

     

    Doing that it will preserve your configuration but it does replace the hqplayerd.service file, which is not an issue under WSL since it is not used.

     

    @Miska, please correct if the steps listed can be improved on.  Also is it possible for the new package to ask if hqplayerd.service should be replaced or existing version can be left alone.  The reason for that is under Debian, I have to add a delay otherwise the hqplayerd bombs out due to network startup delay.  Anytime, I update the version of HQPe, I have to go back and edit the service file to add the delay back in.


  25. Long-time audiophile, but need "newbie" help here
    Long-time audiophile, but need "newbie" help here

     

    7 minutes ago, mansr said:

    For introductory information on a range of computer audio topics, I suggest http://www.thewelltemperedcomputer.com/

     

    I agree. I think Vincent Kars is a member here and on JRiver

     

    7 minutes ago, mansr said:

    That one is dead. A shame, really. I have rarely had such a good laugh.

     

    Still, always good to hear different viewpoints even if just to find out what is being claimed.

    In the interest of revisiting a  good laugh  ?......

     

    <quote>

    The Secrets and Obstacles of Computer Audio

    There are several factors that come into play when designing a computer-­based audio system. You have motherboards, form factors, CPUs, Chipsets, RAM, Cache, operating systems, vibration, cooling, software, threads, power supply configurations, versatility, benchmark performance, and user-­friendliness. All of these factors and then some ultimately play into the end result of your audio servers sound.

    Theoretically.

     

    A computer, in reality, is just a device used for crunching numbers. Our math wiz computer needs to be able to calculate algorithms in real time in the effort to make as few “guessing” errors as possible. Every application, process, and I/O operation acts based on a pre-­determined algorithm. Each algorithm takes voltage from the power supply and applies that to the digital square wave in order to create a transformed copy that can then be read by the next operation.

    The Brain: CPU

    The Central Processing Unit is the brains of the operation. Modern CPUs are a double-­edged sword and are actually so fast that they are limited by the other peripherals integrated in the system. With modern technology its not the clock speed thats the most important.

    The CPU has what’s called Cache. Cache is a special type of very high quality memory integrated into the die. Because the CPU is so fast the memory in the system just can’t keep up and a “wait state” occurs. This means the CPU actually has to wait for data to be loaded into memory before it can be processed.

    Think of it like an assembly line that never stops. The line is moving at 100mph, but because the memory is too slow the CPU has to stop working while it lets the assembly line passes by, which then requires that the same data be passed more than once and it increases processing time.

    This is where Cache comes in. Modern CPUs have three levels of cache memory. Level 1 memory is usually in the smallest quantities and is designed to be as fast as the CPU operations. Data is loaded into L1 cache very quickly so that the data can be processed in real time. L2 cache (and L3 in more modern chips) are progressively slower types of memory that are used for this same purpose and to prefetch data in order to avoid wait states. Better CPUs will have more L1, 2 and 3 cache memories. This is why not all 3.3ghz CPUs are created equal and are not the same price.

    Beyond having more Cache, more modern CPUs are smaller and more efficient. This means they generate less heat and are more power stable. This stability leads to less overall noise in the system and demand on the power supply.

    When you compare an Intel Atom board to a Core i5, or even a Core i5 to a Core i7, the sonic benefit comes from additional processor threads, more cache memory, and faster applicable clock rates. Because these new architectures rely so heavily on cache memory an Intel Atom board with a 1.8ghz processor, but less Cache is really only getting 1ghz of processor speed due to the wait states. A Core i7 vs a Core i5 of the same speed and number of Cores performs better because it has faster and more available cache.

    Number Crunching

    Even modern CPUs can’t crunch every number simultaneously. The more processor threads that can be dedicated to crunching numbers for audio algorithms the better the result. It’s like adding more lanes to a busy highway, more cars can simultaneously pass and more information can be processed at any given moment. Processing this information as quickly as possible is critical, because the longer it stays in wait state the more times it needs to be reprocessed and the more distortion that occurs. If you’ve ever had to do a mad minute in math class you know that finishing 500 problems in a minute by yourself is impossible, but having a team of people who all need to finish only 5 problems makes this process far less rushed and more accurate. This is what happens when you add more processor threads.

    Handshaking and Signal Path

    Audio, unlike other processes in the computer, is ideally real time. Applications themselves are not real time. An application has data stored both on the hard drive and in the registry pertaining to how it runs and operates. The processes created by this application are sent in packets that are buffered and checked for errors. If there’s an error the data is resent in order to prevent corruption.

    This is how hard drives work. Data on a hard drive is also send in packets that arrive perfectly in the receiving application. Once in the hands of the application the rest of the processing is real time.

    So why do hard drives make a difference?

    It’s not for the reasons you might think. The data stored on the hard drive is sent perfectly. However, it’s the moving parts that create issues. These moving parts generate spikes in the power supply that translate to quantization error. The moving parts also create micro vibrations that introduce higher order harmonics to the signal that shouldn’t be there. We use a solid state drive to avoid these spikes and the vibration, not because it’s any better at upholding file integrity.

    So now we’ve copied a perfect file off our hard drive and sent it to application number one. Our audio application does math for processing file types, organizing music, determining the layout of the graphical user interface, the volume, and how the data is actually processed. Every piece of DSP, or format will require some form of algorithm that transforms the square wave. A copy is made.

    The operating system itself then has a signal path that the square wave must then travel through. The more hands that touch the signal the more distortion that occurs. So companies go to great lengths to customize the operating system and shorten the signal path.

    Customizing the operating system

    An operating system is constantly running processes both in the foreground and background. Each process requires threads from the CPU core. The more threads a process uses the faster that process can be handled and the fewer wait states.

    The operating system can be customized in the effort to dedicate more threads to audio processes and applications thereby improving the speed at which those processes are handled and thus lowering distortion.

    Further customization is done by changing output devices in order to decrease the length of the signal path between audio application and output stage. Formats such as WASAPI, Kernel Streaming, and ASIO are a few examples of such drivers that allow a user to bypass Windows’ internal audio architecture. This takes several stages of processing out of the way and provides a much cleaner signal.

    Latency and the delayed battle

    Latency is caused by wait states. This latency causes both quantization error and jitter and it’s desirable to avoid it at all costs. Many people confuse latency with just an output delay and only consider it a problem when trying to sync an output in real time.

    This is not the case. Latency and buffered delay are two separate subjects. Latency is bad because it’s caused by the processor’s inability to keep up with the demands of the processing that needs to be done so it falls behind and needs to try over a longer time period to keep up.

    This is why several programs have introduced memory playback.

    Memory Playback

    Memory playback is a buffered delay. Data is loaded into memory before the processing even begins in the effort to give the CPU a head-­start. This helps to eliminate wait states in that single application. This treats RAM as cache and allows the system to pre-­fetch information to be processed. Implemented only in some circumstances, memory play also functions to load the song into memory so that all processes can be done in a single location. So rather than loading into memory to process volume, then to process DSP, then to process output algorithms the song is moved into memory where all of those processes are handled simultaneously before being moved on.

    Ripping and File Formats

    Many folks who transition to computer-­audio have a collection of CDs that they now want to store in an easy-­to-­access database. There is an abundance of ripping wares out there on the market that allow a user to insert a CD and rip it to a file format of their choice.

    People tend to get hooked up on bit-­rates and file formats, but rarely understand the reason for doing so. The best sounding format will be the native format the file was recorded and bounced at. If the file was recorded at 24/192 and bounced as a WAV file, that’s generally the format you want to listen to. But we usually don’t have access to that file, we have conversions of various files and it becomes a congested mess of what to choose. Let’s filter it a bit.

    A digital signal may be ones and zeros, but it’s still an analog square wave. I need to emphasize that it’s an analog signal comprised of pulses that a device translates as digital, but it’s still stored as a wave. This is important to understand because a wave that portrays a one or a zero isn’t necessarily going to look identical to its next-­door brethren. This is due to quantization error and amplitude distortion. If there is noise on a system there is amplitude distortion on the digital square wave. That distortion gets stored on the file on that wave.

    Error Correction

    Error correction is somewhat of a misnomer. Error correction uses the processes of interpolation (drawing a line between peaks and guessing at the numbers in between) in the effort to fill in missing data. When a piece of software says you have an error-­free rip its just saying that every one that was read is supposed to be a one. This does not take into account amplitude distortion inherent on those square waves.

    Every error-­correcting algorithm will process the data differently. Because its an algorithm it is taking power from the power supply to generate a new wave form that is then stored on the computer. This means that every algorithm sees a data point and will process it slightly differently resulting in different levels and positions of quantization error based on the error already contained on the file. A better algorithm will create a better result, but it’s still heavily tied to the power supplies ability to create a new wave.

    Format conversion

    There are rumors that say converting a file from one format to another can make it better. Oversampling a file can certainly create a version that was created under a magnifying glass, which inherently means interpolation is more accurate. But the more times a file is converted the more algorithms will change its properties. Of course, file formats such as MP3, FLAC, AIFF, and WAV are set with exacting standards and algorithms so the differences created through conversion will be minimal and more reliant on the software engine than the file itself.

    A piece of software may have better algorithms for processing WAV than it does for processing MP3 or FLAC.

    When ripping a file from a CD it’s usually best to rip it at its native format or at a higher sampling frequency. Higher bit-­rates may make you feel like the file is higher resolution, but that requires additional interpolation and will give mixed results. The less guesswork the better.

    It’s more important to consider the speed and processing power of the system rather than the file format. If you have two identical pies, one cut into 24 pieces and one into 16 pieces if there’s no damage to either pie they’re still identical. If there is damage the proportion of that damage will be larger in the 16-­bit file, but higher resolution comes with more power requirements and obstacles.

    The Spine

    The performance of a music server revolves around more than just the specifications of the CPU. There’s a power supply, the motherboard, the RAM, video cards, sound cards, and various technologies that connect them all together.

    The Power Supply

    Arguably the most important piece of the music server is the power supply. The bandwidth of the power supply directly correlates to the resulting sound of the system. Digital is impacted by much higher frequencies of noise than analog systems due to the concept of quantization error where frequencies above the clock rate are folded over into the base band and cause amplitude distortion on the square wave. While error correction and interpolation can estimate whether a one is a one or a zero a zero, it cannot correct the amplitude distortion on the square wave that gets imprinted on the file. Every process that runs on the computer takes power from the power supply (and any noise imprinted on it) and applies that voltage to create the new digital signal based on an algorithm. So where a faster CPU allows for less mistakes, the power supply prevents the CPU from coloring outside the lines. A power supply that generates noise or is too low bandwidth will do more harm than good in a computer-­based audio system.

    The Motherboard

    The motherboard connects everything together and plays a huge role in the sonic results of the audio system. It determines the chipsets, the length of the signal path, the expansion capabilities, and ultimately how stably the system can run. The parts used on the motherboard also play a huge role. A lower ESR part will mean it’ll have a higher bandwidth and be better suited for filtering the PWM signals sent throughout the motherboard. Shielding of the motherboard and heat isolation is a feature in higher-­end motherboards.

    Expansion Cards

    Graphics cards and sound cards may not be something everyone considers as an upgrade to an audio system, but they are important for several reasons you may not have considered. The first reason has to do with memory allocation. When the CPU and integrated peripherals have to process audio and video signals, cache memory from the CPU gets shifted to video and audio processes. This means there’s less memory that can be dedicated to specific threads, and we want to be able to control that. Modern graphics cards have built in cache memory and just by adding a graphics card to the system you free up considerable resources for the CPU to advantage of. This is the case whether you are running video-­heavy applications or not, even if youre running headless. Video processes occur even if you are not using a monitor and just because you cant see it doesnt mean theres no data being processed.

    Sound cards are a similar animal, but more important. Like a graphics card a sound card will have built-­in memory that it can allocate to processing audio signals. A sound card allows hardware acceleration to boost the speed and power at which a CPU can process a signal. Beyond that, a good sound card will have sophisticated buffers and clocks built in along with video sync capabilities so that both graphics and sound cards can communicate. This provides ultimate performance where all links in the chain do what they’re best at, but communicate with each other to create the best signal. Buffers and high-­end clocks in these sound cards helps to eliminate jitter and allows for the implementation of more advanced software algorithms and technologies.

    RAM

    You want to have the fastest memory you can possibly get. The faster it is the more closely it will be able to keep up with CPU operations and the faster the CPU will be able to access data. More memory isn’t all that important as most applications, outside of audio/video rendering applications, don’t store much data in memory for any length of time.

    Noise

    One of the biggest concerns with computer audio is being able to navigate all of the EMI radiated from the motherboard. But the EMI radiated from the motherboard is actually one of the lesser evils that plague computer audio systems.

    Noise is any signal we don’t want. Because we are playing back audio signals in the 20hz-­20khz range anything outside of those realms can be considered noise. In digital audio there are clocking frequencies in the mhz range, which means that any frequencies above that are susceptible to fold-­over and quantization error. This noise generates additional harmonics and data that doesnt exist on the recording and imprints it on that signal.

    Noise is a voltage. This is why it’s generally measured in uV. While this may be a trivial voltage compared to the voltages running through an audio signal, when you have several uV being added every microsecond from different sources it adds up in a hurry. These uV add and subtract from the voltages on the digital signal so a 3.3V (one) becomes 3.2V or 3.4V or greater. This slight variation in noise doesn’t confuse the system away from thinking it’s a one, but that amplitude distortion and timing confusion gets imprinted on the digital signal and translates to added harmonics.

    Every digital signal contains timing information, amplitude information, and channel data. That information gets imprinted on the square wave that is then read by a computer. The imprint is created in spite of noise, which distorts that imprint that’s created.

    Noise comes from all places. It can be high frequency noise caused by wireless interaction, it can be light, vibration, heat, resistance, or any number of elements.

    Heat

    Let’s talk about heat because it’s one of the more obvious and common issues in a computer-­based system. More heat causes system instability. The CPU often will decrease clock rate to compensate for this heat, which translates to slower processing speed and more distortion. Heat increases resistance, which in turn decreases bandwidth. The lower bandwidth also translates to more noise. At the extreme end, heat can damage components and render them non-­functional.

    Vibration

    Vibration is another element often considered in computer audio. Macrovibration generally won’t impact any signals because it occurs in the base band and the amplitude of such vibrations are so great that they’re easily rejected or filtered out by a component’s algorithms. Microvibrations on the other hand are a bigger issue.

    Vibrations are generated both by the component and by external sources. You want to isolate from both places.

    Squishy surfaces are a good start, but they don't have a high bandwidth so they are limited in how effective they can possibly be. They won’t isolate above their resonant frequency in most cases, which is generally low and where it’s most important. They may give the impression that they "float" better, but that's only to macrovibration. The microvibration I'm talking about is not detectable by putting your hand on a chassis and is created by electrical signals flowing through components, higher harmonics, resonant frequencies, etc.

    It's similar to the concept of "you don't hear the noise until it's not there any more".

    It has to do with amplitude distortion. Vibration on vinyl is similar. The resonant frequencies of the cartridge and needle are important because any vibration would distort the vibrations picked up by the needle. This is why many vinyl rigs sound exaggerated in one direction or another. Those vibrations and the coloration created from them determine the sound of the vinyl rig. That's why a high-­end turntable is so expensive, it is designed to isolate from vibration to avoid this amplitude distortion. The difference is that analog is impacted by both macro and micro vibration whereas digital is not.

    In a computer not only is there vibration caused by hard drives, but there’s vibration from fans, external devices, and the music itself. Isolating everything from these devices is paramount to great sonic performance.

    Power Supply Noise

    The ATX-­specification switchmode power supplies purchased with most modern computers are noisy monsters. Not only are switchmode power supplies limited in bandwidth by their switching frequencies, but the higher the switching frequency the more noise they generate.

    It is for this reason a linear power supply with a high bandwidth should be used. Core Audio Technology power supplies have an 18ghz bandwidth and have a slew rate of 5600V/uS. This means they have a very high bandwidth and are extremely fast. The additional speed allows them to react quickly to the transient demands of the computer system. The high bandwidth helps to eliminate fold-­over and quantization error.

    The voltage from the power supply is used to create every signal in the audio system. So any high frequency noise or ripple directly relates to distortion created by every single algorithm and process run in the audio system. Every process takes voltage from the power supply and applies it regardless of whether it’s clean or dirty. The cleaner the better.

    Putting it in the box

    Bringing these elements together is what creates the ultimate audio system. A server is the sum of its parts, cutting corners where it counts is a great way to end up with lackluster sound. The more technologies you tackle, the more expensive the system, but the better the results. So, check out some of our products and improve your audio system. 

    While some manufacturers propose specialty technologies that do things better than the rest, I don’t believe that’s actually a true statement. The only way to get the best results is to use multiple technologies that are best at their own element. By pairing them together you get the best of all worlds and create system-­wide harmony. Understanding how computer audio systems work is the first step to putting the pieces of the puzzle together. </quote>

     

     

    From <http://www.coreaudiotechnology.com/the-secrets-and-obstacles-of-computer-audio/>

     

     


×
×
  • Create New...