JPLAY Responds: An Open Letter

[Julf]

You know I wasn't talking about measuring USB dropped data packages - I was replying to your more general statement " I think this whole discussion would be easily avoidable if vendors making claims would actually provide measurement results showing the effect they claim is actually happening."

And my general statement also applies to the specific situation. If you remember, what I was responding to was:

The point being that the use of this "Glitch" idea is not a simplistic black & white affair - if Windows data delivery sometimes falls outside it's timing constraints determined for USB data transmission. then it doesn't necessarily result in an audible glitch - it may have a much more subtle affect in the soundfield.

Either you drop data, and that can be measured, or you cause jitter, and that can be measured.

 

[Julf]

This may be too subjective for you but the consensus of opinion is that there is a more visceral, emotional contact with the sound. The consensus seems to be it delivers better dynamics & a deeper soundstage with more "air" etc. I know this may sound cliched but that seems to be the consensus.

And how strong (statistically) is that consensus?

 

[jkeny]

Right. So, according to you, what clock does the PLL recover in an adaptive mode USB DAC?

The audio clock, what else?
Here's what Vincent Kars says in his excellent site:

Adaptive
In this mode the timing is generated by a separate clock.
A control circuit (sample rate guesser) measures the average rate of the data coming over the bus and adjusts the clock to match that.
Since the clock is not directly derived from a bus signal it is far less sensitive to bus jitter than synchronous mode, but what is going on the bus still can affect it.
It’s still generated by a PLL that takes its control from the circuits that see the jitter on the bus.

 

[Julf]

The audio clock, what else?

So, as I stated, the clock is generated by a PLL from the bit clock that is generated by a software-independent clock on the computer. So, could you explain how software can affect the PLL-recovered clock?

Your quote from the Well-Tempered Computer just confirms that the PLL is *less* sensitive to bus jitter - so even less likely to be affected by any software on the PC. Was that the point you wanted to make?

 

[Vincent Kars]

So, as I stated, the clock is generated by a PLL from the bit clock that is generated by a software-independent clock on the computer. So, could you explain how software can affect the PLL-recovered clock?

The USB bus runs at a fixed speed e.g. full speed=12 MHz
This is generated by a clock in the host and of course, software can alter the speed (low/full/high) but cannot improve on the precision (cycle to cycle time) of this clock.
In adaptive mode the clock speed of the DAC is derived from the amount of data in the package, not from the bus speed.

Regardless of the USB protocol used, all this is down stream of the media player and is handled by specific USB drivers.
No way can a media player control this.

 

[jkeny]

So, as I stated, the clock is generated by a PLL from the bit clock that is generated by a software-independent clock on the computer.

No you are wrong & somewhat confused. Don't believe me - listen to what Cypress Semiconductors, who know a bit more about USB than you or I, have to say

Part of the difficulty comes from the fact that the receiving end for the digital data streaming over the USB cable doesn’t know
the exact sample rate. In fact, it can only infer the nominal sample rate. What’s more, the data that comes in over the USB
‘pipe’ isn’t accompanied by any form of clock. This is in significant contrast to most other serial interfaces, which either send a
clock, or structure the data so that such a clock can always be extracted from the link when it is running.

 

[jkeny]

Yes, Vincent, nobody said that a media player is controlling this. What can be done however, by the likes of Jplay, is to achieve a more stable operating environment for this real-time operation. As AMir said already, you have to think of the whole system & it's operation inter-connections.

But this is a side-issue - my point is that there is variability in the delivery timing of the USB packets of data. If there wasn't then adaptive mode USB would have been perfect for audio playback (I.e the PLL recovery of the audio clock would be jitter free) & nobody would have bothered to create asynchronous isochronous USB.

 

[Julf]

The USB bus runs at a fixed speed e.g. full speed=12 MHz
This is generated by a clock in the host and of course, software can alter the speed (low/full/high) but cannot improve on the precision (cycle to cycle time) of this clock.

Thanks for the clarification - yes, the software can of course set the clock rate, but it doesn't change it in real time - once it is set, it stays at the same rate, at a precision (as you state) determined by the clock oscillator.

In adaptive mode the clock speed of the DAC is derived from the amount of data in the package, not from the bus speed.

I agree - my point was that the clock is still generated by a PLL that gets the reference from the incoming data, but the date rate is not affected by software.

Regardless of the USB protocol used, all this is down stream of the media player and is handled by specific USB drivers.
No way can a media player control this.

Indeed. This is really the main point.

 

[jkeny]

Furthermore Cypress continue thus http://www.cypress.com/?docID=25374

The only clocking information available on the USB interface is that every millisecond, a specific type of data packet
announces the start of a frame, and this event is detected by the receiving hardware. This millisecond is derived in a known
way from the system clock at the transmitting end – and so is the original audio sample rate (well, we’ll briefly discuss an
exception later).
A simple solution appears to be that one could put this 1 kHz pacing clock into a PLL-based multiplier and multiply it up by
whatever factor is required to create the audio master clock and all the sub-clocks that depend on it. However, in a system
handling CD-derived audio, the sample frequency is 44.1 kHz and a typical conventional audio DAC requires a master clock of
256x this, or 11.2896MHz. The fact is that multiplying an input reference frequency by such a large factor in a single-stage
PLL gives inherently rotten performance. It takes a hit from multiple constraints: loop bandwidth, reference spur rejection, and
VCO jitter. What’s more, the number we need to multiply the 1 kHz by in this case isn’t an integer, making the task that much
harder.

And later

Some USB audio modes require that the local clock is able to ‘slip’ against the incoming clock, for instance from a source
that’s relaying a remotely-synchronized audio stream. A programmable SoC architecture can run in an adaptive mode that
finely trims the local clock to provide the required ‘slip’.
Fixed-function microcontrollers just can’t meet the tough performance requirements on this clock generation process. Their
inflexible clock generation systems can’t be adjusted to be both exactly correct and low in jitter, and they usually fall back on a
crude “add/lose samples” approach. This might be workable for telephony but is completely unacceptable for high quality
audio.

So this whole "real-time enough" issue is far from the simplistic vision that is being portrayed

 

[Julf]

No you are wrong & somewhat confused. Don't believe me - listen to what Cypress Semiconductors, who know a bit more about USB than you or I, have to say

And I totally agree with Cypress. So, based on that, how can software affect the amount of jitter in ways we can not measure?

 

[Julf]

So this whole "real-time enough" issue is far from the simplistic vision that is being portrayed

No. The demands of replacing the simplistic PLL by a SoC chip on the receiving end to accommodate timing slip required by external synchronisation (not needed with stand-alone audio) has nothing to do with real-time requirements for the software on the sending PC.

 

[jkeny]

Hold on Julf, you have gone from an incorrect statement that there is a bit clock in USB audio to agreeing with Cypress who state that there is no separate clock signal in USB - it is derived from the timing of the data packets. That's some turn around in a half dozen posts while still trying to maintain that you were correct, all along!

So now you ask how changes in the operating environment in which this time sensitive clock recovery is being conducted can affect the clock recovery?

As I said already if the USB data delivery was "real-time enough" then why was asynch USB created? Can you give a reason for this?

 

[Julf]

No you are wrong & somewhat confused.

I am definitely confused - by your conflicting claims. If the PLL clock of the DAC is not derived from the audio rate, how can any timing variations affect the DAC output (as long as the data gets there in time)?

Don't believe me

OK, I won't.

 

[jkeny]

I am definitely confused - by your conflicting claims. If the PLL clock of the DAC is not derived from the audio rate, how can any timing variations affect the DAC output (as long as the data gets there in time)?

OK, I won't.

Maybe you should read up about how PLLs work & especially USB PLLs to lift your confusion? Just a suggestion

 

[Julf]

Hold on Julf, you have gone from an incorrect statement that there is a bit clock in USB audio to agreeing with Cypress who state that there is no separate clock signal in USB - it is derived from the timing of the data packets. That's some turn around in a half dozen posts while still trying to maintain that you were correct, all along!

No, my point was that the receiving USB DAC derives the audio clock from the USB data using a PLL.

So now you ask how changes in the operating environment in which this time sensitive clock recovery is being conducted can affect the clock recovery?

Yes, because you seem to be claiming that a) the clock is not recovered from the USB data, but at the same time b) the timing of the data affects the USB clock.

As I said already if the USB data delivery was "real-time enough" then why was asynch USB created? Can you give a reason for this?

The main benefit of asynch USB is that you can totally isolate the DAC audio clock from the USB timing.

Anyway,can we please get back to the real subject - how user-level software on a PC/Mac can affect (or not) the timing of the audio on the DAC?

If the processor has enough capacity to deliver the data packets to the interface in a timely fashion, it doesn't matter how many other processes are running on the computer, or what the load is, or how your code is structured - the timing of the USB interface is not under the control of the CPU once the operating parameters have been set up.

 

[Julf]

Maybe you should read up about how PLLs work & especially USB PLLs to lift your confusion? Just a suggestion

I can totally understand that you don't want to address my actual questions.

The issue is not how USB PLLs work, it is your claim that the timing could somehow be affected (beyond the very coarse effect of actually dropping data) by software. The explanation might or might not involve USB PLLs, but so far I have not seen any coherent explanation.

 

[jkeny]

No, my point was that the receiving USB DAC derives the audio clock from the USB data using a PLL.

here'e what you said (emphasis mine) http://www.whatsbestforum.com/showt...An-Open-Letter&p=199108&viewfull=1#post199108 "The PLL-recovered clock signal is based on the bit clock, not the timing of data packets. The bit clock can possibly be affected by noise and power supply variations affecting the clock oscillator, but it is not affected by software." Your current statement is the direct contradiction of something you said about 2 hours ago!!

 

[jkeny]

I can totally understand that you don't want to address my actual questions.

It's not my role to teach you how a PLL works - I think you should do that work yourself as you are obviously confused.

The issue is not how USB PLLs work, it is your claim that the timing could somehow be affected (beyond the very coarse effect of actually dropping data) by software. The explanation might or might not involve USB PLLs, but so far I have not seen any coherent explanation.

Again, I suggest that you read the thread - Jplay is not just a piece of application software, it actively changes the OSes operating environment as explained by Josef. Now if you are asking how a change in operating environment can affect delivery timing of USB data & cause variability, then I'm flumoxed by your question. I guess you also need to read up some more on this as I'm not going to educate you.

 

[Julf]

here'e what you said (emphasis mine) http://www.whatsbestforum.com/showt...An-Open-Letter&p=199108&viewfull=1#post199108 "The PLL-recovered clock signal is based on the bit clock, not the timing of data packets. The bit clock can possibly be affected by noise and power supply variations affecting the clock oscillator, but it is not affected by software." Your current statement is the direct contradiction of something you said about 2 hours ago!!

Yes, I incorrectly talked about the bit clock instead of the frame rate.

The question still stands: how, in your view, can host software affect the audio clock timing of the DAC?

 

[Julf]

It's not my role to teach you how a PLL works - I think you should do that work yourself as you are obviously confused.

Thanks, but I have been working with PLLs for at least 30 years, so I am somewhat familiar with their operation.

Again, I suggest that you read the thread - Jplay is not just a piece of application software, it actively changes the OSes operating environment as explained by Josef.

I have read his statements, but I am interested in *your* view.

Now if you are asking how a change in operating environment can affect delivery timing of USB data & cause variability, then I'm flumoxed by your question. I guess you also need to read up some more on this as I'm not going to educate you.

If you allow, I might suggest you read up on DMA.