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

[elan120]

31 minutes ago, sandyk said:

One obvious answer  to those concerned about the case temperature would be to reduce the input voltage closer to the minimum +7V if practical.

While this might be true for some products, but for etherRegen, according to the designer, it is not the case.  JS stated last year (below) almost no heat difference in relation to the range of input voltages, and my actual measurements between 7V and 12V input voltage show 104~106 degree F (40.0~41.1 degree C).

 

 

On 12/27/2019 at 11:23 AM, JohnSwenson said:

An EtherREGEN runs nicely at 12V, there is almost no difference heat wise from 7v to 12V so I would go with 12V it will pull less current from the supply, reducing any voltage drop across the DC cable from the supply.

 

John S.

[sandyk]

1 hour ago, elan120 said:

While this might be true for some products, but for etherRegen, according to the designer, it is not the case.  JS stated last year (below) almost no heat difference in relation to the range of input voltages, and my actual measurements between 7V and 12V input voltage show 104~106 degree F (40.0~41.1 degree C).

 

Clearly., you do  not have a problem like some, as 40.0~41.1 degree C is quite a low temperature (comfortably warm)  for most electronic devices You also need to take into account the Ambient Temperature at different locations.

 Unless it uses internal switching voltage regulators, then it should run noticeably warmer at the higher voltage unless it is in a well ventilated or Air Conditioned area when it is drawing >1A, even if the current draw is a little less at 12V.

7V at >1A is quite a bit of heat to dissipate in a small case (>7W)

 

[JohnSwenson]

17 hours ago, sandyk said:

Clearly., you do  not have a problem like some, as 40.0~41.1 degree C is quite a low temperature (comfortably warm)  for most electronic devices You also need to take into account the Ambient Temperature at different locations.

 Unless it uses internal switching voltage regulators, then it should run noticeably warmer at the higher voltage unless it is in a well ventilated or Air Conditioned area when it is drawing >1A, even if the current draw is a little less at 12V.

7V at >1A is quite a bit of heat to dissipate in a small case (>7W)

 

The EtherREGEN does in fact use a whole bunch(12) of very highly shielded very low emi switching DC-DC converters, each of which drives a carefully designed passive filter then into a linear regulator. This was the only way to run the power networks. Most of the current drawn is in the 1.0-1.2V range which would burn up linear regulators trying to drop the full range.

 

Thus the power dissipation of the EtherREGEN stays almost constant as you change the input voltage.

 

John S.

[cat6man]

On 4/8/2019 at 11:05 PM, austinpop said:

So far, I have tried

1. -b 2097152:2097152 -a 52428800:4::
2. -b 1048576:1048576 -a 26214400:4::
3. -b 524288:524288 -a 13107200:4::
4. defaults (nothing in the Euphony expert field)

 

Only 4. is glitch free. 

 

So the answer lies beyond.

 

 

 

resurrecting a path that's a bit old.

i have audio-linux running on a nuc, streaming to an opticalRendu

i've been using hqplayerd for a few years now with all processing turned off and found that moving the renderer off of the Rendu (just NAA) made a nice improvement, though most users use hqplayerd for upsampling/etc.

 

i recently upgraded my networking (ubitquiti edgerouterX to isolate streams related to audio) and power supplies all over the place (plus many many fewer wall warts)

so i thought i would revisit some previous assumptions.

a long time ago, i started streaming with logitech music server, on a ubuntu based nuc, streaming to a logitech touch with digital usb out to my DAC.......come a long way since then

 

previous, but recent, conclusions:

hqplayerd in ramroot on AL is really good with "older" AL builds (e.g. 140) and this sounds much better than the same configuration on build 250........who knows why

 

so, i decided to go back and revisit logitech/squeezelite and running on build 250 was meh running on USB but was outstanding running in ramroot, definitely competitive with hqplayerd on 140 (i need a lot more time to do more detailed comparisons).......hmm, what is going on here?  now my old experience with squeezelite had been without AL or ramroot, but together this is a contender.

 

next questions: 

would squeezelite on AL build 140 be even better?  i don't know as i'm having trouble getting the LMS server to install.........stay tuned

 

the above observations was made with the default buffering for squeezelite.

i next tried -b 2097152:2097152 -a 52428800:4:: in the config file and it sounded good (but different).....again, i apologize for not having more detailed observations yet...........i had expected, based on the above, to have glitches or other problems but i have seen none whatsoever.

 

therefore, why not keep increasing the buffers further and see where that road leads?

i have 8G ram so i'm going to try doubling the ~2G input/output buffers and do some serious listening comparisons.

 

one thing i don't understand is where these buffers reside? are the input/output buffers (parameter -b) on the NUC?

what about the 52G -a buffer?  is that on the opticalRendu?  as a comparison i have set the opticalRendu buffer for hqplayer to 500ms and this has improved the sound. 

 

i also assume that if i had a nuc instead of the opticalRendu, i would have much more flexibility to buffer at the renderer side.

 

cheers (and stay safe everyone)

 

p.s. i've ended my euphony experiment after much wasted time and frustration trying to get external disk music played from memory.......in general i found the design/layout confusing.........my trial ran out as i ran out of patience

 

 

[austinpop]

25 minutes ago, cat6man said:

i had expected, based on the above, to have glitches or other problems but i have seen none whatsoever.

 

Just to clarify: the glitches occurred when using Roon Core as the server, and SL as the endpoint. I had no issues — even with these large buffer settings — when the server was LMS. I hope that distinction is clearer now?

 

Thanks for your findings. Bummer that Euphony OS did not work out for you, as I have had very good experience with it. But ultimately, the responsibility is the Euphony team's, to ensure people — especially potential customers like you — get adequate support.

[cat6man]

1 hour ago, austinpop said:

 

Just to clarify: the glitches occurred when using Roon Core as the server, and SL as the endpoint. I had no issues — even with these large buffer settings — when the server was LMS. I hope that distinction is clearer now?

 

Thanks for your findings. Bummer that Euphony OS did not work out for you, as I have had very good experience with it. But ultimately, the responsibility is the Euphony team's, to ensure people — especially potential customers like you — get adequate support.

 

thanks for the clarification. 

 

do you have any suggestions as to buffer size without roon core?

did you ever compare root core server with LMS?

 

and to clarify on my part--i never requested support from euphony so they did not fail to support me.

my view is that stuff should work (it's the engineer in me--'we don't need no stinking manuals')

it didn't, and i found the interface very confusing

 

anyone know where these buffers reside in h/w or how large they can be made?

[austinpop]

10 minutes ago, cat6man said:

 

thanks for the clarification.  do you have any suggestions as to buffer size without roon core?

 

The SL buffer sizes that I liked were the same, irrespective of which server (Roon Core or LMS).

 

10 minutes ago, cat6man said:

anyone know where these buffers reside in h/w or how large they can be made?

 

Simple answer: in RAM.

 

Or more accurately, these buffers refer to blocks of virtual memory, in the address space of the "squeezelite" process, which are allocated by the application. If you search back, you'll find an earlier post of mine that gave some more detail: https://audiophilestyle.com/forums/topic/30376-a-novel-way-to-massively-improve-the-sq-of-computer-audio-streaming/?do=findComment&comment=946503

 

 

One thing I should add is that the definition of -a is different based on OS. The post above refers to the implementation on Linux, where -a refers to a buffer while interacting with the ALSA driver. As Emile recently reminded me, this is different on Windows, where -a refers to the buffer size to the sound driver, expressed as a time unit (in ms).

[cat6man]

3 hours ago, austinpop said:

 

The SL buffer sizes that I liked were the same, irrespective of which server (Roon Core or LMS).

 

 

Simple answer: in RAM.

 

Or more accurately, these buffers refer to blocks of virtual memory, in the address space of the "squeezelite" process, which are allocated by the application. If you search back, you'll find an earlier post of mine that gave some more detail: https://audiophilestyle.com/forums/topic/30376-a-novel-way-to-massively-improve-the-sq-of-computer-audio-streaming/?do=findComment&comment=946503

 

 

One thing I should add is that the definition of -a is different based on OS. The post above refers to the implementation on Linux, where -a refers to a buffer while interacting with the ALSA driver. As Emile recently reminded me, this is different on Windows, where -a refers to the buffer size to the sound driver, expressed as a time unit (in ms).

 

thanks again, i'm sorry i'm not being sufficiently clear with my question.

i've seen the earlier post.

 

what i mean to ask is, 'where are the buffers located, at the server or at the endpoint?'

 

both the -b and -a buffers are set in the sqeezelite.conf file which resides on the server.

are either of those buffers implemented at the endpoint (the opticalRendu in my case).

 

the Rendu has the following squeezelite settings available:

Buffer size (buffer time in ms)

Period count (period count in bytes)

 

since these look like the -a parameters, i'm wondering if they are the same as the -a parameters set in the config file

 

as a comparison, for hqplayer there is a buffer setting (in ms) that is implemented in the NAA (i.e. the Rendu)

[austinpop]

1 hour ago, cat6man said:

 

thanks again, i'm sorry i'm not being sufficiently clear with my question.

i've seen the earlier post.

 

what i mean to ask is, 'where are the buffers located, at the server or at the endpoint?'

 

No worries. Squeezelite (SL) runs on the machine that is connected to the DAC. If you run a distributed configuration, where the server and endpoint are on distinct machines, then it would be on the endpoint.

 

1 hour ago, cat6man said:

both the -b and -a buffers are set in the sqeezelite.conf file which resides on the server.

 

The squeezelite.conf is irrelevant on the server if your DAC is connected to an endpoint machine. You'd need to change the sqeezelite.conf file on the endpoint.

 

1 hour ago, cat6man said:

are either of those buffers implemented at the endpoint (the opticalRendu in my case).

 

The experiments I and Ray and others ran were on NUCs and other machines with ample RAM (see next point) running AL and Euphony OS, where it's possible to fully control the command line parameters with which SL is invoked. I'm not aware that oR gives you root access to a shell to allow this, or any ability to edit and change the sqeezelite.conf file. Also, to really exploit large buffers, like the 2GB each for input stream and output, you need to have at least 8GB of RAM. Does the oR have that much?

 

1 hour ago, cat6man said:

the Rendu has the following squeezelite settings available:

Buffer size (buffer time in ms)

Period count (period count in bytes)

 

since these look like the -a parameters, i'm wondering if they are the same as the -a parameters set in the config file

 

You'd have to check with Sonore to see if these allow you to achieve the same effect as the -b and -a options. You could ask them to expose these options as additional settings, I suppose.

 

[walloon]

I used to tune stream/output buffers and Alsa when I was using Daphile, which is based on LMS. I'm now using Euphony Stylus on a single box (NUC) and I'm very happy with it.

 

Out of curiosity, does it make any sense to tune these buffers when using Stylus only i.e. no LMS?

[hifi25nl]

8 hours ago, cat6man said:

hqplayerd in ramroot on AL is really good with "older" AL builds (e.g. 140) and this sounds much better than the same configuration on build 250........who knows why

 

Audiolinux is using a special realtime priority configuration that give specific priority to audio applications (this is made with a custom copyrighted script).

After that version some kernels could not support this configuration without freezing the system, so that has been disabled until menu version 226.  Now there is a much more complete new option 6 "REALTIME MANUAL ASSIGNMENT configuration" in EXPERT menu where you can re-enable it if you are running one of the last kernels, for example 5.6.19-rt11-1-rt

 

 

 

[cat6man]

8 hours ago, austinpop said:

 

No worries. Squeezelite (SL) runs on the machine that is connected to the DAC. If you run a distributed configuration, where the server and endpoint are on distinct machines, then it would be on the endpoint.

 

 

The squeezelite.conf is irrelevant on the server if your DAC is connected to an endpoint machine. You'd need to change the sqeezelite.conf file on the endpoint.

 

 

The experiments I and Ray and others ran were on NUCs and other machines with ample RAM (see next point) running AL and Euphony OS, where it's possible to fully control the command line parameters with which SL is invoked. I'm not aware that oR gives you root access to a shell to allow this, or any ability to edit and change the sqeezelite.conf file. Also, to really exploit large buffers, like the 2GB each for input stream and output, you need to have at least 8GB of RAM. Does the oR have that much?

 

 

You'd have to check with Sonore to see if these allow you to achieve the same effect as the -b and -a options. You could ask them to expose these options as additional settings, I suppose.

 

 

sonore does not expose the config file, but do provide web access to a squeezelite settings page on the Rendu where you can change what look like the -a parameters.  they recommend not changing the (unknown value) default.

as for buffer size possible, i'm sure it is far smaller than what you guys did with a NUC as the endpoint........now i have that to consider, hmmmm..................has anyone done a direct comparison of a Rendu vs. a NUC endpoint, using a separate server box?

 

as for Rendu buffer available, if I can do 500ms of buffering in the Rendu/NAA with hqplayer, that would suggest for red book

(44.1k) x (16 bits) x (2channels) x (1/2s) x (1byte/8bits) = 88.2KBytes which is more than an order of magnitude smaller

[cat6man]

7 hours ago, hifi25nl said:

 

Audiolinux is using a special realtime priority configuration that give specific priority to audio applications (this is made with a custom copyrighted script).

After that version some kernels could not support this configuration without freezing the system, so that has been disabled until menu version 226.  Now there is a much more complete new option 6 "REALTIME MANUAL ASSIGNMENT configuration" in EXPERT menu where you can re-enable it if you are running one of the last kernels, for example 5.6.19-rt11-1-rt

 

 

 

 

thanks Piero!

i saw the new option but didn't recognize the significance.

i'll follow up on the AL thread if i have any questions.

[cat6man]

9 hours ago, austinpop said:

 

No worries. Squeezelite (SL) runs on the machine that is connected to the DAC. If you run a distributed configuration, where the server and endpoint are on distinct machines, then it would be on the endpoint.

 

 

The squeezelite.conf is irrelevant on the server if your DAC is connected to an endpoint machine. You'd need to change the sqeezelite.conf file on the endpoint.

 

 

so if these buffers are all at the endpoint running squeezelite, are there any LMS buffer settings at the server?  i see you can buffer radio from 3-30s, so there is something inherently there to buffer inputs.

 

option B would seem to be to run squeezelite on the same NUC as the server, implementing the larger buffers since I have 8G of ram, and run a monoprice slimrun USB to my DAC

[Mahler and Bach on Computer]

On 1/2/2017 at 2:49 AM, austinpop said:

 

So how do you bridge 2 ethernet ports? If you are on Linux, I can't help you but I'm sure it's possible. If you are on a Mac, here are the fairly simple instructions that I followed. Feel free to use DHCP but you are also free to assign a static IP:

 

https://support.apple.com/kb/PH18510?locale=en_US

I got a new Mac Mini and try to bridge the two Ethernet ports together.  Unfortunately, the original link is missing.  Wonder anyone can help me here.  Thank you very much!

 

Best regards,  

 

David

[sbenyo]

I also run monoprice slimrun usb connected to sablon usb 2020. The sablon by itself is wonderful. Best I heard.

With monoprice it's even gets a clearer and a tiny bit better. It's a must to run slimrun with good power otherwise highs are not clean. 

 

My only problem is that the female side of the slimrun gets extremely hot. Is it how it should be? I ordered heat sinks but I am not sure it supposed to be like this. SQ is not affected but I am still concerned with it.

[Mahler and Bach on Computer]

4 hours ago, Mahler and Bach on Computer said:

I got a new Mac Mini and try to bridge the two Ethernet ports together.  Unfortunately, the original link is missing.  Wonder anyone can help me here.  Thank you very much!

 

Best regards,  

 

David

Have the problem resolved by reconfiguration of Thubdrbolt Bridge from thunderbolt ports to Ethernet port and USB port.  
 

Thank you!

[austinpop]

On 8/3/2020 at 9:58 AM, cat6man said:

 

so if these buffers are all at the endpoint running squeezelite, are there any LMS buffer settings at the server?  i see you can buffer radio from 3-30s, so there is something inherently there to buffer inputs.

 

I didn't do a lot of deep digging into LMS, but I didn't find any existing parameters to control buffering in LMS. I bet if you go hack the code, you could implement something, but this isn't a feasible approach for most.

 

This is what makes the Stylus player such a gem. I regard its "buffer queue to RAM" feature to be one of its major strengths, and one of the reasons it sounds so good.

 

On 8/3/2020 at 9:58 AM, cat6man said:

option B would seem to be to run squeezelite on the same NUC as the server, implementing the larger buffers since I have 8G of ram, and run a monoprice slimrun USB to my DAC

 

You should definitely try this. Assuming you're using a good quality LPS on your NUC, you may be pleasantly surprised.

[bobfa]

4 minutes ago, austinpop said:

 

I didn't do a lot of deep digging into LMS, but I didn't find any existing parameters to control buffering in LMS. I bet if you go hack the code, you could implement something, but this isn't a feasible approach for most.

 

This is what makes the Stylus player such a gem. I regard its "buffer queue to RAM" feature to be one of its major strengths, and one of the reasons it sounds so good.

 

 

You should definitely try this. Assuming you're using a good quality LPS on your NUC, you may be pleasantly surprised.

Over the last couple of years I have been amazed at what small teams of dedicated software developers have done with Linux in audio systems.  I use Euphony, Audiolinux, and GentooPlayer as the underlying OS in my testing.  They might be targeted to users with different skill sets and tastes, but they all have helped me improve the sound quality of my systems.  I cannot pick a favorite!  I like Euphony for the steadfast stick to their guns direction.  I like GentooPlayer and Audiolinux for their flexibility and selection of different playback options.  I really need to go back and get a new install of Audiolinux as I have not used it in a year.  Boot it off of a USB device and just mess around some more.

 

 

[Exocer]

3 hours ago, austinpop said:

 

I didn't do a lot of deep digging into LMS, but I didn't find any existing parameters to control buffering in LMS. I bet if you go hack the code, you could implement something, but this isn't a feasible approach for most.

 

This is what makes the Stylus player such a gem. I regard its "buffer queue to RAM" feature to be one of its major strengths, and one of the reasons it sounds so good.

 

 

You should definitely try this. Assuming you're using a good quality LPS on your NUC, you may be pleasantly surprised.

 

Would the buffer queuing available in Stylus render all network tweaks moot if one only streams from services like Tidal/Quboz?

[bit01]

Only last week I upgraded AL LXQt 3x to 4.5 and I find it to have improved SQ (more body to the sound?)- I run JRiver MC25/LXQt from RAM and many, many thanks to the very considerate @Nenon who kindly helped me secure a 16GB Apacer module D21.23261S.001 that is now installed in the NUC7i7DNHE1!

 

This change was from the two 8GB Kingston Value RAM and was very positive in clarifying the perceived soundscape (quieter backgrounds, good depth, location etc) but greatly affected the perceived frequency balance of the overall system setup. The sound seemed bass heavy and devoid of HF sparkle?! This quickly got me to cable swapping, and glad that I did!

 

The perceived frequency balance was easily restored by changing the interconnects between pre/power amps (all DIY). This cable swapping also gave me a chance to play with some ethernet cable variants in the 'bridged' connection I use and where I normally favor the 2m flat Tera Grand CAT7 (2m, with the braided  jacket) .

 

PC-->usb/ethernet adapter (a TP-Link UE300, thanks to another member here) -->NUC

 

Kudos to many  here that have tried and mentioned CAT8 rated cables as possible alternatives. I got some to try -Cable Matters, Ugreen, Monoprice and some unbranded ones! I was pleasantly surprised (shocked actually) how well this one unbranded cable worked in my setup, right from the go! I therefore thought it worth mentioning here!

 

In the Amazon listing it is advertised as indoor/outdoor UV resistant, 26 AWG single strand (solid) copper  twisted pairs in aluminum mylar-backed foil shields , with a 100% braided aluminum overall shield and gold plated connectors. On the package it says Made in China!

 

I got it from the Amazon.ca  seller 'Canachoice' . However it seems to be in other listings too (e.g. Amazon.com - Smolink, DbillionDA, ...) all  'Fulfilledd by Amazon'.

 

https://www.amazon.ca/gp/product/B07WN3P2KB/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1

 

https://www.amazon.com/gp/product/B08296DMTM/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1

 

https://www.amazon.com/gp/product/B07Z4YHHYP/ref=ox_sc_saved_title_2?smid=A2WC0H630DY40C&psc=1

 

The sound I am getting has great PRaT, low noise, good soundscape good instrument timbre and really differentiates the fine recording/mastering from the bad and the ugly! More importantly the music is very enjoyable with no listening fatigue., and offers great 'insight' into the recording.

 

Many thanks to the excellent members here who have positively shared and those who continuously contribute to this amazing thread!

ATB

B.

 

 

[austinpop]

45 minutes ago, Exocer said:

 

Would the buffer queuing available in Stylus render all network tweaks moot if one only streams from services like Tidal/Quboz?

 

Sadly, no. I wish that were the case.

 

As many have observed, and certainly in my own experience, there appears to be some SQ cost to merely the presence of a network connection, even when playing local content. So the upstream quality and mods still matter. However, that said, the ability to buffer network streams does raise their SQ.

[emailtim]

On 7/3/2020 at 3:35 PM, sig8 said:

Just put together a new server with i9-10900 CPU and ASUS Republic of Gamers Strix Z490-E Gaming LGA 1200 ATX board. Sounding better than i9-9900k ASUS Prime Z390-A LGA 1151 ATX right out of the box. Same power supply and RAM modules. Would let it burn for few days and do A-B one more time to be sure.

 

Any feedback on your i9-10900 / ASUS machine ?

 

I am considering updating my old machine with either the i9-10900 or i9-10900K, a Z490 board and NVMes.

 

TIA

[sig8]

1 hour ago, emailtim said:

 

Any feedback on your i9-10900 / ASUS machine ?

 

I am considering updating my old machine with either the i9-10900 or i9-10900K, a Z490 board and NVMes.

 

TIA

I will give a brief update for now, because some more A/B is required. After i9-10900/ASUS, I got to try a i9-10900k with a Gigabyte Z490 AORUS Master. This certainly sounds better than i9-10900/ASUS, and I think it is the Gigabyte motherboard, not the differences in the processors. 

 

All in all, in the past year I have tried two different ASUS boards with i9-9900K, one ASUS with i9-10900, one Gigabyte AORUS Master Z390 with i9-9900K, and the current i9-10900k with Gigabyte Z490. Both Gigabyte boards sound better than any ASUS combo. I have to compare current i9-10900k/Gigabyte with my i9-9900k/Gigabyte. That will be in next 2-3 weeks. Current system is still in burn-in process, it needs to settle down in 2-3 weeks.

 

For now, I have concluded that Gigabyte boards sound better in my system. YMMV.

[Exocer]

10 minutes ago, sig8 said:

I will give a brief update for now, because some more A/B is required. After i9-10900/ASUS, I got to try a i9-10900k with a Gigabyte Z490 AORUS Master. This certainly sounds better than i9-10900/ASUS, and I think it is the Gigabyte motherboard, not the differences in the processors. 

 

All in all, in the past year I have tried two different ASUS boards with i9-9900K, one ASUS with i9-10900, one Gigabyte AORUS Master Z390 with i9-9900K, and the current i9-10900k with Gigabyte Z490. Both Gigabyte boards sound better than any ASUS combo. I have to compare current i9-10900k/Gigabyte with my i9-9900k/Gigabyte. That will be in next 2-3 weeks. Current system is still in burn-in process, it needs to settle down in 2-3 weeks.

 

For now, I have concluded that Gigabyte boards sound better in my system. YMMV.

Thanks for sharing your expertience. Very curious about going this route myself... Hopefully you don't mind the barrage of questions 😃.

 

How would you compare the sound of the 10th gen i9 to the 9th gen i9?

 

Do you have any experience with 8th gen CPUs to compare?

 

Some have reported that the K version CPUs can sound better due to better binned parts and/or enhancements with cooling capabilities due to a difference in the manufacturing process between the k and non k versions. It would be great if you could compare non-k and k on the same motherboard...

 

End rant 👍

 

Thanks