I’m using Holo Audio Spring DAC connected via USB. I set to minimum 5ms buffering and I hear some dropouts but when I increased to 10ms, all dropouts are gone. From there, I compared the SQ between 10ms and the maximum 500ms. There’s a appreciable different; the 10ms sounds more ‘sparkle’ and more ‘air’ especially in the highs. The ‘default’ setting doesn’t sound as good as the 10ms (presuming the default setting is around ~250ms)
My take is try to set the minimum buffering before you can hear some dropouts and increase by a factor of 1. My setting of 10ms goes very well with Holo Audio Spring DAC, other DACs may need different settings. Try this simple experiment if you are using Roon ROCK. If you running Roon using Windows, try to set the buffering at the DAC software drivers.
According to the article posted above by @Edward_Hsu1 (in the original topic pre-split-out), lowering latency increases CPU (more context switching and extra work) and thus creates more noise to interfere with the analog processes in your rendering chain.
It’s our opinion that none of this matters, and latency in the digital domain does not affect SQ.
I’m curious why you think lower latency sounds better when the only explanation reasons the opposite. Do you have anything but your ear to explain? How did you test? What is the explanation for the phenomenon?
May be you can do this simple experiment and let me know? There are many explanations to why there’s a different in SQ; the type of USB cable, putting a USB Regen etc between the path from the host to the DAC. It is interesting to note it is not just about noise coupling; timing also play a part in any digital audio reproduction. I also believe the DAC should cache all the incoming data in the asynchronous memory clocked by it’s highly stable clock system to produce the best SQ and not the other way round.
Where do these buffers stop mattering? Does a buffer in RAAT matter? How about in the download from tidal ? How about the decode of the FLAC? How about the kernel filesystem drivers? How about the ethernet cards buffers and the driver for it as well?
Unrelated to buffering though. The thing you are changing in the settings is before USB in the signal path.
Only when the data contains timing information. In the buffers you are messing with, there is no timing information. Jitter and unaligned clocks are not of concern here as there is no timing information here.
The main thing here is how fast the other end can consume the buffer relative to how fast the filler can fill. Your filler isn’t about to fill reliably in 5ms, thus the dropouts. The thing you are tweaking is about a break in the digital signal, and has nothing to do with audio fidelity.
Don’t get confused about general buffering. I’m talking about buffering between the host USB to a USB-DAC. Buffering in general in a caching process from streaming, caching data for processing does not apply here.
The USB host whether it is hardware or software has a USB buffering, in this case Roon has its own USB buffering shown above. Go and try it and let me know if you hear any different?
This buffer you are tweaking is dependent on the audio infrastructure of the OS and the settings being used. I know this because I just looked at the code. For example, this controls WASAPI in a different way than ALSA, and a different way for Roon Bridge, Devialet AIR, etc… In the end, this setting may impact the size of the buffers going to the device, but if that affects fidelity, I’d argue your DACs USB implementation sucks.
I happen to have a McIntosh MHA150 hooked up to my MacBookPro (running latest Catalina and an unreleased version of Roon – but the Roon Core is running Roon OS in the basement) right now, so I gave it a test… it defaulted to 50ms, and when i went down to 5ms, I also got dropouts. I heard no fidelity changes at other settings. Setup disclosure: I’m using Sennheiser HD800 plugged into the front, with the device set to Norm 150-600/FIR. My room is silent and in a wing of the house where there are no kids. All windows are closed the A/C is not on. It’s about as silent as it gets. I am hugely familiar with these headphones, but not with the MHA150.
We believe the same thing and this is yet another reason why digital buffering should make zero impact on SQ. If it’s re-clocked by the DAC’s clock, all previous timing information is irrelevant.
I’d argue that while these settings may make a difference, they shouldn’t, and giving advice to tweak this stuff when there are real BAD consequences from doing so, is just irresponsible. As for when they do make a difference: it is highly dependent on the environment end to end and any changes in SQ should be considered a flaw in the device outputting the sound or a documented limitation. We provide these options only as workarounds for bad situations where the digital signal breaks.
I owned a Holo Spring KTE 3 for a while. It’s a very good DAC if fed I2S. Its USB implementation was easily the worst in SQ relative to what the DAC can do compared several DACs I’ve owned or own. I’ve read somewhere that new Holo DACs have a better USB receiver. I hope so given how much the old USB receiver crippled such a good DAC.
If you use I2S interface (synchronous), the accuracy of the clock depends on the source and not the DAC. Synchronous DAC interface produces high degree of jitters and noise. All modern DAC uses asynchronous memory to stripe off incoming clock and use its highly stable low noise clock system instead. I own Spring 2 and when I compared I2S and USB or SPDIF, the later one produce the best SQ. Holo Spring DAC will only do asynchronous on USB and SPDIF inputs.
I understand your argument here but my ears doesn’t agree your logic explanation. The settings of the output buffer in Roon when connected via USB does has an effect on the SQ. I’m using Holo Spring level 2 without using a USB Regen. When a USB Regen is connected, the effect is not noticeable when the output buffer is changed. This also applied to the different type of USB cable I used.
At the moment, I used a USB Regen as it helps to have more ‘uniform’ SQ without depending on the source buffering and different type of USB cables I used.
That may be the case with the Spring 2, but it was definitely not the case with the original Spring. As for “Synchronous DAC interface produces high degree of jitters and noise” it all depends on the source clocks, cable quality, and length.
My experience was with the Spring level 3 KTE. Multiple tests, with different sources and listeners. USB was far behind I2S from Singxer SU-1. S/PDIF coax was closer to I2S.
The buffers discussed here are the ones between the RAAT conversion to audio stream and DAC.
So, nothing to do with frame sizes and other flow control devices for ethernet and WLAN.
