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

[gadgetman]

This is very interesting. I am always afraid this could happen and so I have resisted firmware upgrades with the sMS-200 because of fear that it could somehow impact my bridge which would be a tragedy. As far as I know, you can't roll back your sMS-200 to an older firmware because if I could, I would roll back to version 2.0 since that version allowed you to assign the sMS-200 a static IP!

 

Hi, newbie here.

You can do it only if you backup your SD card before updating to a newer version. Just download win32 disk imager. It's free by the way. Backup the SD card every time you upgrade to new version. This way you can test the SQ of each revision easily. Here is the download link:

 

https://sourceforge.net/projects/win32diskimager/

[gadgetman]

Thank you. Very helpful to know.

 

Hi Romaz,

 

You are very welcome.

[gadgetman]

Does any one know the ssh ID and password of SMS-200?

 

Using LAN Scan HD or similar on iPad to scan home network can reveal that SMS-200 has SSH enabled. Through ssh it's possible to assign a static IP to it to eliminate all the Ethernet bridging fuss. Especially now the SD card can be backed up, it's totally safe to mess around.

 

Any idea?

[gadgetman]

Regarding the ssh login account of Eunhasu, I've contacted May@SOtM. She gave me the information but said that it's confidential. So I'm not allowed to share it with everyone.

 

However May gave me a good news which I quote it here:

 

"and we are going to change the settings on Eunhasu to be able to make the Static IP."

 

She didn't mention when the new feature will be ready but let's hope it'll coming soon.

[gadgetman]

Wow, this is excellent news! Thank you for pushing for this. Now if only Sonore would do the same with the mR.

The credit belongs to you. It's your pioneer adventures and all others' efforts that make the manufacturer willing to change. Kudos to you.

[gadgetman]

I'm not all that clued up with networking, so what will enabling a static IP address on the SOTM achieve wrt a direct connection?

Both bridging and static ip can achieve direct connection. By applying static ip one can reduce another OS process in Windows/Mac which may be able to enhance the sound quality a little bit. Of course it's only theoretically speaking. It's not yet being confirmed.

[gadgetman]

Thank you tboooe for your quick response.

[gadgetman]

There's a way to bypass ssh to set static ip of Eunhasu. It's a little bit tricky and perhaps a little complicated.

 

First of all you'll need to backup the original SD card. Then make a copy and use the copy to do the test.

 

Secondly you need to download a free utility -- UNetbootin. It can help download and create a bootable USB drive of various Linux distributions including Ubuntu which I use.

 

Thirdly, you need a USB flash drive 8GB or more. Use UNetbootin to create a bootable Linux distribution.

 

Then insert USB drive into your computer and boot from it. Put the Eunhasu SD card in a card reader or the SD card slot of the PC. There's 2 files need to be modified.

SD_CARD/etc/sysconfig/network-scripts/ifcfg-eth0 and SD_CARD/etc/resolv.conf

 

Follow this link to change it.

networking - How to setup Static Ip in Fedora 19 - Stack Overflow

 

You need to have root permission to make the change. You can use "sudo" for temporary root accessibility.

[gadgetman]

I tested Eunhasu 0.3.3 today. Here's what I feels.

 

At first it seems the volume is been turned down one scale compared to 0.3.2. Then I realize that the depth is increased a notch. Each instrument seems to be seperated a bit more. There seems to be more micro detail now.

 

IMHO 0.3.3 is better than 0.3.2

[gadgetman]

Hi,

 

Where did you get 0.3.3, I'm keen to test..

 

Thanks

In system setup menu tap the middle icon which looks like a pointer going from left to right then goes straight up.

 

If you plan to roll back to your current version you better make a backup copy before doing software upgrade. You can use Win32 Disk Imager to do the job. It's totally free.

[gadgetman]

Thanks, I thought I was looking in the correct place, tried it and it says I am up to date on 0.3.2, I am running an sMS-200 from a Mac, would that explain why you see a later version?

Hmm, that's odd. It shouldn't be OS or machine dependent. As a matter of fact you should see a yellow pointer right at the System Setup menu.

 

What browser are you using? Have you tried google Chrome? Perhaps your browser or system security setting is blocking the update. Try using other browser or different computer.

[gadgetman]

This raises an interesting question?

.....Does anyone build and audiophile grade NUC like this? Mini PC Intel® NUC Kit NUC7i5BNH

That's exactly my audio server setup but with some further optimizations.

 

Here's my H/W configuration：Intel NUC D54250WYHK with Streacom NC2 fanless chassis powered by Keces DC116-19V/6A LPS. It's a shame that Intel changes NUC's mechanical outline for each generation. NC2 can't be fit for recent NUC. If you are into DIY then you can look for Akasa. They have plenty of chassis for you to choose from. Akasa Thermal Solution

 

Or you can just pick a complete set of fanless NUC from company like QuietPC. https://www.quietpc.com/sys-ultranuc-pro-6-fanless

 

For S/W part, I'm using Daphile. It's based on Gentoo and LMS. The entire S/W package is just around 200MB. It can be put in a USB flash drive and boot from it. Unplug the USB then you can boot your Windows from the internal SSD. Of course you have to configure PC bios to boot from USB first.

 

From what I understand the Daphile is not just another light weight Linux plus LMS. One of the major advantage is that the OS is Read Once Run Forever, meaning that the OS only needs to be read from USB once and loaded into system RAM then leave it there. Same mechanism for other software module. No further USB re-access is needed during normal music playback.

 

There's one great feature in the Daphile which is RAM play. You can load as many albums into RAM as you like as long as there's enough free memory. Again, this means there's no HDD or SSD access after the music is loaded into RAM. All this can reduce the current fluctuation caused by USB and HDD/SSD operation which is the main cause of SQ degradation on the music server.

 

Another function that this thread is talking about is network bridging. Daphile can auto-configure network bridge if you have 2 Ethernet ports. However this function is half complete. You have to configure sMS-200/mR the normal way befor connect to the bridge. After bridging sMS-200/mR is only recognized by Daphile. They are blocked to the outside world. But once you finished the configuration you just hook it to the NUC with direct connection. The Daphile will recognize sMS-200/mR without any problem. One hint to remember is that there's a boot sequence to be followed. Boot SMS-200/mR first then Daphile next.

 

I'm sure you'll find the SQ to be much better than any Windows or Mac OS.

[gadgetman]

Thanks for your input.

 

+1 for the DAPHILE's great quality (I am the DAPHILE's user too)

 

 

As you have experienced the network bridging with DAPHILE, I have 2 questions :

 

1. Do you think it will work if I hook 2nd DAPHILE PC (player) as the NAA in this way (bridged network) ?

 

2. Have you found any improvement in SQ hooking the NAA directly to DAPHILE's LMS ? (in comparison to the "normal" way)

 

Thanks in advance and nice day to everybody.

It's glad to know that you are one of the happy Daphile user too. I also noticed that you have a HydraZ in your audio chain. I own one too. Indeed, it's a good choice. May I suggest you to consider Mutec MC-3+USB if you plan to upgrade your DDC in the future. It's better than HydraZ IMHO. To further improve MC-3+USB's performance here's another option with great C/P value you can consider about.’´‚¸“xOCXOƒNƒƒbƒN Premium

As to Using NAA with Daphile, I believe that Daphile uses Squeezelite as the renderer only. NAA can't be cooperated with Daphile. So my answer to your questions is no.However if you ask me is there any SQ improvement hooking squeezelite directly to Daphile comparing to "normal" connection? Then my answer is a big YES!

[gadgetman]

Thanks for sharing this. Daphile sounds like a great option. Have you directly compared it against an optimized Windows 10 or Windows 2012 Server environment, especially with AO?

 

My only concern is that I'd have to give up Roon. Having to manage nearly 5k albums without Roon would be a real joy kill for me but I do like how you get Tidal and Spotify access + CD ripping capability.

 

Here's another optimized Linux option recently presented to me by someone and it has Roon capability, however, it's not clear if you can bridge your LAN ports with it:

 

HOME • Euphony Drive

 

Yes, it's a pity that Daphile isn't compatible with Roon. And unfortunately I don't have AO or similar to compare with. I use normal Win10 pro with JRMC. I too, like to know how it compares to optimized Windows or Mac.

 

The Euphony drive seems to be an interesting solution. But the flash drive only business model may scares some out. Nowadays we all like try-before-buy. That'll be grate if it has such program.

[gadgetman]

@ gadgetman

Thanks for your reply.

Sorry for misunderstanding, my question concerned Squeezelite, as a kind of "NAA" (a player hooked directly to the server), not really the NAA in the meaning of the HQplayer NAA.

So I am very gladit could be possible (and the SQ improvement is big :-) ), I will retry (because my test from some days ago was unsuccessful - maybe because of the boot sequence you are talking about).

 

Thanks a much for the Mutec & Cybershaft advice too, I will consider the try. Is the difference really worth it ?

 

PS

What do you mean by DDC ?

If you're not sure whether or not the bridge is working you can ssh into Daphile to check it. But as you may know that the ssh function is removed in the stable version. You can only do it on beta version. You can check the bridge and the other side of the bridge by using the following commands:

 

ssh daphile.local (or the IP address of your Daphile server) (login as root and password is "zaq" without quotation mark) then you can see a prompt looks like this:

 

daphile ~ # （then type the following commands)

daphile ~ # ifconfig br0 (if you see IP address of 192.168.128.1 then it's almost working)

daphile ~ # arp -i br0 (you should be able to see the IP address of eunhasu.local or renduplayer.local)

daphile ~ # ping -c 3 eunhasu.local (or IP address)

 

Regarding the SQ difference of Mutec + Cybershaft v.s. HydraZ, it's system dependent. While with my pre-Chord DAVE the SQ is a big step up. But using with DAVE I can hardly differentiate the difference. So YMMV.

 

DDC means Digital to Digital Converter, such as USB to SPDIF or the like can be called DDC.

[gadgetman]

As Romaz mentioned quite a few posts earlier that he thought the SQ of sMS-200 is better than mR which I totally agree. And that brings me wonder what could cause such difference?

 

H/W aside I would like to find out if there's any difference in the software. They both use heavily twisted Fedora Linux and they share the same features. It's curious to me what makes them to have such different performance. Here's what I did.

 

Enlightened by Romaz's network bridging I suspect if I can check the network latency of both products. So I conducted a simple and a rough experiment, using ping to check the round trip time of the network traffic. I've tested 5 packets, 10 packets and 100 packets. Seems to me that 5 and 10 packets are too few to have any meaning. So I list the test result of 100 packets in below.

 

System setup:

PC - NUC D54250wykh, internal 960G SATA SSD for music files, powered by Keces DC-116

OS - Daphile on USB

 

Network switch - Netgear GS108EV3

DUT - mR and sMS-200 powered by LPS-1

Music Album used: Carman Fantasies - Anne-Sophie Mutter both FLAC and WAV

 

Test Procedure:ssh into Daphile and ping DUT for 100 packets

 

 

Test Result:Network Latency - microRendu, S/W version : 2.3

 

1. direct connection through network bridge

 

No music playback

100 t, 100 r, 0 loss, 99157ms, rtt min/avg/max/Mdev = 0.333/1.298/2.820/0.697 ms

Play Flac from internal SSD

100 t, 100 r, 0 loss, 99156ms, rtt min/avg/max/Mdev = 0.304/1.204/2.676/0.616 ms

Play WAV from internal SSD

100 t, 100 r, 0 loss, 99149ms, rtt min/avg/max/Mdev = 0.258/1.211/2.499/0.622 ms

Play from RAM100 t, 100 r, 0 loss, 99156ms, rtt min/avg/max/Mdev = 0.258/1.196/2.773/0.641 ms

 

2. connected through network switch

 

No music playback

100 t, 100 r, 0 loss, 99147ms, rtt min/avg/max/Mdev = 0.412/1.116/2.883/0.562 ms

Play Flac from internal SSD

100 t, 100 r, 0 loss, 99151ms, rtt min/avg/max/Mdev = 0.323/1.419/2.987/0.700 ms

Play WAV from internal SSD

100 t, 100 r, 0 loss, 99147ms, rtt min/avg/max/Mdev = 0.354/1.300/2.985/0.683 ms

Play from RAM

100 t, 100 r, 0 loss, 99147ms, rtt min/avg/max/Mdev = 0.357/1.324/2.904/0.681 ms

 

 

Test Result:Network Latencies - sMS-200, S/W version : 0.3.3

 

3. direct connection through network bridge

 

No music playback

100 t, 100 r, 0 loss, 99134ms, rtt min/avg/max/Mdev = 0.211/0.305/0.386/0.042 ms

Play Flac from internal SSD

100 t, 100 r, 0 loss, 99139ms, rtt min/avg/max/Mdev = 0.266/0.351/0.547/0.045 ms

Play WAV from internal SSD

100 t, 100 r, 0 loss, 99134ms, rtt min/avg/max/Mdev = 0.222/0.333/0.428/0.033 ms

Play from RAM

100 t, 100 r, 0 loss, 99137ms, rtt min/avg/max/Mdev = 0.250/0.333/0.402/0.036 ms

 

4. connected through network switch

 

No music playback

100 t, 100 r, 0 loss, 99123ms, rtt min/avg/max/Mdev = 0.325/0.401/0.541/0.056 ms

Play Flac from internal SSD

100 t, 100 r, 0 loss, 99122ms, rtt min/avg/max/Mdev = 0.366/0.446/0.589/0.042 ms

Play WAV from internal SSD

100 t, 100 r, 0 loss, 99119ms, rtt min/avg/max/Mdev = 0.335/0.427/0.609/0.048 ms

Play from RAM

100 t, 100 r, 0 loss, 99138ms, rtt min/avg/max/Mdev = 0.320/0.434/0.517/0.040 ms

 

 

Perhaps it's not enough to make any conclusion. But the most interesting part is that mR's network latency is much higher than sMS-200's. And the differences of min and max of mR is way too large. On the other side, the sMS-200 did have very consistent and small latency.

 

By the way, in terms of network performance that Netgear GS-108EV3 looks pretty good. The added latency is quite low. May be it's because there's only 2 devices connected to the switch - PC and network streamer.

[gadgetman]

You may want to run traceroute on the daphile machine with both the microRendu and sms-200. You may find the microRendu packets take a different path.

Well, as expected, both mR & sMS-200 go to Daphile directly.

 

Does your mR stop by any place that it shouldn't.

[gadgetman]

That's good to know. I don't have have a microRendu, but whenever I read about latency and dropout issues I think it worthwhile to check the routing. I have had both Windows and Linux machines choose to route via routers several hops away even though they are directly adjacent.

 

Unexpected this is tough to check from the microRendu as you can't SSH directly into the box. Is there an SSH door on the sms200?

Yes, both mR and sMS-200 support ssh. I do have login info of sMS-200 but not mR. It's provided by May@SOtM. But she didn't want me to spread it. It's better you ask her in PM if you need it.

 

Or, you think of any further tests like me to do? Please feel free to tell me. I'd be glad to do it.

[gadgetman]

Your results are really interesting. I would expect any directly connected device to have a very short ping time. Even on my el cheapo i3 pc I use an NAA I get <1ms ping times, though for some reason, every 4th or 5th ping I get much higher times (4-5ms). My unsupported opinion is that there are major differences in hardware between the microrendu and sms200. I believe the usb implementation alone has to be very different because the microrendu uses the regen technology and power topology.

I agree there's some difference in h/w implementations. But I suspect it's in networking design. Sonore mR uses Solid-Run SOM which is based on i.MX6. The network performance is limited to 480Mbps max because of internal architecture. I suspect SOtM uses external Ethernet chip to achieve better effiency. May be @May could tell us more.

[gadgetman]

It would be interesting to hear the traceroute results to your daphile box from the sms-200. If nothing else it would confirm no router interaction.

OK. I'll do it sometime tomorrow. It's kind of late here now.

[gadgetman]

It would be interesting to hear the traceroute results to your daphile box from the sms-200. If nothing else it would confirm no router interaction.

The tracepath (name of traceroute in Fedora) shows only one IP address which is Daphile's.

 

Here is the ping results from sMS-200 to Daphile.

 

With switch

100 t, 100 r, 0 loss, 98999ms, rtt min/avg/max/Mdev = 0.355/0.419/0.486/0.035 ms

 

Without switch (direct connection)

192.168.128.1 (Ethernet port connected directly to sMS-200)

100 t, 100 r, 0 loss, 99000ms, rtt min/avg/max/Mdev = 0.295/0.338/0.424/0.031 ms

192.168.2.70 (Ethernet port connected to Internet)

100 t, 100 r, 0 loss, 99000ms, rtt min/avg/max/Mdev = 0.286/0.334/0.454/0.034 ms

[gadgetman]

Roy,

 

Thank you very much for your feedback. I really enjoy your every article and am always looking forward to your very thorough insight into each topic.

 

Back to sMS-200, by further investigating into it I realize that the CPU used is A20 from Allwinner. It's a dual core Cortex A7 ARM CPU. It needs an external Ethernet PHY which is Realtek RTL8211E. From Allwinner's linux-sunxi community it mentioned:

 

"For reliable Gigabit networking (1000Mbit operation), several sunxi devices require an important tweak that adjusts the relative timing of the clock and data signals to the PHY, in order to compensate for differing trace lengths on the PCB"

 

I believe that SOtM must have put a lot of effort in tweaking their Ethernet driver to come to it's present state. That may also explains why they prefer 100Mbps over gigabit at the early product stage.

 

I totally agree with your low impedance perspective. Yet I have some different point of view regarding the latency issue. The way I look at latency is a little similar to your view of CPU clock. It doesn't have to be the lowest but the consistent and predictable timing performance is one of the key factor to a good sounding system.

 

Another point that we all agree that could degrade SQ is the EMC interference. As we all know wherever electric current goes there's electric-magnetic field generated. It gets worse if the current fluctuates frequently. And as you said, which I couldn't agree more is, that "it is always better to prevent a problem or to address it at the source than to have to fix it downstream".

 

One way to achieve low current fluctuation is to use a fixed system clock. All that an audiophile music server needs is a steady and consistent operation without power saving nor hyper speed function. A fixed frequency system clock can do it just fine. And it is a unique feature in Daphile which I believe can improve the SQ quite a bit.

 

Based off the heavy lightweight media server belief, I'm very interested to give ROCK a try. I'll report back when I done the test.

[gadgetman]

For those of you wondering if ROCK is able to use 2 or more Ethernet ports or doubting if the direct connection between the Roon server and network streamer is achievable, worry no more! I can confirm that all is working well in alpha version, in a way.

 

Here's some pictures you can refer to.

 

I'll post the detail procedure later.

[gadgetman]

Before you decide to installing ROCK there are a few things you should know about.

 

First, ROCK can only be installed onto internal drive. Roonlabs suggests a ssd 64GB or larger. Please refer to this web page.

https://community.roonlabs.com/t/rock-hardware-primer/21756

 

Secondly, if you plan to put your music library in an internal drive. It will be reformated into ext4 partition. It's better you prepare a new drive. An existing one will do. But the system won't format it if there's already other partitions exist. You need to delete those partitions manually.

 

Thirdly, if you want to connect to mR or sMS-200 please refer to my previous post (post #687) regarding how to set up static IP of sMS-200. I haven't tried it on mR. But I think the process is quite the same. They both are based on Fedora Linux.

http://www.computeraudiophile.com/f10-music-servers/novel-way-massively-improve-sq-sms-200-and-microrendu-31110/index28.html#post635525

 

 

Lastly, before setting static IP for sMS-200 please make sure it's in Roon mode. And be sure to make a backup copy of the original SD card. Always use a copy version to do the test.

 

So here is my setup:

H/W : intel NUC D54250WYKH (8GB DRAM is preferred, larger will do but won't benifit), m.2 SSD (I happen to own a spare Micron MX200 M.2 256G SSD), Seagate 2TB 2.5" SATA internal HDD, USB3-to-Ethernet adapter (ASIX-88179 but I believe others will do), USB flash drive (4GB or more for installing ROCK). I use the USB3-to-Ethernet adapter to connect to my home router. The on board Ethernet is reserved for sMS-200.

 

Follow the link below to download and install ROCK. The installation is pretty straight forward. http://kb.roonlabs.com/ROCK_Install_Guide

 

It's better that you hook up a monitor the first time you boot ROCK. Take down the IP address then fireup a brower on another PC or tablet. Enter the IP address you see on ROCK. You'll be able to see a page similar to the 1st picture shown in previous post.

 

The next step is crucial to complete the setup. In the web page it shows missing codecs like the picture shown in below. Click the question mark and follow the instruction to download ffmpeg codec.

 

 

You can attach your USB drive containing your music files or copy music the way you put ffmpeg into ROCK but the destination folder is \Data\Storage\InternalStorage

 

Until now ROCK should be up and running. Start your Roon remote and connect to the IP addresss of ROCK. It's now working like your ROON core.

 

Connect ROCK and sMS-200/mR the normal way. Make sure the music can be playback normally. Then take down the IP addr of the Ethernet port which connect to your home router. Set static IP on ROCK and reboot to make sure everything works fine.

 

Assign static IP to another Ethernet port to be connect to mR/sMS-200. Be sure to set different IP segment for mR/sMS-200. ROCK won't boot if both Ethernet ports are at the same segment and mR/sMS-200 is connected. In case you set the IP address in the same segment you can unplug mR/sMS-200. Then you can link to ROCK again.

 

You can point the gateway and DNS server of the 2nd port to be the IP address of the one connected to your home router.

 

Finally, configure sMS-200 to use fixed IP. Then reboot the system. All done.

 

!!! Be warned. ROCK is still in alpha phase. It's unstable. Please take your own risk.!!!

[gadgetman]

Whoa! Possible game changer. How does it sound?

Just finished the setup. May need a few days to compare it with Daphile. But looks pretty promising.