Massively improve the SQ of computer audio streaming?

[diecaster]

The purpose of these thread is to allow free and open discussion about some the ideas and solutions floated and used in the "A novel way to massively improve the SQ of computer audio streaming" thread. In that thread, you aren't allowed to make posts that question the validity of what is being done there. You aren't allowed to suggest that expectation bias may be the cause of the improvement being heard. You aren't even allowed to make observations that would cause people to think about why what they are doing makes or does not make sense. 

 

That thread has spent a lot of time and money on the idea that clocks are incredibly important as is low noise on Ethernet and USB connections and that quality USB was critical to improving sound quality. A recent idea is that lowering the latency of the server makes a difference in sound quality. An even newer idea is that using a NUC with AudioLinux in RAM as an endpoint (NAA and ?) is better than an SOtM ultra or an ultraRendu. When I read that, I posted this:

 

Quote

You see, this is where I start to question the groups ability to not be affected by expectation bias. Let's assume for a moment that low latency indeed factors in to improving sound quality. The NUCs you folks are using are much noisier devices over USB than the SOtM ultra and ultraRendu. I don't know about the SOtM ultra, but the ultraRendu runs most of its OS from RAM so it to is a low latency device....not that it is being asked to do much anyway...especially when used as an NAA. Remember, the SOtM ultra and ultraRendu are single board computers specifically designed for low noise and quality USB output. Their clocks are significantly better than the NUC's clock as well.

 

That got deleted because I had the gall to suggest that expectation bias might be at play and ask questions they can't possibly answer. I responded with this:

 

Quote

 

I didn't ask anyone a question. I made an observation that should generate questions in your minds. We know that clocks are important. Hell, you guys lived on that premise since the beginning. We also know that noise is important. You all lived on that premise from the beginning too. Now, the premise that low latency is important has come to the forefront. By using a big powerful noisy NUC with the OS all in RAM as an endpoint, you are saying that low latency is WAY more significant than noise or clocks. Read that again:

 

By using a big powerful noisy NUC with the OS all in RAM as an endpoint, you are saying that low latency is WAY more significant than noise or clocks.

 

If that doesn't generate questions in your minds about what you are doing and what you are really hearing, you guys have lost all sense of reality. You get all pissy at me because I am a more of an objectivist on this than the people active in this thread. But that does not make my observations any less valid.

 

My points are that we know that noise and clocks make a difference. I won't say that word clocks make a difference but quality clocks in the endpoint just before the DAC certainly matter. Clock phase noise causes problems as does noise on the USB bus. Both pollute the DAC and affect the DACs output. Well, we don't have measurements showing that clock phase noise is a problem (that should soon change) but we do know that noise on the USB bus is a problem and that can be measured. It's harder to understand how low latency OS's would be important in and endpoint or server considering that both Ethernet and USB are full capable of overrunning the buffers in the endpoint/DAC so the endpoint/DAC throttles the sender.  You would think that ANY throttling would instantly negate any improvement in latency of the sending device.

 

Now, if you guys read all of that and say "So?", well, more power to you........

 

 

This post was deleted too.

 

So, let's assume for a moment that the observations are correct. Why would latency make a difference in sound quality? Why would a NUC with crappy clocks that makes a lot of noise on its USB ports running AudioLinux in RAM be a better endpoint than the SOtM Ultra with a super duper external clock and low noise purpose built motherboard with ultra quiet power and a fantastic USB implementation? Factor in that the DAC throttles the USB on the endpoint to keep its buffer from overfilling as their are no retransmissions in USB which should negate any latency advantages of the OS running in RAM.

 

Anyone care to discuss this?

 

[Ralf11]

the thread with censorship that is noted in the OP above:

 

https://www.computeraudiophile.com/forums/topic/30376-a-novel-way-to-massively-improve-the-sq-of-computer-audio-streaming/?do=findComment&comment=895863

 

 

 

@jabbr has posted on close in phase noise - I'd accept his opinion

 

noise on the USB cable also makes sense, tho a noise injector might be a fun project to test that

 

 

Latency causing SQ problems would not seem to be much of a problem.  But if latency triggered high activity on the clean side of a DAC (somehow) I could invent a mechanism...

[mansr]

2 hours ago, diecaster said:

Why would latency make a difference in sound quality?

Latency of what?

[LTG2010]

23 minutes ago, mansr said:

Latency of what?

''AudioLinux is based on realtime custom kernels and on the work of that part of linux community trying to achieve very low audio and processor latencies.''

See here: www.audio-linux.com

[diecaster]

I have reached out to AudioLinux and asked them why their software is supposed to improve sound quality and specifically how low latency factors in to this. I tried to look on their forum but most of the posts are in a language I don't read.

[asdf1000]

12 hours ago, diecaster said:

Why would a NUC with crappy clocks that makes a lot of noise on its USB ports running AudioLinux in RAM be a better endpoint than the SOtM Ultra with a super duper external clock and low noise purpose built motherboard with ultra quiet power and a fantastic USB implementation?

 

From Rob Watts:

"As you know, RF noise creates noise floor modulation, as the intermodulation distortion from random RF noise is a white noise modulated by the wanted signal. This then results in noise floor modulation, and is very very audible. It accounts for the things sounding brighter and less smooth; additionally, when you reduce RF noise, things sound considerably warmer and darker, and one consequence of this is perception of tempo - more midrange gives the impression of a slower tempo, as individual instruments have much more body.

Now if somebody prefers the brighter sound from more noise floor modulation, then fine - that's their taste and preference. But it's not accurate."

 

 

In terms of tweaking with the digital chain, he says that it's technically better to go with a source/chain that results in a smoother, warmer, darker sound...

 

So it MAY be possible that those reporting more detail, more dynamics, are simply enjoying the results of increased RF, causing increased IM distortion and noise floor modulation...

 

Possible. Hard to know for sure.

 

The Sonore ultraRendu + Uptone LPS-1.2 is the smoothest, warmest sounding USB source/chain I've had in my system, to my ears.. I've tried a powerful i7 NUC as an endpoint too but not the lower powered NUC being discussed recently in the other thread.

 

 

[diecaster]

I think you may be right.

[Blackmorec]

About 12 months ago I sold my entire all-tube CDP-based system and ordered a completely new system built around playing CD rips and streaming Qobuz.  I was completely new to digital network streaming so took my time putting the system together.  I built the basic system around a Zenith SE but several challenges remained......finding the best interfacing protocol to connect everything together and getting the data stream from my ISP supplied modem/router into my hi-fi room. 

 

I used information from this forum to guide some of my decisions but ultimately used my ears before making final decisions. 

 

Along the way I evaluated and sometimes added ethernet cables, network switches, network extenders, a router,  linear power supplies, USB cables, USB reclocking modules, power cables, hi-fi rack/platforms etc.  At each stage I would add a new device or cable then sit down and evaluate the result. What I learned:

• some devices and cables sounded immediately better, some sounded immediately worse
• The sound of all devices changed as they ran in
• Some devices had a much larger impact than I was expecting 
• Every single change had a clearly audible affect on the sound
• At least one extremely well reviewed device failed to deliver the sonic goods and was returned to the dealer
• Every cable had its own sonic signature

Which led to the following conclusions:

• My expectations had absolutely no effect on how something sounded. I had virtually every combination....expected better, sounded worse; expected minor or no change, heard major change; expected to like something; didn’t
• Everything that passes a signal changes as it runs in. 
• Not everything that changes during run-in changes for the better....while running in, some really good kit could sound fairly dire. 

So, imagine how boring it becomes when every time someone reports hearing  changes for a given component, one has to plow  through loads of posts putting those changes down to expectation bias. Worse, it would seem that despite what we know about physics, electronics and digital media there are things that affect the sound of a hi-fi system in very counter-intuitive ways. If we deny those changes and always put them down to expectation bias, we essentially deny ourselves the opportunities to investigate and maybe discover what’s actually going on. 

 

 

[mansr]

14 hours ago, LTG2010 said:

''AudioLinux is based on realtime custom kernels and on the work of that part of linux community trying to achieve very low audio and processor latencies.''

See here: www.audio-linux.com

Again, latency of what? From which event to what action?

[LTG2010]

5 minutes ago, mansr said:

Again, latency of what? From which event to what action?

I think it's partly based on DPC latency and how the OS prioritizes tasks, I'm no expert just enjoying the extra clarity over windows I was using previously.

[davide256]

 

 

17 hours ago, diecaster said:

The purpose of these thread is to allow free and open discussion about some the ideas and solutions floated and used in the "A novel way to massively improve the SQ of computer audio streaming" thread. In that thread, you aren't allowed to make posts that question the validity of what is being done there. You aren't allowed to suggest that expectation bias may be the cause of the improvement being heard. You aren't even allowed to make observations that would cause people to think about why what they are doing makes or does not make sense. 

 

That thread has spent a lot of time and money on the idea that clocks are incredibly important as is low noise on Ethernet and USB connections and that quality USB was critical to improving sound quality. A recent idea is that lowering the latency of the server makes a difference in sound quality. An even newer idea is that using a NUC with AudioLinux in RAM as an endpoint (NAA and ?) is better than an SOtM ultra or an ultraRendu. When I read that, I posted this:

 

 

That got deleted because I had the gall to suggest that expectation bias might be at play and ask questions they can't possibly answer. I responded with this:

 

 

This post was deleted too.

 

So, let's assume for a moment that the observations are correct. Why would latency make a difference in sound quality? Why would a NUC with crappy clocks that makes a lot of noise on its USB ports running AudioLinux in RAM be a better endpoint than the SOtM Ultra with a super duper external clock and low noise purpose built motherboard with ultra quiet power and a fantastic USB implementation? Factor in that the DAC throttles the USB on the endpoint to keep its buffer from overfilling as their are no retransmissions in USB which should negate any latency advantages of the OS running in RAM.

 

Anyone care to discuss this?

 

Not until after I've tried AL. Always possible that designs like SoTM and Sonore aren't attacking the right problem head on, that the improvement is just massive overkill in the wrong area causing some bleed-over improvement in the right problem area.

[mansr]

14 minutes ago, LTG2010 said:

I think it's partly based on DPC latency and how the OS prioritizes tasks, I'm no expert just enjoying the extra clarity over windows I was using previously.

DPC is a Windows term.

[davide256]

14 minutes ago, LTG2010 said:

I think it's partly based on DPC latency and how the OS prioritizes tasks, I'm no expert just enjoying the extra clarity over windows I was using previously.

 Audiolinux can run entirely in RAM, boot off your USB stick then take it out, no drive/EMMC access required after boot for the OS and helper applications installed

[LTG2010]

5 minutes ago, mansr said:

DPC is a Windows term

which is measurable in Linux and used in Kernel Design.

[mansr]

4 minutes ago, LTG2010 said:

which is measurable in Linux and used in Kernel Design.

How can something that doesn't exist in Linux be measurable there?

[LTG2010]

34 minutes ago, mansr said:

How can something that doesn't exist in Linux be measurable there?

Realtime Processor latency tests were carried out using an Osciliscope test in Linux as well as others and compared with DPC latency tester in Windows. It's detailed on their website if of interest.

[mansr]

29 minutes ago, LTG2010 said:

Realtime Processor latency tests were carried out using an Osciliscope test in Linux as well as others and compared with DPC latency tester in Windows. It's detailed on their website if of interest.

So what latency did they measure, and what is the relevance to audio playback?

[One and a half]

By adding a component into the signal chain from a computer to a DAC for instance, even if it uses power from the USB bus is introducing capacitively coupled noise into the system. This noise can be a wide range of frequencies, and the common 0V is the medium where this causes the most problem, also known as common mode noise.

 

Given the speed at which USB operates, it's not surprising that noise (created by capacitive coupling) is the most difficult to control, let alone remove. So what to do? Good question! For now, digital audio likes the slow lanes, the AES3, S/PDIF in the form of the RCA connector Toslink ports. Every now and again, these inputs work better with some DACs than their USB, but is that because of noise trading....in other words, the slow lanes produce different and non invasive noise compared to the noise from USB?  For the last few months, I've 'gone back' to AES3 and used USB fixers for the front end, with the expectation that with a long cable, that noise doesn't have the strength to reach the DAC. Certainly sounds more enjoyable, than say Roon bridge on a macmini then usb out to DAC.

 

Isolation is one solution for signals, but that implementation is yet to be proven wholesale IMHO. Isolation can work on the power supply, to stop the spread to other components, but the embedded noise in the signal still remains.

 

Found some papers on noise origins, on how to measure. Interesting reading. Point is, noise is very small, but makes a huge difference to what we hear.

 

 

c121.pdf

MT-095.pdf

kaajakari05uffc.pdf

[mansr]

15 minutes ago, One and a half said:

This noise can be a wide range of frequencies, and the common 0V is the medium where this causes the most problem, also known as common mode noise.

No, that is not what common-mode noise means.

[fas42]

13 hours ago, Blackmorec said:

So, imagine how boring it becomes when every time someone reports hearing  changes for a given component, one has to plow  through loads of posts putting those changes down to expectation bias. Worse, it would seem that despite what we know about physics, electronics and digital media there are things that affect the sound of a hi-fi system in very counter-intuitive ways. If we deny those changes and always put them down to expectation bias, we essentially deny ourselves the opportunities to investigate and maybe discover what’s actually going on. 

 

 

 

The core of the problem is that the "experts" don't know how to measure the performance of a system that correlates well to the listening experience. The thinking that dominates is that human hearing is quite simplistic in its operation, and that monitoring simple, and easily measured parameters tells them all that's important - those that pursue this hobby more vigorously know that this is nonsense - and the fights break out.

 

Yes, the reactions of a playback system to its environment, and other elements in the chain are sometimes counter-intuitive - but a lot of this comes down to the fact that key areas are poorly engineered, and hence "everything matters!". An analogy would be mounting a car engine using lots of rubber bands, rather than a correctly designed mounting block - in the former case, the number of rubber bands, how long, how stretchy, what they were wrapped around part of the chassis and engine, how much the heat affected them - would affect how stable the engine was, and what it was like to drive.

 

Remove the points of poor implementation, and all the silliness of variations mattering go away - the implementation is now robust, and further changes have little, subjective impact.

[beerandmusic]

INRE>>> "A novel way to massively improve the SQ of computer audio streaming" thread.

 

i tend to stay away from that thread most of the time....it's too big, too many rules...pretty soon it will turn into it's own website.

I would much rather see threads separate from it...like "best audio streamer" rather than that jargon get lost in that forest....i know, it's got a table of contents...LOL.  I do occasionally look at it, to see if there is anything new...just found out about audio-linux, but if audio-linux had it's own thread, it wouldn't get lost in that maze and I likely would have found it months ago.  People are too prudish to "outsiders" in there too and don't like to help....let that clan have it.

 

Besides, it's like every other page, it's LIKE OMG, best SQ ever!  I can't believe my ears....I mean, really, how many times can that really happen?  I will wait til everyone agrees in that thread that there is a concensus, and skip about 5000 pages, and jump on that solution.....right now it looks like it's audio-linux...what will be the OMG next month.

 

[lmitche]

14 minutes ago, fas42 said:

further changes have little, subjective impact.

I agree with most of what is written here, but this. As we sort out software, power sources and learn more about cable shielding and the instrinisic noise of various storage devices and  clocks, etc . . . we are starting to see increasing returns, not little subjective impact.

[beerandmusic]

1 minute ago, lmitche said:

I agree with most of what is written here, but this. As we sort out software, power sources and learn more about cable shielding and the instrinisic noise of various storage devices and  clocks, etc . . . we are starting to see increasing returns, not little subjective impact.

it started with USB toys about 7 years ago on this site....i am ready for a $500 streamer dac that is even 10% better than listening to vinyl on jbl speakers and audio research tube amps 50 years ago.

[nbpf]

10 hours ago, mansr said:

So what latency did they measure, and what is the relevance to audio playback?

In this context, latency typically dentoes the time it takes for a process to react to an interrupt signal. I do not know if and why this notion of latency is be relevant to audio playback. But an obvious effect of using real time kernels is that of reducing the spread between minimal and maximal latency. This can be easily verified with latency tests such as 'cyclictest'. On low-power devices like the Raspberry Pi, real time kernels typically reduce the max. latency at the expense of the min. and average latencies. On more powerful architectures and on systems in which the OS can be run from memory, this is apparently not the case and RT kernels can decrease both the max. latency and the average latency.

[fas42]

13 minutes ago, lmitche said:

I agree with most of what is written here, but this. As we sort out software, power sources and learn more about cable shielding and the instrinisic noise of various storage devices and  clocks, etc . . . we are starting to see increasing returns, not little subjective impact.

 

I'm in accord with you - because I count "software, power sources and learn more about cable shielding and the instrinisic noise of various storage devices and  clocks" as elements of the 'network' of poor implementation - a robust solution would have have all of that sorted, and from then on the returns of other changes are far less impacting.