JPLAY Responds: An Open Letter

[jkeny]

Then dispense with the technical talk of what the software does and try to reason why it improves things. Because if that logic is correct, it is measurable. We are discussing a specific technical claim for which there are measurements: noise and jitter. If your claim is that noise and jitter are not changed yet you think it still sounds better, that's cool. Confirm that is what you are saying and we are done discussing technical points.

The technical points were/are conjecture on my part as to how Jplay might be operating to benefit the sound. Now that Jplay are here to answer for themselves, I'm sure you can argue technical issues with them. But your definition of "real-time enough" into a simplification that the sound either glitches or it doesn't, now seems to deny the existence of timing jitter. Let's step back to what Jplay posted - for USB DACs that DO NOT work asynchronously, do you deny that timing issues on the PC can cause them to sound different, not just glitch or not glitch?

BTW, what is your definition of a "glitch"?

Edit: Hell, let's make it simpler - for on-board DACs do timing matters cause jitter in them?

We are coming at this from 2 very different viewpoints:
- I'm starting with the knowledge that Jplay improves the sound & conjecturing how this might be technically
- you are coming at it from the position of proof/measurements/technical points & seem to be denying that it can improve the sound on that basis alone

 

[jplay]

>Thanks for joining our forum Jplay and warm welcome despite the contentious aspect of the interchange that brought us together.

Thank you for your welcome and opportunity to express opposite views – I don't see the point as contentious just lively. Apologies for formatting: seems it gets stripped away when I copy/pasted into forum editor (I have bad experience with forum text editors and tend not to use them)

>I will make some brief comments which I may add more to when I am in better mood and can think better

Sure, take your time – I’ll do the same with your comments:

? 1. You provide a lot of detail on the changes you made to make the system more real-time. None of that matters because existing players are "real-time enough."

So high-end CD transport manufactures targeting picosecond jitter measurements are wasting their time because if you don’t hear any audio glitches timing is already ‘good enough’? Just attach a cable to DAC, it will reclock anyway, done?

Please read again section on buffers: ‘existing players’ all use relatively large buffers to ‘cheat away’ fundamental issue of having to provide a real-time service (audio streaming) in a decidedly non-realtime environment which offers few promises and no guarantees about timing whatsoever.
Nothing wrong with that except experimental evidence suggests _smaller_ buffers seem to increase sound differences (yes, most say ‘it sounds better’ and no, I don’t have a nice graph for you – shoot me) but are much harder to work with as danger of glitches increases exponentially. So I’m afraid ‘it matters’.

>But in the manner our members use the system, usually as a dedicated machine, the system is real-time as a CD player is in that audio is not interrupted.

No offense but you cannot twist definition of real-time as you see fit: it either is or isn’t realtime.
CD player, by definition, is realtime and Windows is not.
These are facts which do not depend on ‘manner of usage’ and have nothing to do with whether audio is interrupted or not.
If you play a scratched CD and audio gets interrupted does that suddenly turn CD player into a non-realtime system?

>No one I know that buys your software has expressed that they bought it because Jriver glitched and yours didn't.

Good – otherwise it would mean JRiver is utterly broken ?
Seriously: who ever suggested anything of the sort? The whole point is not about glitches but whether ‘good enough’ is enough or can be improved by optimizing the environment.

>You say you are software guy. That is a problem… I live and breath the full spectrum and it is in that context that I find issues with your approach.

I freely admit not being particularly smart and not having multiple hats like you do and I am happy for you. I have no intention to debate with your other hats as those are beyond my limited competence but you did talk about software in your post and this guy with no hat at all felt you were incorrect on several important points, whichever hat you were wearing – that’s all.
If you think my descriptions were in error please do correct me like I corrected you on specific points.

>You should measure and document….You need to add other skills and disciplines to your assets to understand why I predicted that measurable improvements would not be there and that is what has come to pass.

Amir – I’m a flawed human being with limited skillset but that’s just how it is: take or leave it. It’s a bit too late for me to go back to school and get multiple PhDs so if that is required to be able to enjoy the music or participate in this forum then I’ll respectfully move on.

Cheers,
Josef

 

[amirm]

? 1. You provide a lot of detail on the changes you made to make the system more real-time. None of that matters because existing players are "real-time enough."

So high-end CD transport manufactures targeting picosecond jitter measurements are wasting their time because if you don’t hear any audio glitches timing is already ‘good enough’? Just attach a cable to DAC, it will reclock anyway, done?

No. These are two different topics:

1. Whether the system is predictable or fast enough to play audio samples without interruptions. This is what is meant by "real-time." If the system is real-time enough, the job is done. Making more real-time is of no value. Imagine a robot on factory floor working on assembly line. It may need to start its job in say, 1/10 th of a second. Making it work at 1/10000 of a second will have no value whatsoever. A missile however travelling at > speed of sound needs to be real-time but at much lower latencies. This is a fundamental concept in building real-time systems. You only need to be real-time enough for the application.

In this scenario, redbook CD needs an audio sample once every 1/44100. If we can give the hardware 100 bytes at a time, then we need to service it 1/441 seconds and so on. As long as we are at that level of latency or faster, then we have achieved our goal and being better gets us zero points with the end customer since the system does not work any better.

As I noted, every computer server that people deploy plays audio samples at the required rates as to not cause interruptions. If there were audio drops, we would hear them and they would massively show up in measurements as we would get a glitch that shows up as a ton of distortion. So the system is real-time enough. And fundamental principal of real-time systems says there is no more merit than being better.

2. Fidelity differences with respect to DAC clock accuracy. This has nothing to do with the above concept. I can vary the clock jitter by many nanoseconds with the system still playing reliably with no glitch. Distortion however would be generated due to jitter and this is what high-end companies aim to minimize. A $10 CD player and a $10,000 one however, are both real-time enough to play the same content. Neither glitches when playing audio.

Yes, there is a point at which clock jitter can cause lock to be lost and we get a glitch. That is not a concern here. Again, no one has experienced jitter lock being lost with their DAC and fixed it with Jplay.

I did not set a target for clock jitter when I said "real-time enough" as you imply. Real-time enough strictly applies to proper functionality per #1 above, not fidelity. Your responses and claims for the software constantly mix these two topics together.

Please read again section on buffers: ‘existing players’ all use relatively large buffers to ‘cheat away’ fundamental issue of having to provide a real-time service (audio streaming) in a decidedly non-realtime environment which offers few promises and no guarantees about timing whatsoever.

As I said, it is off-topic. I can play music 100% reliably with all of these media players. They are all for the purposes that we have, are "real-time." You have made the system no more reliable by the changes you have made since the end experience is the same: JRiver plays without interruption, you play without interruption.

Yes, at the core, the system is still not real-time. I can for example put the disk drive in sleep and if you try to play, it will take a few seconds for it to wake up to play. You could also have too little memory and start up photoshop and have it cause paging and playback glitching. If these were real problems for users and you made them better, then you would have a case there. But these are not problems people face or care or think about fixing with your software. Your marketing message is a fidelity improvement, i.e. #2 above. So the constant talk about #1 is a distraction.

Nothing wrong with that except experimental evidence suggests _smaller_ buffers seem to increase sound differences (yes, most say ‘it sounds better’ and no, I don’t have a nice graph for you – shoot me) but are much harder to work with as danger of glitches increases exponentially. So I’m afraid ‘it matters’.

Have you taken any blind tests and seen how accurate your assessments are? If not, you should. I was once helping my codec team optimize our encoder. They gave me a dozen parameters I could tweak. I tweaked them over many painful days to many decimal places. The team was shocked as they told me none of the fractions were used. I told them they were crazy as I could easily hear the difference. They give me two sets of files and ask if I can tell the difference. I listen and I say sure, they sound different. They tell me they were identical! And this is coming from someone who was trained as an expert listener and could hear artifacts few people could. So while I am not dismissive of subjective assessments people make, they don't have value when they try to convince *me* of some technical fact.

The bloggers that have tested your software took the analog output of the DAC and analyzed it. All that happened up stream including the buffer changes, real-time this and that, was ultimately boiled down to that waveform. Those waveforms did not differ with or without your software down to the accuracy of testing. So I am afraid you do need to have your own graph to counter them. Everything else is hand waving.

As I noted to John, you are making specific technical claims, connecting certain dots. That theory can be easily tested as the bloggers did. And their results, says that your theory is not valid in their tests. Of course they did not test all scenarios. So maybe it matters elsewhere. Problem we have is that you, as the proponent of these changes, have no data either. I even gave you the low hanging fruit: take the PC motherboard sound and see if your changes make a difference there. I think there is some chance that it might there. But you are not going there. And certainly have not in the past.

As with my experience above, you may very well have heard the wrong thing as have other's testimony you are using here. You need some way of ruling that out. For your own sake if not ours.

>But in the manner our members use the system, usually as a dedicated machine, the system is real-time as a CD player is in that audio is not interrupted.

No offense but you cannot twist definition of real-time as you see fit: it either is or isn’t realtime.

Well, it is an offense because the first company I worked at was in the business of selling real-time systems for such applications as flight simulation. I was hired on to work on Unix and to see if we could make it real-time enough vs their proprietary system. We did not get there but in lighter applications we did manage to make Unix "real-time enough." I worked there for many years in 1980s so please don't tell me what a real-time system is or isn't. Or what its definition is. I know what it is as it was my job to know.

Your comment above indicates that you are not familiar with how real-time systems are quantified. I hate sending you to the Wiki but let me do that and save some typing: http://en.wikipedia.org/wiki/Real-time_system

CD player, by definition, is realtime and Windows is not.

Windows is not. But if I play a track on my music server, it is every bit as real-time as CD player. It plays the track without interruptions. And again, no one is buying your player to fix a problem there.

These are facts which do not depend on ‘manner of usage’ and have nothing to do with whether audio is interrupted or not.
If you play a scratched CD and audio gets interrupted does that suddenly turn CD player into a non-realtime system?

If the retry mechanism in the CD player takes too long, yes. The system needs to have enough buffering to keep playing while that retries. If the media cannot be read at all, that is a system failure and has nothing to do with the topic at hand.

>No one I know that buys your software has expressed that they bought it because Jriver glitched and yours didn't.

Good – otherwise it would mean JRiver is utterly broken ?
Seriously: who ever suggested anything of the sort? The whole point is not about glitches but whether ‘good enough’ is enough or can be improved by optimizing the environment.

90% of your marketing material and explanations go toward this point. You have people like JKeny who then believe it to mean fidelity is improved which is an orthogonal topic as I noted in the start of this answer.

>You say you are software guy. That is a problem… I live and breath the full spectrum and it is in that context that I find issues with your approach.

I freely admit not being particularly smart and not having multiple hats like you do and I am happy for you. I have no intention to debate with your other hats as those are beyond my limited competence but you did talk about software in your post and this guy with no hat at all felt you were incorrect on several important points, whichever hat you were wearing – that’s all.
If you think my descriptions were in error please do correct me like I corrected you on specific points.

I don't want to lose the audience over detail that is off-topic. I might comment on them later but for now, we have to get one thing clear: you can't confuse changes that make the system more real-time with higher fidelity. You either agree with this or we stay on it 'till we resolve it.

>You should measure and document….You need to add other skills and disciplines to your assets to understand why I predicted that measurable improvements would not be there and that is what has come to pass.

Amir – I’m a flawed human being with limited skillset but that’s just how it is: take or leave it. It’s a bit too late for me to go back to school and get multiple PhDs so if that is required to be able to enjoy the music or participate in this forum then I’ll respectfully move on.

Cheers,
Josef

Those skills are required if you want to convince *me*. It is not a requirement to enjoy music or stay in the forum. And you don't need to go back to school either. Just need to read and accept a bit what I am saying .

 

[egidius]

for the last sentence: hats off!

No. ......

Those skills are required if you want to convince *me*. It is not a requirement to enjoy music or stay in the forum. And you don't need to go back to school either. Just need to read and accept a bit what I am saying .

I must say: Me being a violinist, I would not pretend to understand your facts, but I can understand your reasoning, which, especially with your last sentence, gets almost artistic elegance . Hats off to you!
But no, I don't think it will suffice ;-)

 

[Steve williams]

I must say: Me being a violinist, I would not pretend to understand your facts, but I can understand your reasoning, which, especially with your last sentence, gets almost artistic elegance . Hats off to you!
But no, I don't think it will suffice ;-)

accept a bit what I am saying

Amir

this is what we call "bit perfect"

Well stated and I must say even understood by me

 

[Phelonious Ponk]

Thanks for the link. It is a strange and misleading response. It even starts wrong:

"'Simpler is better' is an old rule frequently quoted by designers of audio-equipment. However, some say we should completely forget this rule when it comes to computer audio: They say, computers are so 'fast' and audio reproduction such a relatively 'easy' job for a computer, that any computer, regardless of hardware or software used, will sound absolutely identical provided the data is 'bit-perfect' (as in: digital audio bits are not modified by equalization, digital signal processing, etc). And they add that once a computer outputs 'bit-perfect' data then all those who claim to hear a difference between software players or operating systems or computer hardware are ‘delusional’ at best and, at worst are 'scammers' and 'hoaxsters'!"

No one is saying that simpler is not better. We are saying that they can't and aren't making things simpler. They may think they are, but they aren't. If the path to your destination takes 1000 turns and you change one of them, you have not made the journey less complex. It is that complexity that they cannot tame. While it is the position of Jriver that bit-perfect equals perfection, it is not mine. I acknowledge that timing is involved. The problem is, as they later say, the PC is not a "real-time" device no matter what you do in the app. Ultimately the operating system has a higher priority than any process in the system and it is the entity that decides what happens next.

"Unfortunately, for digital audio, timing is an essential requirement: the official standard for CD playback says 32 bits must be played precisely every 22 microseconds: if this timing is 'off', even by a very, very small amount, the output, by definition, is no longer in line with the technical specification for CD playback. In other words: digital playback must not only be 'bit-perfect' but also 'timing-perfect'. That is why many modern DACs often showcase 'jitter' measurements (denoting a DAC’s timing precision) at the _pico_second level (1 picosecond is only 0.000001 microseconds!).

And that is what JPLAY is all about: improving timing."
What confusing logic. First of all, if the timing is not maintained, you get a glitch or data loss. If the target device is fed data late, it will have to make it up on its own and hence will cause an audible distortion that cannot be missed. If it runs behind, then data is dumped on the floor and effect again, will be anything but subtle.

Stepping back, the way this a non-real-time PC is made into a real-time one is to create a buffer, a pool of memory, were audio samples are prefetched and put there. The hardware also has a buffer but usually much smaller one that it uses to make sure it can output things on time. When its buffer starts to empty, it will force the compute to stop with what is called an "interrupt." All activity in the computer stops at that point and a piece of software called a "driver" for that device (e.g. USB for USB DAC) starts to run and it takes data from computer memory and sends it to the hardware to push out. The job of an application is to keep giving data to the driver so that when that critical time comes, it has plenty of data to send out. Once you achieve glitch-free operation here, doing better and faster will mean nothing. This is why if you bought a computer that is 100 times faster than you need will not result in audio playing any better. This deals with the first sentence.

The rest of what they say has nothing to do with the above factor. What is being described is classic timing jitter. If you are using a low-quality digital output directly from your computer or its DAC, then it likely has fair amount of jitter. Source of jitter is varied and a lot of it may have nothing to do with what the app is or is not doing. Some of it may be due to CPU activity and changing that, might impact it. JPlay has no data at all that they are able or have impacted this worst case situation.

Here is the other problem: the audience for this player is not the guy who is running the motherboard S/PDIF or a DAC on the computer. Instead, it is someone who is likely using a high-quality interface that is not dependent on the quality of the clock out of the PC. Assuming so, then the situation gets hard, really hard. That is because a proper async interface does not use any clock out of the PC. It has its own system similar to what I described above where the DAC calls the shots as far as when it needs the next chunk of data. In that sense, it has isolated itself from the PC clock altogether.

"While some audiophiles will manually optimize the Windows OS on their servers, JPLAY adds to that process by increasing the computer's timer resolution accuracy to the maximum possible."

I don't know what timer they think they have changed. But there is no facility whatsoever to change the S/PDIF clock accuracy under program control or that of USB, etc. All of those run at hardware governed rates and no software is able to change them.

Maybe they have mucked with the operating system time. Windows allows the default 15 msec timer to be changed to smaller values. But such changes will not at all control the hardware clocks per above. The change will increase the CPU load also and could have unpredictable impact on the time jitter should that interface be on board. A 15 msec timer should it create jitter, will be at about 70 Hz (1/.015) which is masked perceptually. Increase resolution to 1 msec and now the jitter will be at 1000 Hz and you just made that jitter more audible by pushing it out of the shadow of the music signal.

And what happened to making things simpler? More timer interrupts increases the load, not reduce it.

"JPLAY uses special ultra low-latency RAM to store music samples and massively pre-queues them so the sound driver can access them faster."
As I explained, once you keep up with the hardware, it matters not how much faster you make it. The hardware, in this case, the audio driver and audio click, drive the speed requirements. And by definition, all players put their audio samples in high-speed system memory which is thousands of times faster than what the audio DAC needs.

"It’s important to note that the corporation accusing JPLAY of being a 'hoax' does not, in fact, deny JPLAY is performing this massive "audiophile re-programming" of Windows. No—Instead, this corporation denies that, despite JPLAY’s actions, JPLAY has any impact on sound quality whatsoever. Their "proof" is that JPLAY does not have any 'technical measurements' to demonstrate an improvement in sound quality.

Sure, we don’t have all the 'technical measurements' we would like: The simple fact is, while there are plenty of DAC measurements regarding jitter, when it comes to using a computer as a digital transport, there simply aren’t any! Nobody has quite figured out how to measure ‘computer jitter’ (or 'computer noise'), which others propose is the "real" cause of the sonic differences in software and/or hardware."

So they did all of these optimizations yet had no way of measuring if any of them did any good? How do they know they did not make things worse?

And such measurements readily exist. I published my article in WSR magazine a couple of months ago and there are ton of measurements around online, including the specific ones that showed Jplay not changing noise or jitter. Those tests were trivial to put together and run. Just a PC with a sound card and free software to analyze what it the other PC is outputting. We are readily able to measure if the PC changes impact what comes out of the DAC which is ultimately what we need to see.

If he is talking about measuring jitter as it comes out of the PC (e.g. on USB) that can also be easily done with a digital scope. There is no mystery there. As tests go, it could not be any easier to set up and run.

"While we’re certain technical measurements will come in time, computer audio is still a new field—and while we're certainly looking forward to working with anyone advancing the state of art, we do believe we have the best measurement equipment on the planet: the ears of thousands of passionate and discerning audiophiles who have tested dozens of JPLAY versions by ear alone…"

So just say this. Don't try to claim technical points that are not founded or backed by any objective data.

You're too kind, Amir. My reaction was simply "what a crock." And I haven't a fraction of your technical knowledge and ability to recognize the nuanced BS in that crock.

Tim

 

[Phelonious Ponk]

"JPLAY uses special ultra low-latency RAM to store music samples and massively pre-queues them so the sound driver can access them faster."

I wonder how this piece of software is able to mount special ultra low-latency RAM in my laptop

Elves.

Tim

 

[audioguy]

Elves.

Tim

Low Latency RAM Elves, to be specific.

I don't remember the first part of the expression exactly but it went something like, "if you can't dazzle them with brilliance, then baffle them with bull$hit".

Simply mind-boggling.

 

[Vincent Kars]

Reminds me of Mark Twain

It is better to keep your mouth closed and let people think you are a fool than to open it and remove all doubt.

 

[jkeny]

Hey, let's try & keep this thread devoid of sneering & derision.
Did people read the question I asked about this low-latency RAM & if it was the CPU cache area that was being alluded to?

 

[Steve williams]

Hey, let's try & keep this thread devoid of sneering & derision.
Did people read the question I asked about this low-latency RAM & if it was the CPU cache area that was being alluded to?

John

when I read that it came across to me that you were prompting him. I'm no guru on the subject but as I see it, isn't the onus of responsibility on the person who signs off on the document before you put it upon the web. Did he even read it?? Even worse, I guess, is if he did read it and sign off on it and allow it to be published, you get my drift

Credibility becomes an issue

 

[Imperial]

Reminds me of Mark Twain

And P.t Barnum said?

This is really getting silly good people!
Many people use their ears. A few their good manners...

Imperial.

 

[jkeny]

John

when I read that it came across to me that you were prompting him. I'm no guru on the subject but as I see it, isn't the onus of responsibility on the person who signs off on the document before you put it upon the web. Did he even read it?? Even worse, I guess, is if he did read it and sign off on it and allow it to be published, you get my drift

Credibility becomes an issue

Steve, I don't fully understand your post - I prompting Josef? I asked a question - I'm sure he will answer it.
I'm not sure what you mean about "signing off on the document" - are you talking about the original open-letter? Have we not had a more detailed explanation of this open-letter which fills in some of the grey areas which came under criticism, one of which was the low-latency RAM explanation?

As you had admonished me in the recent past about my style of posting - I find the last number of posts to be entering into sneering, derision & enticement to a flame-war, don't you? The tone of this thread so far had been respectful & interesting, avoiding ad-hom, flame-warfare. Do we want to reduce it to that level now?

 

[jplay]

Amir – Your initial answer was, quite frankly, a bit lacking on specifics - so I felt I had to increase temperature a bit just to see if you’re moonlighting or are genuinely serious about the topic. In retrospect I realize I may have crossed the line and pushed you a bit hard – I apologise for that!
Anyway, I challenged you to correct me where I was wrong like I corrected you: If you feel that sending me a wiki link is the adequate answer then, well, that’s a bit disappointing…
So please allow me to be very brief here:

>Whether the system is predictable or fast enough to play audio samples without interruptions. This is what is meant by "real-time." If the system is real-time enough, the job is done.

With all due respect there simply is no such thing as ‘real-time enough’ and it has nothing to do with ‘fast’ either: “Real-time programs must guarantee response within strict time constraints” (this quote from your wiki link)

Could be X microseconds, could be Y milliseconds but it simply can’t be Z of ‘enough’ – no such measuring unit.
If ‘enough’ was ok your example missile could explode over the ocean (or anywhere else) as long as it didn’t blow _us_ up…

During Windows NT days in ‘90s it was a common joke among real-time developers how MS fundamentally did not understand real-time and always came back saying ‘but computer is so fast – isn’t that enough?’

But ok, I understand you were not in that team and just meant something else than what you said, happens to us all - fine.

> Have you taken any blind tests and seen how accurate your assessments are? If not, you should.

To use your term, this is really ‘off-topic’ but sure, we have been doing a bunch of those over the years. But we're really not important:

During jplay 5 beta we had several hundred people all over the world with all kinds of equipment listening to over 20(!) different versions over a period of several months.
Every change prompted a reaction and whether positive or negative it was always a large majority….


> Those skills are required if you want to convince *me*.
…read and accept a bit what I am saying

Amir – I have no desire to convince ‘*you*’ of anything.
And as I said in initial post it seemed to me we did have enough common ground for a mutually beneficial discussion. You agreed timing was important and had no issue with simple being better which is more than most would accept.
How about we both take a step back?

In your essay you argued in great detail that (quote) ‘jplay can’t & does not make things simpler’ based on how you see Windows working.
I replied addressing specific points where IMHO you had a fundamentally wrong idea of what happens ‘’under the hood’ in Windows and showed that jplay ‘_can_ & _does_ make things simpler’ and challenged you to disprove my assertions – that’s all.

It’s not about ‘convincing’: it’s about laying arguments for those specific points.

 

[jplay]

Low Latency RAM Elves, to be specific.

Simply mind-boggling.

audioguy & phelonius: No RAM Elves needed (nor any Elves): but, yes, it is 'mind-boggling' if you never heard of it before so your scepticism is understandable...

and no 'special chips' needed as Vincent alluded on other site: only a simple software technique which reduces latency - that is all....

 

[ack]

Having read this entire thread - and also being in the software business - I find Amir's "thesis" dead on. Not only do real-time systems have to be real-time enough _for the application_ as he explained (thus your attempt at throwing it out with this silly missile argument is just that) - and as long as buffers are >0 length all the time the server is real-time enough - a general-purpose computer can be only as real time as what we call the CPU's quantum, which on Unix is 1ms (therefore, best to buy a Mac-based PC server or similar, rather than Windows) and on Windows is _approximately_ 15ms (if you want to nitpick on Amir's comment, that would be the only thing), more realistically 15.6ms - see this if you are interested. So, as I said in the sister thread to this, *if* JPlay were to do anything beneficial in the PC-based music reproduction it would be related to jitter only; but as long as the buffers are full at the USB output side, it is simply irrelevant what JPlay may be doing to "optimize" things (and shutting down unused processes should be just as "optimal" - exactly what Mach2Music and others are doing with their PC-based servers). And as Amir said, if the analog output of the DAC has been measured to be precisely the same with and without JPlay, well, I call this QED. *If* JPlay shuts down unused processes, thus making sure buffers are always full that way that would not have been otherwise for whatever the reason, then I can see why some hear differences and others don't, based on the hardware and its configuration at hand. Otherwise, from a computer software and hardware perspective, JPlay is not convincing me that it does anything new or groundbreaking that would be more beneficial than other techniques (like shutting down processes myself).

 

[amirm]

Amir – Your initial answer was, quite frankly, a bit lacking on specifics - so I felt I had to increase temperature a bit just to see if you’re moonlighting or are genuinely serious about the topic. In retrospect I realize I may have crossed the line and pushed you a bit hard – I apologise for that!

I am serious about the topic. My ask is to not keep assuming I don't know something like a real-time system. That is like accusing your doctor that he doesn't know how to use a stethoscope . As I explained, I worked for a decade developing operating systems and making them real-time in a company that sold about $300M worth of hardware and software for critical real-time applications. In that post and here you keep going on about what I don't know about that topic.

Anyway, I challenged you to correct me where I was wrong like I corrected you: If you feel that sending me a wiki link is the adequate answer then, well, that’s a bit disappointing…
So please allow me to be very brief here:

>Whether the system is predictable or fast enough to play audio samples without interruptions. This is what is meant by "real-time." If the system is real-time enough, the job is done.

With all due respect there simply is no such thing as ‘real-time enough’ and it has nothing to do with ‘fast’ either: “Real-time programs must guarantee response within strict time constraints” (this quote from your wiki link)

Could be X microseconds, could be Y milliseconds but it simply can’t be Z of ‘enough’ – no such measuring unit.
If ‘enough’ was ok your example missile could explode over the ocean (or anywhere else) as long as it didn’t blow _us_ up…

I thought I explained this very topic. And the wiki does the same. Here is a relevant example from that:

"Consider an audio DSP example: if a process requires 2.01 seconds to analyze, synthesize, or process 2.00 seconds of sound, it is not real-time. If it takes 1.99 seconds, it is or can be made into, a real-time DSP process."

See, there is no talk of picosecond accuracy. A simple requirement of how much time you have and if you get there just in time, it is perfect. If you get there a hair later, you have lost the battle. I gave you an example of an audio device with 100 byte buffer. For playing Cd audio, if you can service that device in less than 1/441 seconds, you are golden. Nothing better whatsoever comes from getting there in 1/882 seconds. You would simply be faster than your device requires you and wasted your resources getting there. The device will only come back for more data 1/441 second. It is a relay sport. You are the front-end gathering data in a media player, and the hardware consumes it. The hardware is the time critical one. And it is only critical to what it is doing. This is the ABC of real-time systems. I have helped designed many and it is always application specific. I gave you the most common examples with one extreme being factory floor where hundreds of milliseconds may be OK, and a missile where micorseconds may be required for course correction.

During Windows NT days in ‘90s it was a common joke among real-time developers how MS fundamentally did not understand real-time and always came back saying ‘but computer is so fast – isn’t that enough?’

Windows NT was not a "hard" real-time system. They just added a few easy features to accomplish soft real-time tasks. I was not part of Microsoft then so have no idea what claims were made beyond that. The system is perfectly capable of being real-time to play audio. The proof is millions of people who everyday play music and don't go chanting in the street that there are pauses and glitches. Yet you keep talking as if that was an impossibility until your software came about.

Please answer clearly: do you think current media players are failing to be real-time? If so, what explains the fact that music plays continuously? You think if that happens they are still failing? Failing at what???

But ok, I understand you were not in that team and just meant something else than what you said, happens to us all - fine.

I meant every word I said.

> Have you taken any blind tests and seen how accurate your assessments are? If not, you should.

To use your term, this is really ‘off-topic’ but sure, we have been doing a bunch of those over the years. But we're really not important:

During jplay 5 beta we had several hundred people all over the world with all kinds of equipment listening to over 20(!) different versions over a period of several months.
Every change prompted a reaction and whether positive or negative it was always a large majority….

It is not off-topic when you put forward your ears as proof that your theories about computing are right as opposed to measurements. So now we get to examine how good your hearing is. Can you point to any objective data that says you are immune to placebo especially when it comes to your own software? Every bit of your posts and writing points to someone who thinks these changes make a difference. So of course you hear them. And so do all the other people. If ears are 100% reliable, how come some people like our own Bruce Brown didn't hear them?

> Those skills are required if you want to convince *me*.
…read and accept a bit what I am saying

Amir – I have no desire to convince ‘*you*’ of anything.

You wouldn't be a man with a passion if that were true . So let's not use debating terms there.

In your essay you argued in great detail that (quote) ‘jplay can’t & does not make things simpler’ based on how you see Windows working.
I replied addressing specific points where IMHO you had a fundamentally wrong idea of what happens ‘’under the hood’ in Windows and showed that jplay ‘_can_ & _does_ make things simpler’ and challenged you to disprove my assertions – that’s all.

You have bigger problem than that: your entire premise is in question. As I said, vast amount of the improvements you have made aim to make the system more real-time. You have to first prove that is of value. Once there, then we can examine whether you have indeed improved things. Right now, you are not even remotely close to making that case. I have repeatedly said that current media players do not glitch. You have not disputed that, nor has anyone else. Yet you somehow think that making the system more real-time somehow makes things better. Well, you need to articulate that.

It’s not about ‘convincing’: it’s about laying arguments for those specific points.

Got it. Here are the points:

1. No one needs a more real-time system. Music plays to the satisfaction of everyone who uses a media server.

2. Not one person has said here that they bought your player because it made the system more real-time, i.e. played audio without drop out.

3.Claim is made that you have made things simpler. But no data is shown that such simplicity, assuming if it is even there, results in the system behavior changing at the output of the DAC. By far the responsibility is yours to demonstrate that objectivity. Others who don't have this burden however, have performed tests that has shown no improvement. So at least in their situation, with the resolution of the tests they have run, no electrical changes were registered despite all the heroic things you have done to simplify things.

4. The only evidence you put forward for the efficacy of your software is your ears and that of unknown many. I know I can easily fool your ear and just as many people in countless tests so that doesn't amount to much evidence in my book especially when the improvements you have made had specific technical objectives that can readily be measured.

Here is where I net it out. I don't think you are aware of how severe effect of placebo is in this domain. I encourage you to have a loved one do a blind test on you of your player and Jriver over good number of runs. You don't have to tell us the results. But I suspect you will be more sober after that . I have done exactly these tests and know this first-hand. On the other hand, I think it is possible to improve the performance of some systems, some of the time if one had more knowledge of how they worked. Sadly for our audience here, I think those will be lower performing system.

 

[jplay]

ack - thank you for your observations.

I am afraid we might lose a majority of readers here with this ultra technical 'real time'/'real time enough' discussion but since you call on me I feel obliged to try and explain it in another way as i obviously was not clear in my post (which is my fault only) - so, put simply:
'real time' implies a guarantee.
If you read Amir's response he says himself Windows is not realtime - so there is no disagreement here at all.

The reason I am pushing Amir on this is not some fetishist semantical/engineering/pedantry If there are no guarantees, quite simply, you have to be prepared!
Which for audio means use larger buffers...
And that is the point of 'contention' as experimentally most people preferred minimal buffers sound-wise (in our humble experiment involving couple thousand people).
But using small buffers in non 'real-time' OS means you _exponentially_ increase the odds of glitches!
Because if e.g. Windows is 'good enough' for buffer of X samples it may not be for buffer of Y samples....
And that is when all this system optimization done by jplay becomes needed: simply to keep the ball rolling

>a general-purpose computer can be only as real time as what we call the CPU's quantum, which on Unix is 1ms (therefore, best to buy a Mac-based PC server or similar, rather than Windows) and on Windows is _approximately_ 15ms

Windows also works with 1ms 99% of time
If you don't believe me get this and check on your own system:
http://technet.microsoft.com/en-us/sysinternals/bb897568.aspx

But anyway, things are not that simple: 'quantum' you mention may not be a minimal unit of measurement - _several_ quantum's are usually a minimum but it gets more complex when you add interrupts etc: OS really has to be modified to be realtime - it is not a switch that just needs to be flipped and bingo - realtime: it's tricky and it has tradeoffs too...(do general consumers need real-time? no...)

Anyway - I just mention this as you seem to have made a recommendation for Mac vs Windows server just based on 'quantum': it ain't that simple so please look at other factors before making a decision as quantums are least important of all - that's all i can say....

>JPlay is not convincing me that it does anything new or groundbreaking that would be more beneficial than other techniques (like shutting down processes myself).

good to hear you feel shutting down other processes is beneficial
but no, there is no way you can shut down as many processes as jplay can (in Hibernate mode pretty much anything but very core OS is shut down) simply because even if you could kill all of those you would not able to revive the system
and would it make a difference or not in your system: nobody can say but you...:we say on site 'trust your own ears only' which means check out a free trial and decide for yourself....

 

[jkeny]

Can I just ask something about the use of the term "glitch" in relation to USB audio.

The assumption put forth is that if a data packet is not delivered to a USB DAC on time it will cause a drop-out or "glitch" in the sound.

Can I refer you to this site for an in-depth description of how USB works http://www.beyondlogic.org/usbnutshell/usb4.shtml
And this quote from it

Isochronous transfers occur continuously and periodically. They typically contain time sensitive information, such as an audio or video stream. If there were a delay or retry of data in an audio stream, then you would expect some erratic audio containing glitches. The beat may no longer be in sync. However if a packet or frame was dropped every now and again, it is less likely to be noticed by the listener.

Now isochronous USB protocols natively provide error detection via CRC, but no retry or guarantee of delivery.

It is however possible for asynch USB drivers to detect errors but this has to be coded into the driver. In Windows, sample rates of up to 96KHz are handled by Windows native USB drivers - I'm not sure how they handle this error detection (I don't know if Amir can help here?). Above 96KHz, proprietary USB drivers are required & the handling of errors would be dependent on this code. This is what I can find on Windows iscochronous USB transfers http://msdn.microsoft.com/en-us/library/windows/hardware/hh406225(v=vs.85).aspx

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.

BTW, the timing constraints for USB packet delivery are 1ms ± 500ns on a full speed bus or every 125 µs ± 0.0625 µs on a high speed bus. The high speed USB protocol is the commonly used USB protocol on most modern USB audio devices.

 

[amirm]

Can I just ask something about the use of the term "glitch" in relation to USB audio.

The assumption put forth is that if a data packet is not delivered to a USB DAC on time it will cause a drop-out or "glitch" in the sound.

Can I refer you to this site for an in-depth description of how USB works http://www.beyondlogic.org/usbnutshell/usb4.shtml
And this quote from it

Now isochronous USB protocols natively provide error detection via CRC, but no retry or guarantee of delivery.

It is however possible for asynch USB drivers to detect errors but this has to be coded into the driver. In Windows, sample rates of up to 96KHz are handled by Windows native USB drivers - I'm not sure how they handle this error detection (I don't know if Amir can help here?). Above 96KHz, proprietary USB drivers are required & the handling of errors would be dependent on this code. This is what I can find on Windows iscochronous USB transfers http://msdn.microsoft.com/en-us/library/windows/hardware/hh406225(v=vs.85).aspx

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.

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.

BTW, the timing constraints for USB packet delivery are 1ms ± 500ns on a full speed bus or every 125 µs ± 0.0625 µs on a high speed bus. The high speed USB protocol is the commonly used USB protocol on most modern USB audio devices.

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 .