HQPlayer NAA, who owns the clock?

scolley · February 11, 2016, 2:52pm

This is an offshoot of this conversation. But this is specific to Roon using HQPlayer, and the HQPlayer using an NAA.

The Signalyst website clearly diagrams flow control moving backwards from the DAC, to the NAA, to HQPlayer - as I would hope it would be. Can someone please confirm (or dispute) that this is the same “DAC owns the clock” benefit that RAAT provides to RoonReady Endpoints?

Thanks.

Krutsch · February 11, 2016, 5:28pm

I think it depends on how you connect your NAA to the DAC. If you are using async USB, then the DAC will own the clock. If you are using S/PDIF out (e.g. the TOSLINK optical, such as on a Cubox-i), then the NAA will own the clock.

Please correct me if I am wrong on this, but the network communication between the HQ Player and NAA is described as async, so it seems it has to be this way…

scolley · February 11, 2016, 5:38pm

That’s an excellent clarification! Good catch. Thank you Kenneth.

Yes, as I understand it, the output device for any S/PDIF connection will always march by the beat of its own drummer. So my OP question really relates to an asynch USB connection only. Not asking about any other type.

Thanks.

Krutsch · February 11, 2016, 5:49pm

Then it has to be the DAC.

scolley · February 11, 2016, 6:04pm

Ahh… yes, that would be the case for the asynch USB NAA connection to the DAC.

But the question remains open about the HQPlayer network connection to the NAA.

Krutsch · February 11, 2016, 6:17pm

There is no owning the clock on an async connection - that’s the whole point of implementing flow control, as he shows in the diagram between the player and the NAA and the DAC (again, assuming an async USB connection).

This is the problem with Airplay - the clock is owned by the sending device, which requires the receivers to drop frames, et al., to adjust and/or keep pace if there are networking issues.

Again, I this is my view and please correct me if I am wrong.

scolley · February 11, 2016, 6:27pm

I’m sorry to be contentious. But I believe that statement is exactly the opposite of the facts… the point of an asynch connect is so that one party can own the clock, and changes to timing will be negotiated by the clock owner, as needed, as determined by said clock owner.

scolley · February 11, 2016, 6:28pm

That, however, appears to be exactly right.

Krutsch · February 11, 2016, 6:40pm

Well, I am not the author of NAA, so my comments are worth what they are. However, I’ve spent a lot my career writing networking and communications software.

The point of flow control to apply “back pressure” on the sender, not the other way around. The sender is assumed to be sending as fast as it can and the receiver signals when it is ready to accept more data.

Starting with the HQ Player to the NAA, via Ethernet, the chain is repeated between the NAA and the DAC, via the same mechanism between the async USB receiver and the NAA USB transmitter.

scolley · February 11, 2016, 7:02pm

Kenneth I’m glad to have a professional network info contributor. Thanks. I’ve got a great deal of large scale/global, profession network experience myself. But like yourself, not in this particular area…

With regard to your comments I’ve quoted above, I believe we are having a problem with semantics. The receiver signaling when it is ready to accept more data is EXACTLY the receiver controlling (owning) the pace of exchange (clock).

But we don’t have to agree on symantics. Because…

The words “by the same mechanism” tells me that - in language I would use - the DAC owns the clock all the was back to the HQPlayer.

Presuming you know this, and are not just assuming based on the diagram I referenced in the OP, then - Thank you! That’s what I was hoping to find out.

jussi_laako · February 11, 2016, 9:31pm

Kenneth’s description is correct, I have nothing to add.

Clock in the DAC is master of the show (or conductor), it defines the pace.

scolley · February 12, 2016, 2:18pm

Thank you!

PA1962 · February 12, 2016, 3:25pm

What if the NAA is connected to DAC with Toslink?

scolley · February 12, 2016, 3:34pm

I’ll let the experts chime in. But it’s my understanding that you lose that benefit with ANY S/PDIF connection to the DAC.

PA1962 · February 12, 2016, 3:44pm

Running Roon and HQ Player on Mac Mini, thinking of buying Sonore SonicOrbiter and connect it with toslink to my NAD D7050 (kind of a power dac). Which Clock would be the “master”?

jussi_laako · February 12, 2016, 10:44pm

With S/PDIF the transmitter owns the clock. So it is the sender side S/PDIF implementation that has the clock. The receiver side is then PLL slaved to that clock (to filter out the perceived variations).

There are also bunch of reclocking S/PDIF receivers like the Wolfson receiver and the one inside ESS Sabre DAC chips.

What is practically best depends on the big picture. There are various DACs that have better jitter performance with Toslink than USB (due to optical isolation Toslink and good reclocking). But whenever you use S/PDIF (Toslink/Coax) or AES/EBU (balanced variant) it is best to minimize the sender side jitter by using a good trasmitter implementation. Then there is much less for the receiver side to compensate for.

From NAA network link point of view it doesn’t make difference whether you use S/PDIF or USB, it only makes difference between NAA and the DAC. (NAA owns the clock vs DAC owns the clock)

For quite a while for one DAC I used BeagleBone Black as NAA with M2Tech hiFace (1) feeding the DAC over coax. And the results were really good. Another one was battery powered BeagleBone Black with Musical Fidelity V-Link192 and balanced AES cable (with ground connection cut, thus floating). Note! In these cases, the clock is in the asynchronous USB device, either hiFace or V-Link192.