The difference between synchronous and asynchronous USB is to do with correction for long-term drift between the clocks on the source and sink; as far as I know it has nothing to do with jitter which is a short-term phenomenon. Agreed, the USB clock is likely to be noisy and may have high jitter but any DAC with pretensions to high sound quality won’t be clocking audio samples based on the USB clock, whether using the synchronous or asynchronous USB audio protocol. Apart from anything else, the USB clock frequency might not be simply related to the audio sample rate.
3 Likes
You are right re the long term drift. The effect of this once the signals are out of sync even by 1 bit would be a continuous high pitch squeal. However short term variations are also possible were the DAC clock is being derived from the incoming data and is synchronised to the source clock, which is coming from a poor clock source (PC’s). Both effects are called Jitter. You are also right in that some DAC’s with more advanced PLL (phase lock loops) will attempt to override the variations in timing of the incoming clock and some may be able to do this more successfully than others. The displacing of a exact timing of the sample frequency will create an auditable effect on sound when the filters are converting the data to analogue. Asynchronous USB can help to solve this problem because then the DAC is entirely dependant upon its own internal clock, however if the clock is not supper accurate then a problem may still exist. The solution is to connect via ethernet to a streamer (with highly accurate clock) between ROON and the DAC which should also have a quality clock. In my experience price is not the determining factor. Some low cost DAC’s and Streamers can have excellent clocks while high price ones can have poor clocks. This explains why many audiophiles report very varied experiences. Also ethernet is not subject to this problem as it is a packet technology and does not stream at the sampling clock frequency.
1 Like
USB audio is also a packet-based protocol: audio samples are delivered in packets containing the number of samples which fit into the USB frame period, normally 125 us (8 kHz), plus or minus samples needed to correct for the fact that the audio sample rate may not be an exact multiple of the frame rate (and also for long-term drift correction when asynchronous feedback is used). It would not be possible for the signals to be “out of sync by one bit” as you put it.
Well it does happen which is why ROON has a setting that allows you to increase the resync delay. When it happens one gets a continuous sound not unlike the fingernails across a blackboard. USB Audio packets are completely unlike IP packets. Firstly the timing (clock) of the digital audio within the USB is critical component in digital to analogue conversion. I would call it synchronised data bursts and certainly not a packet technology like TCP/IP. This aside what I am saying is that IF and that’s a big IF audiophiles can really hear a difference between how a digital system is connected then there are only 2 possible culprits. 1) the DAC and in particular the digital to analogue process it uses (i.e. the filters and analogue components) or 2) which of the many available implementations of USB have been used.
As I said, USB audio sample data is carried in packets, albeit small, which arrive at a rate defined by the USB specification. This rate is usually 8 kHz. The audio sample clock (44.1 kHz, 48 kHz, etc.) does not define the rate at which these packets arrive. In fact the audio sample clock is not present on the USB physical layer at all, but is an implied property of the audio data which is negotiated between the sender and receiver. There is no per-sample “timing” of the audio data on the USB bus; the receiver has to reconstruct the timing using a sample rate clock running at the negotiated rate.
For example, if the negotiated audio sample rate is 44.1 kHz then the USB packet will usually contain either five or six samples (44.1 / 8 = 5.5125); these arrive at the receiver effectively at the same time (each complete USB packet is normally DMA’d into buffer memory by the USB controller hardware). The receiver then has to arrange for these five or six samples to be clocked into the DAC hardware at the proper rate - that is, 44.1 kHz. Nothing on the USB physical layer maintains the 44.1 kHz / 22.7 us timing between individual samples.
9 Likes
Just read a review yesterday about the ifi usb filter on ASR. Yeah it’s basically useless garbage. Works ok only on really bad designed DACs to improve something. On well designed DACs (including 100$ DACs) it even decreases the performance by a bit.
I feel the same way about Powerfilters, expensive cables, ethernet reclockers, linear PSU Vs smps, expensive streamers etc. Most of the time it’s just people feeling the need to waste Money.
3 Likes
It always amazes me when someone who randomly listened to a friend’s system, is able to spot some “difference” after some days or months.
Human hearing is usually unable to spot difference after some minutes, but, of course this is not the case for audiophiles.
3 Likes
Amir goes into some detail in one of his vids about this supposed talent.
and the difference between the rock and the nucleus??
Search speed? Storage? Noise from fans?
Many things in the game. Sound quality is not any of them.
2 Likes
One was designed for fanless and has thermal management as part of the os and also has all the drivers for home automation stuff for installers. Other than that they are the same.
3 Likes
i think volume leveling gives better sound. All things being equal. I think MQA is POO !! Just my opinion.
Sounds to me like a misconfiguration issue on you old ubuntu device
e.g. ; default-sample-format or ; default-sample-rate
(maybe you installed PulseAudio on top of ALSA and haven’t use it but audio parameters remained changed …idk)
ROCK configures all a way it should be. When you are not an “it expert” then configuration mistakes are almost always a problem due to the OS Level configuration complexity.
So maybe u hear the sound now as it should be ….
Hi, coincidentally I’m using NUC10, and got the same experience, too.
In past, my Roon server was installed in a highly trimmed real time kernel debian Linux (PulseAudio is uninstalled, only ALSA) and I’ve set roon to top priority (99).
And in few days ago I installed the ROCK with same setting in the same NUC, and everything else remain the same. The audio outcome is just more than woooh! And I’ve compared the sound quality if ROCK fetches the music files from NAS and internal ssd. I think, it’s just needless to say the result.
Someone should tell Roon about this
I believe they knew it very clearly before they launched ROCK. 
Actually…
1 Like
Once again we degenerate into getting personal with once again the same result!
Do I really have to post the forum rules and guidelines again?
1 Like
Clean up on aisle 4 complete!
1 Like