Roon 1.8 sound quality change?

To see whether this really matters, you would have to collect the references of the work of Nordmark, cited in the article, for us to examine this further.

I did not do that (yet) as I am working full time on very different things and audio is a lifetime passion, but not an actual profession for me. However I found other recent works confirming the extraordinary performance of trained human hearing.

I found particularly interesting this extract of Physics Review Letters of 2013, that I am happy to share.NOTE - The first posting was not the correct reference link.
I also just discovered that the paper might have been revised since I extracted it. Check ongoing.

An audio professional told me that in his USB III experience one should not exceed 90 cm for avoiding audible jitter at 384 kHz data flow. That maps into 3.6 m at 96 kHz but only 1.35 m at 256 kHz.Not sure how universal this statement is, but on my 384 kHz DAC I found out that prior to having a galvanically decoupled cable (then running Mac Book on battery for best results) I had better results with shortest length, the best was 30 cm…

You must have a subscription to read not only the four sentence abstract, do you?

You can obtain a free copy via

Download menu

What format is this odd sampling rate used for?
Isn’t it usually multiples of 44.1/48 kHz?

I’m not going to engage in your cable length/sample rate arithmetics.

1 Like

The USB has two signal pins, a ground pin and a +5V pin.
I would believe that the cheap galvanically isolated ones are simply disconnecting the 5V pin, which I was doing manually with a thin strip of scotch tape on the square side - small but easy, reversible and it improves quality. The full decoupling involves something else that I did not investigate into details, but it works better. Fortunately, as it is also much more expensive.

Are you trying to be sarcastic?

Would you care to translate into laymens terms the relevance to this thread?
This comment paper is actually refuting another scientific work, as far as I can tell.

1 Like

Actually, I think UAC 2 still uses isochronous mode to transmit the data. The asynchronous out-of-band signalling is used to keep the sender clock in sync with the receiver clock, but does not gate the transmission of more data.

1 Like

This is exactly the problem: you don’t know!
You’re just trolling…

Apologies, not at all… I downloaded this article some years ago already and I was trying to figure out how to either copy from my iPad, or find a link. I did google several possibilities and I saw this one downloading pdf.
But I admit I did this in a loose, distracted mode, as I am also listening to good music thanks to Roon 1.8/HQP as per the origin of this thread. That is indeed our final objective.
Let me go to a laptop and see if I can include a link.

Well yes, but isochronous is unrelated to asynchronous.

Isochronous is a Quality of Service thing, it ensures that the packets get there in time to keep up with the music flow, and don’t get delayed by somebody else doing a backup.

But within that overall speed guarantee, which is a tiny fraction of USB bandwidth, the data transfer is still asynchronous, follow the piece-of-paper pattern i sketched.
Asynchronous means the sender has no influence on the receiver’s clock, isochronous means pieces of paper arrive frequently enough but that doesn’t say anything about the sample timing.

1 Like

I just might have been caught not knowing the exact workings myself.
I stand corrected then!
Thanks for correcting that bit, Bill.

For those who hear a deterioration in SQ with 1.8 - Congratulations !

No! I just recall my experience and when I make assumptions (logical but not proven) I make it clear. Instead of criticizing in vacuum, why don’t you share your insights about USB cables and their galvanic insulation variants ?

Human Time-Frequency Acuity Beats the Fourier Uncertainty Principle

Ah, but the names mean things in the USB Audio protocol. Data is transferred with an USB isochronous protocol, which just means it’s going to send some music samples (data packets) every USB frame, 1 millisecond on USB 1, every 125 microseconds on USB 2. How many samples are sent in each frame depends on the bit rate and sampling frequency.

The sending clock and the receiving clock are usually a bit out of skew. The sub-protocols used to reconcile this difference are called “adaptive” and “asynchronous”. In adaptive, the receiver watches the analog wavefrom of the incoming digital signals to attempt to surmise the clock skew. I think that’s what you’re calling “asynchronous”. However, In UAC asynchronous, every few milliseconds the sender asks the receiver how many samples (not frames, but data packets sent in some set of frames) it’s received. It uses this result to add or remove a sample from the next frame, removing one if it’s sending “too fast”, adding one if it’s sending “too slowly”.

3 Likes

Cant share my take, since I’ve no first hand experience with them.
Cable demonstrations at dealers/shows were never really conclusive for me, but no USB demo so far…

Thanks for the paper, I’ll check it out tomorrow, time for sleep…

Ok?
Your discussing the mechanism.
I’m just saying, isochronous is a QoS mechanism that has nothing to do with the exact timing of samples into the actual digital to analog conversion system.
And asynchronous is a timing mechanism that ensures the sender has nothing to do with the exact timing of samples into the actual digital to analog conversion system.

That was my only point, the rest is irrelevant to this discussion.

I’m saying that the USB transfer cannot introduce jitter.
A failure in the isochronous mechanism causes glitches, or a complete breakdown.
A failure in the asynchronous mechanism — I don’t know what it would cause but it wouldn’t cause errors in the inter sample timing at the DAC because it is not involved in that timing.

Look at it this way; if I say that Amazon will introduce a premium delivery service for CDs that puts femtoclocks in the delivery trucks’ cruise control to reduce CD playback jitter — that’s a ridiculous notion. But why? Because the timing of the samples into the DAC mechanism does not depend on timing of the physical delivery of the package.

2 Likes

THanks for this clarification Bill!
What about USB III ? I guess if it were the same as II only with 10x shorter frames it would not have additional signal pins…