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

19 hours ago, tapatrick said:

monoprice 36awg cables in the UK..

 

I could only find SSTP ones in the UK but at least they're CAT7

 

https://itm-components.co.uk/products/cat7-ultra-thin-slim-patch-cables-1-foot

https://itm-components.co.uk/products/cat7-ultra-thin-slim-patch-cables-2-foot

https://itm-components.co.uk/products/cat7-ultra-thin-slim-patch-cables-3-foot

 

They're also testing those cables with positive results

 

https://www.vpi.us/dpdf/483/slim-cat7-cables-1.pdf

https://www.vpi.us/d/484-specs---fluke-test-results-for-cat7-uthn-xx-mm-pdf

http://www.yeida.com.tw/ec99/ushop10157/GoodsDescr.asp?category_id=1780&parent_id=1776&prod_id=CAT7-UTHN

 

These guys are actually selling (last link showed $0.38 each without any minimum order quantity but international shipping could be tricky) 36AWG UTP ones with 2.4mm OD so they're even slimmer than those Monoprice ones with 2.6mm OD (like 0.2mm would actually make a difference, LOL)

 

http://www.behpex.com/pd.jsp?id=58

https://www.alibaba.com/product-detail/Ultra-slim-OD-2-4mm-rj45_60710573547.html

https://www.alibaba.com/product-detail/Flexible-OD-2-4mm-Mini-Cat6_60723059633.html

https://www.alibaba.com/product-detail/High-Quality-Slim-UTP-Cat6a-Cable_60712896323.html

 

Since we kinda liked to put a ferret or two for our cables, I didn't realize that not all CAT cables are made for this particular purpose

 

Armored UTP Cat6 Cable with Anti-Rodent Function
https://www.alibaba.com/product-detail/Armored-UTP-Cat6-Cable-with-Anti_60699873387.html

https://www.prospectasrl.it/en/portfolio/utp6-armored-anti-rodents-cable/

Link to comment
25 minutes ago, austinpop said:

 

This is ridiculous. Kindly stop this.

 

I still want to know how these minute differences in latency affect a DAC that is buffering input and not being starved for data. Does anyone have an explanation???

Link to comment
4 hours ago, diecaster said:

I am not looking for a science experiment...just some sort of logical hypothesis as to how latency could matter if the DAC’s buffer never becomes empty. Is no proponent of this low latency concept able to be an apologist for it?

Good question! As reported, I have not noticed any obvious difference in sound quality between the two kernels. That said, there is more than one logically plausible explanation of how latency could affect the sound quality of a DAC. First, the rate at which a DAC buffer is consumed is not constant. The old Naim DAC, for instance, does select an internal clock (according to which the buffer is consumed) on the fly and on the basis of the speed at which the buffer is filled in. If this rate varies because of latency, it is conceivable that latency can have a direct impact on clock selection and hence on sound quality. Another, perhaps less direct way of impacting sound quality could be through electrical or electromagnetic noise. We should assume that, under conditions that grant bit-perfect data transmission, the stream of bits that fills in a DAC's buffer is independent of the choice of S/PDIF cable, USB to S/PDIF bridge, upstream computer, etc. Still, S/PDIF cables and USB to S/PDIF interfaces are known to have an impact on the sound quality in spite of filling a DAC's buffer with the same bit stream at more or less the same speed. This suggests that, in spite of filtering and isolation measures, electrical noise and/or electromagnetic radiation can have an impact on sound quality. If this is true, then it is not surprising that latency can indirectly impact the sound quality: the results that I have posted suggest that the average latency increases by about 50% when one replaces the standard kernel with the real-time kernel! Moreover, real-time kernels tend to consume more resources and we know that electric noise and electromagnetic radiation do depend, among others, on the power consumption. These are all hypotheses that need to be supported or confuted by empirical experiments. But they seem logically possible, at least to me.      

Link to comment
18 minutes ago, austinpop said:

No they don’t.

 

Okay. Let me get this straight. People here are finding that loading the OS into the RAM of a NUC resulting in lower latency improves sound quality on a DAC when using a USB and Ethernet or just one or the other?

Link to comment
11 minutes ago, diecaster said:

 

Okay. Let me get this straight. People here are finding that loading the OS into the RAM of a NUC resulting in lower latency improves sound quality on a DAC when using a USB and Ethernet or just one or the other?

Your question contains lots of qualifiers.

 

People do find loading the OS into RAM makes the SQ better as I've seen in this thread.  Not sure whether they're using USB DAC or Ethernet.  Why don't you search the posts, and ask the member who posted the post?

Link to comment
1 minute ago, diecaster said:

 

Okay. Let me get this straight. People here are finding that loading the OS into the RAM of a NUC resulting in lower latency improves sound quality on a DAC when using a USB and Ethernet or just one or the other?

I am not sure that everyone who has tried to reduce latency measures has noticed improvements in the sound quality.

 

The aim of my post was indeed to see if, after about 15 pages of reports on experiments with latency measures, it was possible to come up with some consistent observations or findings. Perhaps just a summary the observations and some preliminary conclusions. 

 

I have only played around with Raspberry Pi devices and, as reported, I have not observed obvious differences in sound quality when running the standard kernel and a real time kernel. This might be due, among others, to the fact that my system is not particular revealing or to my old ears.

 

It should probably also be noticed that, on the Raspberry Pi,  the real time kernel decreases the max. latency by a factor between 3 and 10 but at the same time increases the average latency by about 50%!  Thus, real time does not necessarily imply low latency, at least not in average and on weak processors. This is something that I felt had been completely missed in the discussion.

 

Link to comment

Some details on bios settings about..NUC roon labs community rock software. Any thoughts other than turn off not needed hardware Bluetooth LAN , WLAN ?. Advanced setting bios may differ on Mboard. Sorry if i missed previous suggestions.

 

I need WLAN on but the card on the Mboard. (Single NUC no roon. LAN)

 

For the Fanless guys who need WLAN would this help? Thinking outside the box... Riser card/ extender. 

You cant unplug it, so still some device noise.  Move it away or outside the case.

Room for shielding the device, riser ribbon cable, aerial leads and keep antenna on the outside.

Possible for m.2 cards also with riser if you have them.

What difference it makes i dont know?

Right then ..Tidy the house before 1 year old destroys it again and wife kills me.

Have a great week all.

Dave

EG

 

 

BQLZR Mini PCI Express PCI-e Mini Card Extender Extension Cable Powerful Test Tool https://www.amazon.co.uk/dp/B00T2FP7X4/ref=cm_sw_r_cp_apa_oUc6BbVV2HBE1

 

HUACAM HCM16 2 x 2.4GHz 6dBi Indoor Omni-directional Antenna 802.11n/b/g RP-SMA Female Connector + 2 x 12cm U.FL Mini PCI to RP-SMA Pigtail Antenna WiFi Cable

https://www.amazon.co.uk/dp/B00VHDXSSU/ref=cm_sw_r_cp_apa_-fd6BbHEFP2W4

 

Link to comment
31 minutes ago, romaz said:

 

This is a fair question and I suspect you won't get a definite answer no matter how many times you ask.  Ask an engineer, IT specialist or a typical poster on ASR and they might offer some explanation that improving latency should offer no SQ benefit but those that offer these responses often do so based on a finite understanding of digital audio and not actual listening.  They may show you measurements that there is no impact on jitter or SNR but are these the only measures of SQ?

 

Go ahead and disconnect the USB, SPDIF, I2S, or Toslink cable between your player and your DAC for 30 seconds while playing back music.  Although extreme, this physical disconnection is a form of latency, is it not?  If your DAC is like mine, you will notice that playback stops fairly quickly, typically within just a few seconds and so your DAC's buffer that you speak so highly of isn't that large and it doesn't take long before the DAC is indeed starved for data.  Nonetheless, look at all the buffers you have upstream of your DAC (RAM, CPU buffer, disk buffer, Ethernet buffer, etc.).  With such buffer redundancy, how could latency possibly be an issue and so your point is well taken. 

 

If you use Roon, unlike your DAC, you probably know that Roon typically buffers a whole track into memory (depending on the size of the track) during playback.  This is easily proven with Tidal streaming or streaming from a NAS.  During playback, disconnect your Ethernet cable and notice that playback will continue for the length of that track in most cases.  This should suggest that the Ethernet cable, server, NAS, and router that are upstream of your Roon playback device should have no impact on SQ and yet they can and do.  

 

Here's another example.  Even though you use an ultraRendu which in of itself is a very good buffer against a higher noise, higher latency server, try loading the latest version of headless AudioLinux + RoonServer onto the server you are currently using and see for yourself if you can hear a difference.  Whether the difference is large or small, positive or negative, the point that you can hear a difference at all should tell you that a buffer is not a complete firewall for all of your upstream problems and that upstream components, whether it be digital or analog, whether it be a resistor, inductor, or capacitor, seem to have the ability to permanently imprint on the signal.

 

As for your question of how latency directly impacts SQ?  I wonder about this myself.  Is it latency itself or is increased latency impacting some other property?  Is higher latency leading to increased jitter, increased noise or dropped bits?  Unless you are upsampling or applying DSP, most software players claim to be bit-perfect but how does the player know if bits weren't dropped beforehand or dropped somewhere downstream?  Neither USB, SPDIF, Toslink nor I2S employ error correcting protocols.  

 

And so we're left with empirical evidence.  With either Windows, MacOS, or Linux, there are plenty of threads here on CA and elsewhere that suggest that as you trim your OS of unnecessary processes and services, latency improves and SQ improves and this is the foundation for products like Audiophile Optimizer regardless of the DAC and that DAC's buffer.  As you move your OS from a higher latency storage medium to a lower latency storage medium (whether it be a hard drive, an SSD, or RAM itself), there are many who will tell you that SQ improves.  AudioLinux has an "Extreme" mode which prevents CPU sleep and according to the designer, results in exceptional CPU latency.  I can verify that when I use "Extreme" mode on my Mac Pro, this otherwise quiet and cool running machine gets noisier and hotter.  While you would think that this would result in increased electrical noise that would be detrimental to SQ, SQ actually improves.

 

As you've suggested that 99% of what we are hearing on this thread is due to "expectation bias," you should listen for yourself.  Even blind test yourself.  I do this often when I'm not sure if what I'm hearing is real or not.  If you can't hear a difference, then live in bliss with what you have but there's no need to call what people are doing on this thread a "joke."  Respect begets respect.

 

 

 

 

Thanks for the eloquent explanation, Roy!

 

Alea jacta est.

Link to comment
1 hour ago, romaz said:

Is higher latency leading to increased jitter, increased noise or dropped bits?

Absolutely software as well as components are subject to jitter lowering latency and as a result jitter would account for the increased clarity.

The second point regarding the RAM OS is simply the removal of the very noisy OS SSD/HDD which introduces a large amount of jitter in the playback chain.

As for the NUC there is no magic in 'NUC' as such it's the simplicity of it's SOC processor, avoidance of PCH etc. RAM as well as low latency is also direct to CPU on most motherboards hence the good overall results with audiolinux.

Link to comment
12 hours ago, ElviaCaprice said:

1.  Format limitations:  JRiver video/hires playback is a need of mine. 

You can use Jriver in Audiolinux lxqt it sounds fantastic and outperforms Roon with PCM at least.

The jump up in quality from Windows to Archlinux is equivalent to going from a standard setup to a sclk-ex one. The better the components the more the improvements become apparent such as the standard motherboard USB output to that of a tx USB- exp with sclk - ex.

Get off that fence :)

Link to comment
2 hours ago, romaz said:

 

This is a fair question and I suspect you won't get a definite answer no matter how many times you ask.  Ask an engineer, IT specialist or a typical poster on ASR and they might offer some explanation that improving latency should offer no SQ benefit but those that offer these responses often do so based on a finite understanding of digital audio and not actual listening.  They may show you measurements that there is no impact on jitter or SNR but are these the only measures of SQ?

 

Go ahead and disconnect the USB, SPDIF, I2S, or Toslink cable between your player and your DAC for 30 seconds while playing back music.  Although extreme, this physical disconnection is a form of latency, is it not?  If your DAC is like mine, you will notice that playback stops fairly quickly, typically within just a few seconds and so your DAC's buffer that you speak so highly of isn't that large and it doesn't take long before the DAC is indeed starved for data.  Nonetheless, look at all the buffers you have upstream of your DAC (RAM, CPU buffer, disk buffer, Ethernet buffer, etc.).  With such buffer redundancy, how could latency possibly be an issue and so your point is well taken. 

 

If you use Roon, unlike your DAC, you probably know that Roon typically buffers a whole track into memory (depending on the size of the track) during playback.  This is easily proven with Tidal streaming or streaming from a NAS.  During playback, disconnect your Ethernet cable and notice that playback will continue for the length of that track in most cases.  This should suggest that the Ethernet cable, server, NAS, and router that are upstream of your Roon playback device should have no impact on SQ and yet they can and do.  

 

Here's another example.  Even though you use an ultraRendu which in of itself is a very good buffer against a higher noise, higher latency server, try loading the latest version of headless AudioLinux + RoonServer onto the server you are currently using and see for yourself if you can hear a difference.  Whether the difference is large or small, positive or negative, the point that you can hear a difference at all should tell you that a buffer is not a complete firewall for all of your upstream problems and that upstream components, whether it be digital or analog, whether it be a resistor, inductor, or capacitor, seem to have the ability to permanently imprint on the signal.

 

As for your question of how latency directly impacts SQ?  I wonder about this myself.  Is it latency itself or is increased latency impacting some other property?  Is higher latency leading to increased jitter, increased noise or dropped bits?  Unless you are upsampling or applying DSP, most software players claim to be bit-perfect but how does the player know if bits weren't dropped beforehand or dropped somewhere downstream?  Neither USB, SPDIF, Toslink nor I2S employ error correcting protocols.  

 

And so we're left with empirical evidence.  With either Windows, MacOS, or Linux, there are plenty of threads here on CA and elsewhere that suggest that as you trim your OS of unnecessary processes and services, latency improves and SQ improves and this is the foundation for products like Audiophile Optimizer regardless of the DAC and that DAC's buffer.  As you move your OS from a higher latency storage medium to a lower latency storage medium (whether it be a hard drive, an SSD, or RAM itself), there are many who will tell you that SQ improves.  AudioLinux has an "Extreme" mode which prevents CPU sleep and according to the designer, results in exceptional CPU latency.  I can verify that when I use "Extreme" mode on my Mac Pro, this otherwise quiet and cool running machine gets noisier and hotter.  While you would think that this would result in increased electrical noise that would be detrimental to SQ, SQ actually improves.

 

As you've suggested that 99% of what we are hearing on this thread is due to "expectation bias," you should listen for yourself.  Even blind test yourself.  I do this often when I'm not sure if what I'm hearing is real or not.  If you can't hear a difference, then live in bliss with what you have but there's no need to call what people are doing on this thread a "joke."  Respect begets respect.

 

 

 

 

You use a USB DAC, so you have a ground line that could carry "crap" into your DAC. The processing that is done upstream could affect the quality of the signal, and it may not have anything to do with latency, you will probably never know, unless you were to compare the same software with different settings. 

 

Some DAC designers are quite knowledgeable about all the interferences that come into the DAC and those generated by the processing within the DAC itself as well. There are some very interesting projects out there that may render all these experiments with sources moot quite soon, and that will be a huge step in computer audio (not the experimenting you are doing here - don't kid yourself...). 

Link to comment
11 minutes ago, hopkins said:

There are some very interesting projects out there that may render all these experiments with sources moot quite soon

 

Believe it or not, this is what most of us want very much. A DAC that is 100% immune to the upstream chain would save people a lot of money and effort. All the experimentation you read here comes from the fact that current DACs do not achieve this ideal - even very expensive DACs.

Link to comment
58 minutes ago, austinpop said:

most of us want a DAC that is 100% immune to the upstream chain ....

....but surely all that toxic rubbish is inherent & intrinsic to the electronics, hardware & software? Yes reduce to a minimum level! BUT surely 100% clean is impossible; like you say: "even very expensive DAC's don't achieve this". I would say it is impossible to totally eradicate the toxicity?

Link to comment

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...