JPLAY Responds: An Open Letter

[jplay]

>My ask is to not keep assuming I don't know something like a real-time system.

Huh - You sent 'real-time wiki' link to _me_ !!!
And I thought it hilarious, a friendly kick in the butt...(far too many smiles in your posts gave you up...)
But ok - for whatever language/culture reason we seem to have some communication issue here so better sleep over this and discuss tomorrow with clear heads...

 

[Steve williams]

your analogies make for easy understanding for me Amir.

 

[opus111]

His motivation is that people said smaller buffers sound better. If I were him, I would have tested that concept with some measurements before running off and making ton of changes to the playback pipeline to keep the system from falling behind.

Seems to me not to be the optimum approach. 'Better' is too subjective to begin with, rather descriptions of the differences need to be collected and compared to see if there's any correlation between what the claimed 'thousands' of listeners heard. If there's not enough commonality in the listening reports then further listening would need to be done using standard test music tracks chosen to highlight what the changes might be. Assuming that there is eventually correlation found between the descriptions then a hypothesis needs to be dreamed up to test for what's thought to be responsible. At no point so far in the process are measurements necessary.

 

[amirm]

Seems to me not to be the optimum approach. 'Better' is too subjective to begin with, rather descriptions of the differences need to be collected and compared to see if there's any correlation between what the claimed 'thousands' of listeners heard. If there's not enough commonality in the listening reports then further listening would need to be done using standard test music tracks chosen to highlight what the changes might be. Assuming that there is eventually correlation found between the descriptions then a hypothesis needs to be dreamed up to test for what's thought to be responsible. At no point so far in the process are measurements necessary.

I don't know how to read the tea leaves from subjective reviews that way. If you know better, feel free to teach me . Here is a sampling of comments from 6moons review:

"Several months ago while reviewing John Kenny’s excellent JKSPDIF Mk3 and JKDAC32, Kenny pushed me to try JPlay, a simple non-GUI music playback program with a tiny memory footprint. I held little initial interest as I was content with J. River’s obvious sonic improvement over Foobar and iTunes and was reluctant to add another variable in the middle of a review. Eventually I downloaded the freebie demo however and was surprised that music was clearer, more palpable and dynamic than over JRMC.

[...]

With my preferred settings I experienced a more visceral fuller presentation with a more open delineated top end with less hash. This was particularly noticeable on cymbals and high strings. Musical textures were more apparent as well as a sense of greater openness or air. Bass was deeper (who doesn’t want more bass?) and more articulate and propulsive. In fact I thought the way JPlay handled the lower end of the spectrum was exceptional and significantly superior to what I usually hear from CD playback. "

 

[Shum3s]

Have you listen to Jpay for your self,like you would a new amp or any kind of new equipment that you are interested in? I would love to get your feed back after you demo the free trial. Sam

 

[amirm]

Have you listen to Jpay for your self,like you would a new amp or any kind of new equipment that you are interested in? I would love to get your feed back after you demo the free trial. Sam

I plan to do that. Been too busy redoing all the electronics for my boat and no time to spend in this area. Once I get a breather, I will do so and report back.

 

[Shum3s]

The question above is to ACK, not you admir, I messed up the sequence of my post 'in real time' Sam

 

[opus111]

If you know better, feel free to teach me .

Sure - lesson #1 is don't go to 6moons for anything other than the pictures. Its for audio porn only.

 

[Julf]

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, or you don't. That is pretty black and white. If you don't drop data, there is no audible effect. If you do drop data, the effect might or might not be audible, but if it is only occasional, it doesn't affect the sound quality most of the time - only occasionally. A trained listener should be able to say "something happened there". It would also be easily measurable.

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.

 

[jkeny]

A few things. If USB loses some data, there is no way a software player like JPlay will know about it and do anything about that. Such a failure happens down stream and the media player and even the OS will be blind to it. Such failures can occur in theory. But in short connections and typical applications, they just don't occur. If they do occur, they would immediately show up in measurements.

There are mechanisms in the isochronous USB protocol whereby delivery errors can be detected - this would be at the driver level. I'm not sure if these USB drivers actually implement any retry mechanisms? Jplay would not need to be aware of these errors but simply create a more stable environment where fewer or no errors occurred & therefore fewer/no retries. I agree that if the final reconstructed datastream was missing data, it would be seen in measurements but my reason for framing the question was to ascertain if anybody had a deeper level of understanding of USB audio drivers

Why don't we count how many electrons are going past the cable to make the numbers even more impressive . Your software player is not in charge of serializing the bits and sending them on USB bus. A dedicated piece of hardware does that. The role of the software is to provide a chunk of data from which the hardware siphons the bits. It is like you driving the car. You change the accelerator. The computer in your engine takes that and then modulates the fuel injectors with extreme accuracy measured in microseconds. The fact that they do that, does not mean that you need to move your foot with the same microsecond precision or that if you did, you would change the way the injectors work.

This is a fundamental way non-real-time systems are made real-time. We allocate pools of memory and dump lots of data in there when we get a chance. The hardware then on precise intervals meters the bits out. We get to be sloppy and non-real-time while the system as a whole stays real-time.

From the last post by JPlay, it seems that he undone the above mechanism by making the buffer small. Once he did that, then he created a world of hurt for himself since now he has to service the hardware on much more frequently and on more precise timing requirements. He took an easy job and made it hard. His motivation is that people said smaller buffers sound better. If I were him, I would have tested that concept with some measurements before running off and making ton of changes to the playback pipeline to keep the system from falling behind.

As an analogy, he is saying in winter you can just put a t-shirt and go outside. But to not freeze, now you need to run all the time to stay warm. Me? I would question why we would want to put a t-shirt on in winter .

But these USB data packets are NOT delivered in as accurate a manner as you make out here. If it was as precise as you make out why then would we have any issue whatsoever with using Adaptive mode USB for audio, where the clock is derived from the timing of delivery of the USB data packets using a PLL? Surely if the data packets were delivered as precisely as you say this would be a perfect system for audio & asynchronous USB would never have been created? To use your car analogy, in this scenario we are experiencing the car slightly speeding up & slowing down constantly - not a pleasant experience for the car's occupants - certainly not as pleasant as a constant, steady, smooth pace.

I'm just asking questions which try to address some of the simplicity around what's being said in these posts. We are dealing with a non realtime system & using it for realtime data delivery - it's not as trivial or simplistic as just throw a buffer or two in there & all will be fine, sure isn't the PC fast enough & look sure isn't it's CPU only working at 5% of it's capacity, so the hardware will handle it.

 

[jkeny]

I don't know how to read the tea leaves from subjective reviews that way. If you know better, feel free to teach me . Here is a sampling of comments from 6moons review:

"Several months ago while reviewing John Kenny’s excellent JKSPDIF Mk3 and JKDAC32, Kenny pushed me to try JPlay, a simple non-GUI music playback program with a tiny memory footprint. I held little initial interest as I was content with J. River’s obvious sonic improvement over Foobar and iTunes and was reluctant to add another variable in the middle of a review. Eventually I downloaded the freebie demo however and was surprised that music was clearer, more palpable and dynamic than over JRMC.

[...]

With my preferred settings I experienced a more visceral fuller presentation with a more open delineated top end with less hash. This was particularly noticeable on cymbals and high strings. Musical textures were more apparent as well as a sense of greater openness or air. Bass was deeper (who doesn’t want more bass?) and more articulate and propulsive. In fact I thought the way JPlay handled the lower end of the spectrum was exceptional and significantly superior to what I usually hear from CD playback. "

Amir, I have been recommending Jplay to all my customers but without prompting them as to what they will hear.
The consensus I have gathered from when/if they report back concurs with my own & others experience of the sound.
Do they come to this universal consensus through reading what others have said about it - I don't think so but maybe some do?
If you are saying that this is mass suggestion in operation, I disagree with you. If you are saying that everybody is deluding themselves in exactly the same way & hear the same improvements with Jplay, then I disagree with you.

 

[jkeny]

Either you drop data, or you don't. That is pretty black and white. If you don't drop data, there is no audible effect. If you do drop data, the effect might or might not be audible, but if it is only occasional, it doesn't affect the sound quality most of the time - only occasionally. A trained listener should be able to say "something happened there". It would also be easily measurable.

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.

But the point is that nobody yet knows what to measure & what level of precision is necessary.

 

[Julf]

But these USB data packets are NOT delivered in as accurate a manner as you make out here. If it was as precise as you make out why then would we have any issue whatsoever with using Adaptive mode USB for audio, where the clock is derived from the timing of delivery of the USB data packets using a PLL? Surely if the data packets were delivered as precisely as you say this would be a perfect system for audio & asynchronous USB would never have been created? To use your car analogy, in this scenario we are experiencing the car slightly speeding up & slowing down constantly - not a pleasant experience for the car's occupants - certainly not as pleasant as a constant, steady, smooth pace.

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.

 

[Julf]

But the point is that nobody yet knows what to measure & what level of precision is necessary.

A lot of us know how to measure for dropped USB data. It is not hard. And it can be measured down to a single missed bit - no more precision is needed, unless you believe in half bits.

 

[opus111]

The consensus I have gathered from when/if they report back concurs with my own & others experience of the sound.

Any descriptions available?

If you are saying that this is mass suggestion in operation, I disagree with you. If you are saying that everybody is deluding themselves in exactly the same way & hear the same improvements with Jplay, then I disagree with you.

If those are indeed the favoured hypotheses then they do need to be testable in practice or science isn't being done. I can't see how a 'mass suggestion/mass delusion' hypothesis is a testable one myself but of course I'm open to suggestions.

 

[jkeny]

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.

Huh? We are talking about USB, not SPDIF.

 

[jkeny]

Any descriptions available?

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.

 

[jkeny]

A lot of us know how to measure for dropped USB data. It is not hard. And it can be measured down to a single missed bit - no more precision is needed, unless you believe in half bits.

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."

 

[Julf]

Huh? We are talking about USB, not SPDIF.

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

 

[Vincent Kars]

There are mechanisms in the isochronous USB protocol whereby delivery errors can be detected - this would be at the driver level. I'm not sure if these USB drivers actually implement any retry mechanisms?

In case of UAC1/2 it is isochronous mode. As this is a quasi real-time stream you can’t do a retry. The retry will simply arrive too late.
As far as I know, a retry is not part of the isochronous mode protocol.
The funny thing is that SPDIF and isochronous USB are pretty much alike. It is unidirectional, you can check at the receiver if there is an error but now way to correct this error.
Older M2Tech models used bulk mode. Here a retry is part of the protocol.