USB Clock Upgrade My Experiences (so far)

[PeterSt]

Arjan, sorry for the confusement; the "trimpot" I referred to is just a software dial I have created in XXHighEnd here. So, not available to you all yet. Hopefully soon though.

Regards,
Peter

[acg]

Hi Peter,

I've just shelled out for same USB card that you have there so that I can compare it to the PPA card before and after you release your software update.  It will be interesting.

Cheers,

Anthony

[acg]

Ok, in the spirit of trying to understand a little of just what Nick and Pauls usb clock upgrades or Peters software 'dial' in the forthcoming XXHE release are achieving I looked into the asynchronous USB protocol today:  I did me some book learning.  In point form the following is what I have learned (please chime in and let me know if I am incorrect):

• Asych is one form of the isochronous protocol
• All forms of the isochronous protocol function by the host (the XXHHE PC in this case) spewing out packets of data at regular fixed intervals (1KHz or 8KHz) and varying the number of bytes in the packet to suit the transmission rate
• There is NEVER any re-transmission.  If data is lost for any reason it is not coming back.
• The receiver (the NOS1 in this case) welcomes the data into the FIFO (first in first out) buffer and clocks it out of there using a FIXED local clock.  It is the fixed local clock on the receiving side that means that the transfer is asynchronous.
• The clock rates at the host and the receiver do not match...they just don't, even though they may be rated the same speed.  When the clocks don't match the FIFO buffer will eventually empty or overflow both of which are bad.
• To keep the FIFO buffer within its population limits the receiver (the dac) will monitor the buffer and when needed send a packet back to the host (the PC) to say "whoa back" or "give it some spurs".  The host then alters the number of bytes in each packet.

 

So if I have this right, the NOS1 usb board does a little bit of work monitoring the FIFO buffer and then sending back packets to the XXHE PC to say speed-up or slow-down.  Then the USB card in the XXHE PC responds by doing a few calculations and changing how much data it throws in each packet.

Now, the NOS1 is not your average dac.  When XXHE upsamples to 16/705 that is 16 times more data than a simple Redbook transmission.  On the face of things this means 16x then number of 'correction calls' sent from the dac to the pc to vary the transmission rate but this may be alleviated in full or in part by how much data can be made to fit into a packet.  Peter will know this.

So how could the upgraded clocks or software dials result in an improvement in sound quality?  My guess is that by making the clock rates match each other more accurately that fewer 'correction calls' are made and therefore less noise produced in both the host and receiver usb interfaces which in turn has less of an impact within the dac and its production of jitter.

The next question therefore becomes is there an advantage by having super stable and accurate clocks in the usb interface?  My guess here would be "probably not" (nothing like sitting on the fence) because all that we should be trying to achieve is to absolutely minimise the number of 'correction calls'.  If the two clocks cycle at constant speeds in relation to each other over time then the number of 'correction calls' will be relatively low.  However the ideal thing here is to use only one clock for transfer, which is the slave idea that Coen, Peter and Nick had earlier.  I don't know how to do this or if it can even be done in this situation.

There may also be an advantage to using clocks that are super low noise in one way or another (I don't know which way really...just putting it out there).

Anyway, this has been my attempt to put this stuff in more laymans terms for some others to try and follow.  Please pick it to pieces and let me know where I am wrong and have not thought it through properly.

Cheers,

Anthony

[PeterSt]

Anthony, thank you for this mate.

Of course I sould have sorted this out myself but for some things I don't know where to get the additional time from. But what I planned for tomorrow was just call someone who really whould know. So even better when I'm now loaded with data.

That no resends take place is a bit of s surprise for me because it would be the property of "sending data" which is subject to error checking (contrary to sending "audio"). Well, the error checking is obviously there (see NOS1 Control Panel), but then no resends ? I'll ask tomorrow.

That the underlaying means should be isochronous (that guaranteeing the data to arrive in time always, meaning that the OS needs to take care of sending it in time always) is no surprise.

That the timing issue is solved by more or lesser filling the packet is something I could expect but actually did not know. It is fully logic to me now though.

All your subjective (?) observations of the real merits according to noise hence jitter in the end - I can only agree. But I guess (or hope) that is obvious by now.
That it would lead to one clock controlling it all, is also obvious, or logical. What is new of course, is that with one clock, only one "correction call" would be in order (for a playback session) to never have one again - unless the correction call doesn't lead to the proper expectatations hence the "setting" of the amount of data immediately leads to a "is wrong" and such a call is send out again to the other direction, and is observed to be wrong again - et cetera. But if so, the margin of what's right would be too small which then *IS* related to the underlaying speed indeed, as you pointed out so well.

Great work Anthony.
Peter

[acg]

That no resends take place is a bit of s surprise for me because it would be the property of "sending data" which is subject to error checking (contrary to sending "audio"). Well, the error checking is obviously there (see NOS1 Control Panel), but then no resends ? I'll ask tomorrow.

My understanding is that a checksum is performed, but there is nothing to really be done with the result other that some sort of alarm that information loss has occurred, which is what the NOS1 Driver front-end on the XXHE PC tells us.  That piece of information I got from post #52 here, so not strictly from a textbook.

To be honest I was not game to post this information until I read that post today (John Swenson seems to have sensible things to say about computer audio in general) because I feared that I was not seeing the 'big picture' on the subject, but that post  resolved my doubts and I went ahead.  Sort of like all the pieces falling into place.

Anthony

[PeterSt]

Ok, careful then;
We have been "discussing" other articles from John where at least I could easily point out that he knows more than any other on this subject, but also that he clearly doesn't have the whole picture of it. (maybe this was 4-5 months ago).

Who, I think, can always be trusted is Ar-t, but he is always more talking in secrecy, a bit like I do. Just doesn't want to unveil everything because of his commercial good reasons. So needs a lot of reading in between the lines.

In any event it would be correct that errors of any kind showing up in the NOS1 Control Panel are audible, so let's say that resending is not in order. Or at least not in those cases, but with reference to disk read errors only showing up as errors to you, knowing that it doesn't make much sense to show you an error which wasn't an error really (because a retry solved it for net result).
Also, it would be my idea that it may depend on the chips used, and empirical finding (a bit like John is I'd say) not necessarily tells all. So, I'd still like to find the textbook story after all, meaning the USB spec and how it can be used or utilized.

Also look at the danger :
For years "we" copy the "statements" of others that Asynchronous USB is error checked and "thus" should end up with error free transmission. I am a first to do to while the "thus" is just my expectation because logical. And now someone tells it is not because of ?
Wikipedia would show a banner with "needs references" etc.
Still it can be correct, even without those references.

My reading in between the lines detects the perceived merits about "Tent Clocks". Did you notice ? maybe not, but I notice more. And so I also notice the sneaked-in underlining of Ar-t without futher words. Like I don't use further words on this little subject.
But to me it tells a lot about both good guys.

Or what about your post regarding controlling the jitter. It won't tell anything to either guy, while to me it tells everything (well, obviously - but all is about references).

Regards,
Peter

[PeterSt]

One more thing, which only testifies how difficult this all is (or should testify that) :

I am pretty sure that I am the only one as an "end user" who has the USB driver code, including all the Windows Kernel Code and including the FPGA image code (bought a license for that ever back). I recently told that already. Now :

I am also the only one (as it looks like) who pointed out bugs in there, not known to the original driver code programmers. This *is* highly related to our subject here. Still, I have not been able to have these bugs solved, no matter I could provide all the test data and means to reproduce it. Can't solve those bugs myself either, because a 10,000 programs are involved and it is just too much for a simple soul. One of these bugs is about not reporting errors while clearly audible they are there (yes, I am repeating myself from a previous post).

Message : I should know a lot, but I know nothing.
Next message : Anyone in this field with "statements" really doesn't get way with it so easily when I'm around.

I will try to find out more tomorrow, with most probably the same outcome (no resends - just saying).

Peter

[acg]

I am thinking aloud now Peter, so please don't hold what I say against me.

So, we have a clock on our pc USB card that is spewing out information in frames (that contain the packets) at a set rate...sometimes it sends out data, sometimes it does not, but what the rest of the computer is doing (read latency) does not have a tremendous effect on the oscillator (the clock just turns over on its power supply and does its job) because if there is no data to be sent out it just sends out an empty frame with no packets just the timing information.  If the USB bus operates at 8MHz there are 8000 frames allocated per second.  Unfortunately there is no possibility of re-sending packets that contain errors because that will mean that the next frame would need to be delayed (the reference is here).  That is basic isochronous USB operation.  Will a very stable, low noise clock/USB card make a difference here?  Perhaps...at least that seems like what Nick and Paul are reporting to some degree.  The very stable clock on the USB card is probably important from the perspective of it oscillating at the same very predictable rate relative to the clock on the NOS1 USB board in that it will not trigger a varying rate of 'correction calls'...I think that the only thing more important here than a stable rate of 'correction calls' is zero 'correction calls'.  So a good low noise power supply for the pc USB card and a stable low noise clock are things to investigate in the pc.

Controversial and ill-considered thought #1 - Does latency in the computer (i.e. not getting the data to the USB card buffer in time) affect noise because it causes empty packets to be sent to the dac when instead they should have been populated, thus causing 'corrective calls' to say 'speed up the transfer' and then once the latency issue resolves further 'corrective calls' are required to slow down the transfer rate....then there is another latency issue and the cycle starts again.

[PeterSt]

Hey Anthony, nobody who is thinking outloud can be held anything against. It can only be helpful.

I must digest your last post somewhat, but it triggers me to say this :

When you fire up the NOS1 Driver Control Panel, the USB streaming is active. This should be with empty packets, although I can't tell whether the contents is important and things are just "silenced". Also good to know : on the DAC board side (of the NOS1) i2s is always running, so no matter USB streaming is going on or not). So it's actually always making sound, though silent sound. Now :

What I can see easily in any situation the USB noise is not surpressed sufficiently on the outputs, is that 8KHz. Will be 130-140dB down, but it can be seen. Now what's important for our story here is that this noise is lower when only streaming is going on, opposed to when music data is in those packets, because the noise gets somewhat higher (say a few dB).

At this moment I don't know how much this is related to the "adjustment calls" or ... that this is just about the analog signal which now carries 1's and 0's and the transition to the other of that. For this to understand you must read Nick's postings about i2s noise, which in the end will come down to the same. Here : Hunting for noise (scroll down until you see pictures).

Careful now, because I can be confusing;
What I say is that already those transitions from 1 to 0 and back will cause noise as per Nick's shown proof of that (such a thing). BUT (!!!) :

The noise I see rising is at the 8KHz frequency hence something about more steep current used. What I can't tell is

whether this is about all that pile of 0's and 1's and their transitions in there (keep in mind, it is all an analog signal, never mind we call it digital) which collect within the "one send" of a packet.
or
whether this is about packets getting larger once real data is to be in there (I just don't know because never investigated it, but I can imagine it (USB packets contain a header)).
With the notice that this already lurks for a combination with the above reason.
or
Whether once real data is transmistted, right away the "adjustment calls" start to happen and that this implies higher current = noise to be seen. But if so, I'd say that each sent packet implies soch a call (back), because it is still 8KHz I see, and nothing else (also not "white noise" getting higher).

AND

That it already can happen that *acoustical* 8KHz can be heard from the MoBo once MoBo drivers are not the best or whatever, and where this acoustical noise seems to spring from the normal cpu (ASRock 3930K situation) with no idea how such acoustical noise will imply electrical noise.


I just thought to mention this, because it seems related to your last post, Anthony.
Peter

PS: Is that 8MHz you mentioned correct, or was it meant to be 8KHz ? -> 8KHz is the rate of the packets sent.

[acg]

PS: Is that 8MHz you mentioned correct, or was it meant to be 8KHz ? -> 8KHz is the rate of the packets sent.

Yes, KHz is the right one.

Looks like I have some reading to do...

Anthony

[Nick]

Ok, in the spirit of trying to understand a little of just what Nick and Pauls usb clock upgrades or Peters software 'dial' in the forthcoming XXHE release are achieving I looked into the asynchronous USB protocol today:  I did me some book learning.  In point form the following is what I have learned (please chime in and let me know if I am incorrect):

• Asych is one form of the isochronous protocol
• All forms of the isochronous protocol function by the host (the XXHHE PC in this case) spewing out packets of data at regular fixed intervals (1KHz or 8KHz) and varying the number of bytes in the packet to suit the transmission rate
• There is NEVER any re-transmission.  If data is lost for any reason it is not coming back.
• The receiver (the NOS1 in this case) welcomes the data into the FIFO (first in first out) buffer and clocks it out of there using a FIXED local clock.  It is the fixed local clock on the receiving side that means that the transfer is asynchronous.
• The clock rates at the host and the receiver do not match...they just don't, even though they may be rated the same speed.  When the clocks don't match the FIFO buffer will eventually empty or overflow both of which are bad.
• To keep the FIFO buffer within its population limits the receiver (the dac) will monitor the buffer and when needed send a packet back to the host (the PC) to say "whoa back" or "give it some spurs".  The host then alters the number of bytes in each packet.

 

So if I have this right, the NOS1 usb board does a little bit of work monitoring the FIFO buffer and then sending back packets to the XXHE PC to say speed-up or slow-down.  Then the USB card in the XXHE PC responds by doing a few calculations and changing how much data it throws in each packet.

Now, the NOS1 is not your average dac.  When XXHE upsamples to 16/705 that is 16 times more data than a simple Redbook transmission.  On the face of things this means 16x then number of 'correction calls' sent from the dac to the pc to vary the transmission rate but this may be alleviated in full or in part by how much data can be made to fit into a packet.  Peter will know this.

So how could the upgraded clocks or software dials result in an improvement in sound quality?  My guess is that by making the clock rates match each other more accurately that fewer 'correction calls' are made and therefore less noise produced in both the host and receiver usb interfaces which in turn has less of an impact within the dac and its production of jitter.

The next question therefore becomes is there an advantage by having super stable and accurate clocks in the usb interface?  My guess here would be "probably not" (nothing like sitting on the fence) because all that we should be trying to achieve is to absolutely minimise the number of 'correction calls'.  If the two clocks cycle at constant speeds in relation to each other over time then the number of 'correction calls' will be relatively low.  However the ideal thing here is to use only one clock for transfer, which is the slave idea that Coen, Peter and Nick had earlier.  I don't know how to do this or if it can even be done in this situation.

There may also be an advantage to using clocks that are super low noise in one way or another (I don't know which way really...just putting it out there).

Anyway, this has been my attempt to put this stuff in more laymans terms for some others to try and follow.  Please pick it to pieces and let me know where I am wrong and have not thought it through properly.

Cheers,

Anthony

Anthony hi,

We are both a little sad to be trawling USB protocol information  . I have posted these points elsewhere but they may help again here.

lets assume for the USB link only that there might be four main forms of error / management interruption to data that could impact sound here (there are properly more, but for now).

1) Processing of resend requests (depends on usb transfer mode used)
2) Bit transmission errors
3) Audio word errors (out of sequence or missing words) 
4) Transfer speed management requests


USB Async transfer mode is intended for media stream transfers of video / data and as you say there is no USB protocol error checking, just signalling from the receiving end to speed up / slow down the link. So here the only point 1 of the points 1 to 4 above would not apply. The rest will apply and there will be no USB protocol handling / correction of errors so once the error has happened it will make it to the DACs as corrupt data and we hear it. Since the data lines are simplex (one set of wires carrying data for both directions) for the receiving end to issue commands to the transmitting end to speed up or slow down it has to interrupt the transfer. This is unlikely to be a "set and forget" tuning by the receiving end because the clocks at both end of the link will drift (I know even the temp stabilised Dexa clocks do this) which means that the speed up slow down requests will happen throughout replay.

Another USB transfer mode is bulk transfer mode. If you read back and look at the hunting for noise thread you will see that this is mentioned. I asked in one of these thread posts IIRC if Peter knows from the source code of the NOS USB driver if bulk transfer mode is used by the NOS interface. This could be very relevant to what we hear. With bulk transfer mode there are CRC checks performed on packets and transfer resend requests are made where there are errors. So in this mode it is possible that all four error types listed above could be happening.

The errors only have to happen at some thing like audio frequency intervals and we are going to hear the effects.

Finally wrt clock quality and the accuracy of transmission over the USB lin. Again as mentioned else where both the transmitting and receiving end of the USB link synthesize their 480mhz transfer clock speed by multiplying the 24mhz oscillator wave form by 20X. This makes phase noise in the 24mhz oscillator VERY important if there is to be a well formed 480Mhz link clock. Consider if one beat of the transmitting 24mhz xtal is say 25% faster this could mean that for 20 beats of the transmitting 480Mhz clock it runs 25% faster than the receiving clock so 20 beats at the transmitting end to a relative 15 beats so 5 beats missed.

This is an extreme (I hope  ) example, but its not hard to see that not having the 480mhz USB carrier running at consistent speed at both ends of the USB link could / will cause all sorts of data transfer problems.

Taking all this into account my view was when I started with DIY clocks and then selected the Dexas was "how would better quality clocks not improve the USB link transfer quality ?" (actually I did have some experience of improving USB clock quality from years ago  which helped. Then it was just a case of waiting for the free PSU offer that NewClassD run on Neutron stars from time to time to come round again)

Its important not to go down the "data is data" route of thinking when tuning the implementation of digital audio components. Practical experience is that if you buy into the data is data approach then there are some really big improvements that can be missed out on.

I think the best thing to do would be to use the information I sent over by email and take to plunge. Build the DIY clocks or put Dexas in. Don't get too hung up on transmission line lengths and noise etc. The effect of improved clocks is much much greater then the electrical effects. Three folks are up and running with Dexas with two more in the pipeline that I know of. Listening to the effects puts a very different perspective on the discussion  .

Kind regards,

Nick.

[PeterSt]

I am with you about the intermodulation of the two clocks being a possible problem. I lost a post earlier (dammed ipad battery) about the clock speed and thoughts on possible effects of the clocks on data and SQ. In essence i'm not really seeing this as an electrical noise issue. My money is on data transmission error rates being vastly improved and if USB "bulk transfer" mode is being used to transfer data then the reduced error rate will reduce the number CRC errors and so the number of "Stalls" and retransmissions on the link.

Re: USB Clock Upgrade My Experiences (so far)

Nick, really this topic. And a you see you're even confused yourself now (yes, "and old cow" as we say over here, but maybe you can try avoid confusing possible useful posts from you by each line in it "referring to" ? let me add Please).

Anyway, might you have seen this as a question towards me : No, of course no bulk transfer is in order. But I must honestly say that once you start to relate things as you do now (previous post, but feel free to combine it with put quote) I have another Dutch saying : Can't make much chocolate of it.

Didn't I express the other day that I was a kind of disappointed ? It happened again. Not because of your serious quest to the whole lot, but because of a too much charismatic expressing which comes across as "I know !". Let me help you with quoting what bothers me (not all as much of course); please notice that this is all without proove that I can see and that it just takes things for granted from one angle or base that's worked towards; I can do that too but I think or at least hope that there's so much more context given that or I express explicitly to be possibly wrong, or that the context put forward has to be worked out first. So let's see :

I have posted these points elsewhere but they may help again here.

and as you say there is no USB protocol error checking

So here the only point 1 of the points 1 to 4 above would not apply.

for the receiving end to issue commands to the transmitting end to speed up or slow down it has to interrupt the transfer.

The errors only have to happen at some thing like audio frequency intervals and we are going to hear the effects.

their 480mhz transfer clock speed by multiplying the 24mhz oscillator wave form by 20X. This makes phase noise in the 24mhz oscillator VERY important if there is to be a well formed 480Mhz link clock.

but its not hard to see that not having the 480mhz USB carrier running at consistent speed at both ends of the USB link could / will cause all sorts of data transfer problems.

Practical experience is that if you buy into the data is data approach then there are some really big improvements that can be missed out on.

Don't get too hung up on transmission line lengths and noise etc. The effect of improved clocks is much much greater then the electrical effects.

Listening to the effects puts a very different perspective on the discussion 

Nick, this is almost all of your post. And no, these points don't need to be worked out because I think most of them have passed already with doubts, context for review, things against them and what not. So, you go your own way ? Yes, it seems you are. Here the foremost example, because dealt with a couple of times by now :

This makes phase noise in the 24mhz oscillator VERY important if there is to be a well formed 480Mhz link clock.

I put it in bold now. So, I claim these Dexa's are sh*t for Phase Noise. And as long as you don't come up with the plots of it, I will remain right on this. And no, it is not important that I am right on this, but to me it is important that you press your "statements" (on others) rather than finding out first and that you advise people to spend a lot of money which is worth nothin,g or can be - or should be solved by quite different means (and I hope it is clear enough what these means can be). And just saying : STILL you can be right, but not by just pressing.

Yes, VERY reluctant to post, especially because I am sure it is well meant on your side. Well, same here. If we really want to get somewhere that is.
Best regards,
Peter

[CoenP]

Hey you dual Dexa clock guys, what about the USB cable? Does another cable still make a difference?

Some (audio) USB cable manufacturers claim an influence on dataloss....

regards, Coen

[Nick]

I am with you about the intermodulation of the two clocks being a possible problem. I lost a post earlier (dammed ipad battery) about the clock speed and thoughts on possible effects of the clocks on data and SQ. In essence i'm not really seeing this as an electrical noise issue. My money is on data transmission error rates being vastly improved and if USB "bulk transfer" mode is being used to transfer data then the reduced error rate will reduce the number CRC errors and so the number of "Stalls" and retransmissions on the link.

Re: USB Clock Upgrade My Experiences (so far)

Nick, really this topic. And a you see you're even confused yourself now (yes, "and old cow" as we say over here, but maybe you can try avoid confusing possible useful posts from you by each line in it "referring to" ? let me add Please).

Anyway, might you have seen this as a question towards me : No, of course no bulk transfer is in order. But I must honestly say that once you start to relate things as you do now (previous post, but feel free to combine it with put quote) I have another Dutch saying : Can't make much chocolate of it.

Didn't I express the other day that I was a kind of disappointed ? It happened again. Not because of your serious quest to the whole lot, but because of a too much charismatic expressing which comes across as "I know !". Let me help you with quoting what bothers me (not all as much of course); please notice that this is all without proove that I can see and that it just takes things for granted from one angle or base that's worked towards; I can do that too but I think or at least hope that there's so much more context given that or I express explicitly to be possibly wrong, or that the context put forward has to be worked out first. So let's see :

I have posted these points elsewhere but they may help again here.

and as you say there is no USB protocol error checking

So here the only point 1 of the points 1 to 4 above would not apply.

for the receiving end to issue commands to the transmitting end to speed up or slow down it has to interrupt the transfer.

The errors only have to happen at some thing like audio frequency intervals and we are going to hear the effects.

their 480mhz transfer clock speed by multiplying the 24mhz oscillator wave form by 20X. This makes phase noise in the 24mhz oscillator VERY important if there is to be a well formed 480Mhz link clock.

but its not hard to see that not having the 480mhz USB carrier running at consistent speed at both ends of the USB link could / will cause all sorts of data transfer problems.

Practical experience is that if you buy into the data is data approach then there are some really big improvements that can be missed out on.

Don't get too hung up on transmission line lengths and noise etc. The effect of improved clocks is much much greater then the electrical effects.

Listening to the effects puts a very different perspective on the discussion 

Nick, this is almost all of your post. And no, these points don't need to be worked out because I think most of them have passed already with doubts, context for review, things against them and what not. So, you go your own way ? Yes, it seems you are. Here the foremost example, because dealt with a couple of times by now :

This makes phase noise in the 24mhz oscillator VERY important if there is to be a well formed 480Mhz link clock.

I put it in bold now. So, I claim these Dexa's are sh*t for Phase Noise. And as long as you don't come up with the plots of it, I will remain right on this. And no, it is not important that I am right on this, but to me it is important that you press your "statements" (on others) rather than finding out first and that you advise people to spend a lot of money which is worth nothin,g or can be - or should be solved by quite different means (and I hope it is clear enough what these means can be). And just saying : STILL you can be right, but not by just pressing.

Yes, VERY reluctant to post, especially because I am sure it is well meant on your side. Well, same here. If we really want to get somewhere that is.
Best regards,
Peter

Wow Peter, you got out of the wrong side of bed this morning. I'm not going to dignify this with any form detailed response, it can just hang 

[Nick]

Hey you dual Dexa clock guys, what about the USB cable? Does another cable still make a difference?

Some (audio) USB cable manufacturers claim an influence on dataloss....

regards, Coen

Coen hi,

I have not tried, but can do. I'll give alternate cables a go and report back.

Cheers,
Nick.