JPLAY Responds: An Open Letter

[jkeny]

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

Great so then you know that PLLs on SPDIF signals have a lower cut-off frequency of operation below which they don't block any jitter - they simply let it straight through. Some have this knee at 1Khz i.e all jitter below 1Khz gets through. Can you tell me how USB PLLs work?

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

Well I can only tell you that Jplay is much more than an application & has system-wide effects.

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

For what? Are you denying that there is any variability in the USB data delivery timing? That it is perfect?

 

[Julf]

Well I can only tell you that Jplay is much more than an application & has system-wide effects.

But can you tell what those effects are and how they work?

Are you denying that there is any variability in the USB data delivery timing? That it is perfect?

Of course there is some variability in USB data delivery timing. What I am saying is that it is not something that the host software can fix.

 

[jkeny]

But can you tell what those effects are and how they work?

Of course there is some variability in USB data delivery timing. What I am saying is that it is not something that the host software can fix.

You are ignoring what I write & simply repeating the same question over & over. I'm not interested in this time-wasting !

 

[Groucho]

It seems as though there is a clash between hardware-oriented people vs. the software types, with very few people who have the ability to think in terms of the whole system and its genuine beauty.

In my mind, it all seems remarkably simple, and extremely elegant:

The local DAC clock is what directly defines the output sample rate and timing. Sample jitter at the output derives directly from this clock only. There are two possible basic configurations:

1. In an optimal configuration, the local DAC clock is the master clock and the rest of the system is slaved to it (examples would be the standard CD player, a PCI sound card, asynchronous USB). Here, the clock can be a simple but high precision crystal oscillator with fixed frequency, giving very low jitter. There is a small hardware buffer at the DAC and other buffers in the system. Except for gross dropouts and data loss (if the overall system is not "real time enough"), this configuration can not be influenced by the timing of the software/OS etc.
2. In less optimal configurations, the local DAC clock has to be adjusted in response to the data (and embedded clock) streaming to it (e.g. SPDIF, isochronous USB-based DACs) and is affected wrt jitter by noise in the cable and jitter in the timing of the data/clock transmission. In this case, the master clock (defining sample rate) is the one at the sending end, and the local DAC clock is slaved to this. The data retrieval within the PC/playback device is also slaved to this, so its precise timing does not influence jitter. Data is, again, hardware-buffered at the DAC and played out at a rate set by the local clock's frequency, but here the local DAC clock frequency has to be derived from the timing of the data stream using a jitter-attenuating PLL that makes occasional, minimal frequency adjustments to maintain the same average sample rate as the sending end. As long as the sending end is hardware-buffered and regulated by a fixed-frequency clock, although the jitter will be 'worse' than option (1), it will not be affected by software/OS timing considerations. Luckily, this is just what happens:

Isochronous transfer
Data is sent out in frames every millisecond...
...The rate at which the frames go out is determined by a oscillator driving the USB bus.
This rate is independent of everything else going on in the PC.

http://www.thewelltemperedcomputer.com/KB/USB.html

And that's, er, it... The debate is only around whether the OS can not be guaranteed to provide the data in time (not the precise accuracy of that timing) which would lead to severe and highly-audible glitches, or some mysterious and undefinable noise/PSU/ground issue related to the load put on the CPU by everything it is having to do. Everything else is pretty sensible and was not designed by people completely ignorant of what jitter is or mystified as to how computers and DACs work.

 

[Julf]

You are ignoring what I write & simply repeating the same question over & over. I'm not interested in this time-wasting !

I keep asking the same question because you spend a significant amount of effort in avoiding answering it. I agree it is a total waste of time.

 

[Julf]

And that's, er, it... The debate is only around whether the OS can not be guaranteed to provide the data in time (not the precise accuracy of that timing) which would lead to severe and highly-audible glitches, or some mysterious and undefinable noise/PSU/ground issue related to the load put on the CPU by everything it is having to do. Everything else is pretty sensible and was not designed by people completely ignorant of what jitter is or mystified as to how computers and DACs work.

Indeed. I think we can all agree with that.

 

[jkeny]

Thanks Groucho & I agree with you - it takes a full system's view, both hardware & software, to try to get to grips with this data transmission & the possible inter-dependencies therein.


I agree with your summary but would add the following possibility:
Even with asynch USB there is still a variability in data delivery timing. So one possible mechanism whereby timing variability on the HOST PC could (remember this is me just throwing out one possibility for consideration) have an affect on an audio DAC is if there is still a PLL operating on this data. Normally the PLL derived clock is used to generate the I2S stream for the DAC chip but in asynch DACs, this I2S stream is reclocked by the local clock. So does this not mean that the DAC is immune to incoming data jitter? Maybe not - the feedback loop of the PLL will vary depending on the variations in incoming USB data timing. This variation in the PLL feedback loop will track the variation in the USB data stream. Will this give rise to some variable noise/PSU/ground issues? Possibly?. I believe the same data correlated noise phenomena has been reported by Jocko Homo in relation to SPDIF PLLs where he has stated something along the lines "has anybody listened to the PSU driving the PLL & heard how it varies"

 

[Julf]

Maybe not - the feedback loop of the PLL will vary depending on the variations in incoming USB data timing. This variation in the PLL feedback loop will track the variation in the USB data stream. Will this give rise to some variable noise/PSU/ground issues? Possibly?. I believe the same data correlated noise phenomena has been reported by Jocko Homo in relation to SPDIF PLLs where he has stated something along the lines "has anybody listened to the PSU driving the PLL & heard how it varies"

Sure. It is also possible that the software on the PC causes the PC power supply to send varying RF noise into the mains wiring, and that RF noise might get picked up by the DAC. Possible? Yes. Likely? No.

It is always good to suggest new ideas for things that might affect the sound, but the next step is always verifying if the effect is real. Just because something is possible doesn't imply that it actually happens.

It would be quite easy to look at the power rail of the DAC with a scope while producing various amounts of timing variation on the data. If there is some correlation, there then needs to be an additional step to check if the noise/supply variance actually causes audible differences.

Until we have the measurement results I guess we have to say "interesting theory".

 

[jkeny]

Yes, Julf, "interesting theory" & that's all I posted it as but up until this post you were claiming that there was no possibility or chance of any systems' issues on the PC having an influence on an asynch USB DAC.
Now you say that it's a possibility (although unlikely) as are the other possibilities you mention along with still more possibilities of ground noise, common mode noise riding on the USB cable along with the "real-time enough" digital data.

I agree that tests/measurements are needed but these are proving to be elusive as I have said all along. Your statement of how easy it would be to do these measurements is again simplistic & an old debating trick often cited in this field.

I predicted this line of argument on another thread that we had an exchange on - it's like the grieving process - it goes through recognised stages (but this time it's the giving up of an idea & not a loved one). It goes something like this:
- firstly denial
- then acceptance of the possibility (but unlikelihood)
- then the demand for measurements
- then the denial that the measurements could be audible
- then the demand for DBTs

And so it goes around & around.
While in the meantime we listen & hear the effects of this "yet to be determined mechanism"
C'est la vie, I guess!

Edit: Oh & btw the technical claims to date in this thread have been to deny the possibility of ANY mechanism for Jplay's SQ improvements. Once a number of technical possibilities are offered where does that leave the original argument? Exactly where you have expressed "yes, it's a possibility but unlikely"

So what are your exact technical reasons for the statement that it is unlikely?

 

[Julf]

Yes, Julf, "interesting theory" & that's all I posted it as but up until this post you were claiming that there was no possibility or chance of any systems' issues on the PC having an influence on an asynch USB DAC.
Now you say that it's a possibility (although unlikely) as are the other possibilities you mention along with still more possibilities of ground noise, common mode noise riding on the USB cable along with the "real-time enough" digital data.

Ah, so even when I try to be polite and give you the benefit of doubt you try to use it against me

In that case, just to make it clear - no, I don't personally believe there is any merit to your speculation, and my suggestion of the mains-line-induced RF noise was firmly tongue in cheek, trying to come up with something equally far-fetched.

I agree that tests/measurements are needed but these are proving to be elusive as I have said all along.

Elusive, as in "nobody has been able to produce them despite it being fairly easy to do so", yes.

Your statement of how easy it would be to do these measurements is again simplistic & an old trick.

I went further than that. I told you *how* to make those measurements. The only way I could go beyond that is to actually do the measurements for you, but I doubt you would accept the results.

Wouldn't you call responding with "it's not that easy" to any suggestion of measurements somewhat simplistic and an old trick too?

While in the meantime we listen & hear the effects of this some "yet to be determined mechanism"

Some people seem to think they do hear them, yes. There are also people who see pink elephants under their bed. The pink elephants might be real too, as it is very, very hard to measure the existence of pink elephants. Anyone suggesting otherwise is being simplistic.

 

[jkeny]

As I said, if you can give the exact technical reasoning which leads you to claim my possibility outlined is "unlikely" then perhaps we have something to discuss!

 

[joelha]

I think it would be great if each person who posted mentioned whether they've tried JPLAY or not.

Those who have not tried it, even though there's a free trial, and are sure it won't do anything, mystify me.

You can't be surprised? Your understanding of the sciences surrounding this product are so all encompassing that you absolutely know what's going to happen?

If you don't have the time to try it, that's fine. No problem. But to not try it and be sure it's not going to do anything positive when so many others have a different experience?

You have a very different way of appreciating this hobby than I do.

Some of the best parts of my music listening have come as a result of the surprises I've experienced.

I have this vision of someone going into a restaurant with a friend. Each person has a different meal. The second person tells the first, "You have to take a taste of what I'm eating. It's fantastic". The first person says "What's in it?". The second person gives the ingredients and the first person says "There's no way that could taste any good". The second person protests and says, "But you have to try it. One taste and you'll see, and if you don't like it then you don't have to try it." Some in the restaurant chime in and say they've tried it and don't enjoy it but other says they have tried it and think it's very good. The first person decides not to try it and persists in saying it simply can't be any good.

If everyone had such an attitude, our hobby would not be nearly as fun and interesting as it is.

Joel

 

[Julf]

As I said, if you can give the exact technical reasoning which leads you to claim my possibility outlined is "unlikely" then perhaps we have something to discuss!

Let's start with how it is rather unlikely that minute timing variations in the incoming data would cause major differences in the noise level of the circuitry.

 

[Julf]

I have this vision of someone going into a restaurant with a friend. Each person has a different meal. The second person tells the first, "You have to take a taste of what I'm eating. It's fantastic". The first person says "What's in it?". The second person gives the ingredients and the first person says "There's no way that could taste any good". The second person protests and says, "But you have to try it. One taste and you'll see, and if you don't like it then you don't have to try it." Some in the restaurant chime in and say they've tried it and don't enjoy it but other says they have tried it and think it's very good. The first person decides not to try it and persists in saying it simply can't be any good.

I think a more appropriate analogy is every person ordering the same choice, but one person using a spoon instead of a fork, and stating their food tastes much better than your meal because eating it with a spoon makes food taste better. Even if you respond "I have tried using a spoon a lot of times, and it never made any difference", the person will say "ah, but you haven't tried *this* food with a spoon".

 

[jkeny]

Let's start with how it is rather unlikely that minute timing variations in the incoming data would cause major differences in the noise level of the circuitry.

Please elucidate as I don't see any technical reasoning in your statement - your juxtaposition of the words "minute" Vs "major" is not what I call technical arguments. I thought you claimed to be an EE?

 

[Groucho]

Even with asynch USB there is still a variability in data delivery timing. So one possible mechanism whereby timing variability on the HOST PC could (remember this is me just throwing out one possibility for consideration) have an affect on an audio DAC is if there is still a PLL operating on this data. Normally the PLL derived clock is used to generate the I2S stream for the DAC chip but in asynch DACs, this I2S stream is reclocked by the local clock. So does this not mean that the DAC is immune to incoming data jitter? Maybe not - the feedback loop of the PLL will vary depending on the variations in incoming USB data timing. This variation in the PLL feedback loop will track the variation in the USB data stream. Will this give rise to some variable noise/PSU/ground issues? Possibly?. I believe the same data correlated noise phenomena has been reported by Jocko Homo in relation to SPDIF PLLs where he has stated something along the lines "has anybody listened to the PSU driving the PLL & heard how it varies"

The way I see it, if I were designing an asynchronous DAC, I would be concentrating on making the sample clock and converter sections very close together, powered and linked to the outside world in such a way that they were as immune as possible to the effects of RFI, power supply contamination and so on - that's the critical part. Then, all the other stuff involving data streams (and PLLs if necessary) would be almost irrelevant in terms of its influence on the output signal. I don't know if all DACs are designed this way, but I would bet that most are.

 

[joelha]

"I think a more appropriate analogy is every person ordering the same choice, but one person using a spoon instead of a fork, and stating their food tastes much better than your meal because eating it with a spoon makes food taste better."
Your analogy betrays your bias, Julf. You're as certain that the difference between JPLAY and not using JPLAY is as clear as the use of a fork or a spoon with a certain kind of food?
Honestly, in my opinion, that's too bad for you.
You're possibly missing out on something great.
Joel

 

[Phelonious Ponk]

The history of the audiophile endeavor is filled with long, detailed, seemingly technical, psedo-scientific explanations of possible reasons for things people hear which channot be explained, verified or measured. This is just the digital chapter.

http://en.wikipedia.org/wiki/Occam's_razor

http://en.wikipedia.org/wiki/List_of_cognitive_biases

Tim

 

[Julf]

Please elucidate as I don't see any technical reasoning in your statement - your juxtaposition of the words "minute" Vs "major" is not what I call technical arguments. I thought you claimed to be an EE?

I feel like we are heading down an endless debate over non-issues here. Let me rephrase then:

Let's start with how it is there is a statistically significant probability that timing variations in the incoming data as small as those seen in normally operating computer USB interface would cause differences in the noise level of the circuitry of a magnitude that would affect the normal operation of a DAC.

 

[Julf]

Your analogy betrays your bias, Julf.

Of course - just as your analogy was reflecting your own bias.

Honestly, in my opinion, that's too bad for you.
You're possibly missing out on something great.

I know. The story of my life.