Jump to content
IGNORED

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


Message added by The Computer Audiophile

Important and useful information about this thread

Posting guidelines

History and index of useful posts

Most important: please realize this thread is about bleeding edge experimentation and discovery. No one has The Answer™. If you are not into tweaking, just know that you can have a musically satisfying system without doing any of the nutty things we do here.

Recommended Posts

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.

Link to post
Share on other sites
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)

 

 

How a Digital Audio file sounds, or a Digital Video file looks, is governed to a large extent by the Power Supply area. All that Identical Checksums gives is the possibility of REGENERATING the file to close to that of the original file.

PROFILE UPDATED 13-11-2020

Link to post
Share on other sites
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.

Link to post
Share on other sites
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

 

 

Link to post
Share on other sites
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.

Link to post
Share on other sites
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?

Link to post
Share on other sites
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).

Link to post
Share on other sites
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)

Link to post
Share on other sites
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.

 

Link to post
Share on other sites

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?

Link to post
Share on other sites
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

 

 

 

AudioLinux --> https://www.audio-linux.com

developer of AudioLinux realtime OS

Link to post
Share on other sites
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

Link to post
Share on other sites
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.

Link to post
Share on other sites
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

Link to post
Share on other sites
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

Link to post
Share on other sites

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.

Link to post
Share on other sites
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!

Link to post
Share on other sites
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.

Link to post
Share on other sites
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.

 

 

Link to post
Share on other sites
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?

Link to post
Share on other sites
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

Software: JRMC26-64, RePhase, REW, Pandora, Spotify, dBPowerAmp Reference

2 Channel: A-Tech Fabrication i7-3770K/SSD/Passive Cooling-No Moving Parts->OKTO DAC8 PRO->MagTech/Mark Levinson #336->Magnepan 20.1's & OB/Dipole Subs

Home Theater: Anthem Statement D2V->W4S 7x1000->Magnepan 3.6's/CC3/MC2's+Martin Logan Descent I Subs

Office: Core-i7 3770S/SSD->Xonar Essence STX->W4S µDAC->W4S STI-1000->Magnepan Mini-Maggies

Garage: Dell Laptop->W4S uDAC->AdCom Amp->B&W Rock Solid

 

Link to post
Share on other sites
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

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


×
×
  • Create New...