JPLAY Responds: An Open Letter
- Thread starter mauidan
- Start date
Here is the main argument:
It is an interesting response by JPLAY. A few things stick out to me:
1. It is an argument by analogy. He is saying that since a CD has a standard for timing then computer audio must have a standard, too . . . and nothing else but JPLAY is meeting the standard.
2. I find it ironic that JPLAY doesn't even support CD playback.
3. Even if timing was ever an issue for CD playback, it certainly isn't for CD ripping otherwise everyone's rips would be different.
4. An asynchronous USB connection controls the timing of data received so anyone using asynchronous USB obviously doesn't need JPLAY since JPLAY "is all about: improving timing."
It is an interesting response by JPLAY. A few things stick out to me:
1. It is an argument by analogy. He is saying that since a CD has a standard for timing then computer audio must have a standard, too . . . and nothing else but JPLAY is meeting the standard.
2. I find it ironic that JPLAY doesn't even support CD playback.
3. Even if timing was ever an issue for CD playback, it certainly isn't for CD ripping otherwise everyone's rips would be different.
4. An asynchronous USB connection controls the timing of data received so anyone using asynchronous USB obviously doesn't need JPLAY since JPLAY "is all about: improving timing."
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.
"'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.
Amir, it seems the deck is stacked against JPay..With Jriver AND Foobar joining forces against it, as well as some pretty
well known computer audio gurus and personalities all publishing null findings..including a big article on computeraudiophile.com
But how do you account for the group that insists it improves Jriver, feverishly defending it?
Also Steve Plaskin on Audiostream definitively said it improved Jriver.
http://www.audiostream.com/content/road-jplay
I'm stumped!
P.S., I also thought their response and explanation of what the program does was lightweight at best, but
to be fair there could be a language issue as well.
To Amirm
Amen!
We, audiophiles, have been known to hear differences or improvement that cannot sustain any serious analysis. Sme people still go for the dots and stones and magic pebbles ... Shakti stone is till running a brisk business so ... Are thebharmonix Lombards and various quantum audiophile products...remember the green felt for CDs?
"We, audiophiles, have been known to hear differences or improvement that cannot sustain any serious analysis. Sme people still go for the dots and stones and magic pebbles ... Shakti stone is till running a brisk business so ... Are thebharmonix Lombards and various quantum audiophile products...remember the green felt for CDs?"
Yes, I agree with you. But 6Moons, Audiostream, and several other review sites ALL said they loved it. I don't understand. There is no doubt that
some audiophiles, and MANY reviewers exaggerate the differences they hear with certain variables.
BTW, the Shakti Stone really works. Do you know their products are used in high end auto racing? It supposedly allows the instrumentation
and various critical systems to work better with less RFI/EMI interference.
Yes, I agree with you. But 6Moons, Audiostream, and several other review sites ALL said they loved it. I don't understand. There is no doubt that
some audiophiles, and MANY reviewers exaggerate the differences they hear with certain variables.
BTW, the Shakti Stone really works. Do you know their products are used in high end auto racing? It supposedly allows the instrumentation
and various critical systems to work better with less RFI/EMI interference.
Think about this...would some of the top racers in the world screw around with voodoo, and put their lives in danger? I think not.
Also let me clarify my position, or lack there of on Jplay.
I am ALSO a skeptic. As I said above, their response was limp to me. I just don't have any interest in a $150 plug in for a $50 program.
I am wondering why they just don't create their own nuts and bolts program, instead of plugging into Jriver.
I am quite taken aback at the the battle that has been waged. So many say Jplay does absolutely nothing and then
there are others who swear by it. Dumbfounding!
When I close processes I hear a difference, when I turn off the screen, I hear differences x100. I believe there may be subtle improvements with process shutdowns but I believe more in LCD power consumption/LCD vibration issues. Try shutting your screen down or your amp's LCD and then post your results.
Peter, in a blind test, with someone sitting by your computer out of view, could you reliably tell
when that person shuts down processes? Could on repeatedly identify when the display was on or off?
Bruce B
WBF Founding Member, Pro Audio Production Member
Last year I was reviewing a couple of DAC's and tried JRiver with and without JPlay... I couldn't tell a difference.
The DAC's I tried it on were the PB MPS-5, MSB and the one from JKenny.
The DAC's I tried it on were the PB MPS-5, MSB and the one from JKenny.
Hey Bruce:
I am getting in a couple of USB DACs and I guess I will try Jplay for the hell of it.
What is amazing is that droves of experienced listeners like your self have heard nothing
while some have..Steve Plaskin at Audiostream went bonkers over it. A real mystery
as to how this software has created such a split.
"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
I wonder how this piece of software is able to mount special ultra low-latency RAM in my laptop
Jplay did make a positive difference in my system - for whatever reason. My personal understanding is that it makes the computer perform better by closing certain processes that are not necessery for audio playback (similar to what Fidelizer software does), which results in lower RFI/EMI radiation.
Jplay response puzzles me though.
Jplay response puzzles me though.
Hello Amir and thank you for your post.
>No one is saying that simpler is not better.
You would be surprised how many people will fervently fight this notion for reasons we noted in our letter.
Glad we agree though that old audio adage ‘simpler is better’ _does_ apply to computer audio as well.
> While it is the position of Jriver that bit-perfect equals perfection, it is not mine. I acknowledge that timing is involved.
Good we agree on this too. Again - many wouldn’t for mysterious reasons.
Seems we have enough common ground here that hopefully we can make this a useful discussion and not a silly ****-match of ‘hoax’ accusations or claims that ‘bit-perfect equals perfection’ as you have eloquently put it – good!
> We are saying that they can't and aren't making things simpler.
We at jplay have exactly diametrically opposing view:
Yes, we DO make things simpler because, yes, we think we just _can_!
You’ve summed up the crux of our debate brilliantly simply with easy to understand two diametrically opposing views – Excellent!
You have also described reasoning behind your view in great detail without resorting to calling names or ad-hominem attacks which is rare these days and highly commendable (oh, you have not exactly been kind to us but that’s ok – we may not be kind in what we have to say below but hope you can see it’s nothing personal just a battle of opinions)
In addition, I understand that you not only have Microsoft background but have first-hand experience with Windows Audio as a key figure in development of Windows Media Player?
This again lifts you way above average ‘nickname’ poster and provides a higher level of credibility. You seem to know what you’re talking about and you have good credentials.
And it is this which worries me a great, great deal and why I am writing this.
It is one thing being called a ‘hoax’ by someone whose only credential is ‘I am CEO!’ (as if that somehow automatically makes everything he says ok???) and quite another being challenged on specific & technical level by someone with your background.
But what worries me here is precisely because of your excellent background you should know better – much better, in fact, than how you described Windows working ‘under the hood’.
What you described is a correct but naïve theoretical model which differs significantly from how Windows works in practice and, no offense, it exposes serious gaps in your knowledge which, with your permission, we hope to elucidate. After all, if you have misunderstandings of how things work is it any wonder so many people get confused?
In the interest of brevity, please allow me to skip most of what you wrote and put focus on things we believe you are simply wrong about but which do reflect the essence of your view pretty accurately.
> 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.
Yes, that is exactly the problem we are confronted with!
But wait - while it is an indisputable fact it’s OS & OS _only_ who decides ‘what happens next’, does it mean that we are totally powerless?
Does this mean we have absolutely no influence whatsoever?
I seriously hope that’s not what you wanted to say as it’d be absurd.
Yes – we cannot _force_ OS to do exactly what we want at exact time we want it done.
But we _can_ increase the odds.
How?
For starters, by simultaneously reducing priorities of non-audio tasks and maxing out priorities of audio-sensitive tasks.
Does this ‘guarantee’ OS will always ‘focus’ on audio-sensitive tasks first?
Not at all!
Consumer OS like Windows (or MacOS, or ‘non real-time’ Linux for that matter) gives NO guarantees whatsoever when it comes to timing – it’s simply designed for something else, it CANNOT give such a guarantee.
But it _does_ guarantee making a ‘best effort’ to honour priorities we set!
Point being: We cannot _control_ timing in OS (due to its design) but we can _influence_ it to a great deal indeed!
And why do we need to influence timing?
> 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.
Uh no: Adding ‘a buffer’ does not a real-time OS make just as ‘one swallow does not a spring make’…
It takes quite some effort to make a real-time OS but I’m sure you know that - let’s focus on this as you are hitting a key point:
What you are describing here is really just ‘a workaround’, said politely, or ‘a kludge’ said in a less politically-correct way, but one we simply have to live with when using consumer OS for audio playback.
A ‘kludge’ that cannot be fixed ever but kludge that we at jplay are simply (but obsessively) trying to perfect. Surprisingly, it turns out that size of this buffer which is a sort of a necessary evil, has an impact on sound as in, smaller buffers sounding better! We don’t know why (at least we can measure buffer size lol) but we can theorize that smaller is simply better as less data has to be moved around which means more of it (ideally all) can stay closer to CPU simplifying the process by minimizing ‘fetch data from ram bank’ steps.
The problem is, smaller buffer means greatly increased chances of glitches/pops especially in a ‘busy’ system so making things ‘simpler’ becomes not only a theoretically nice idea but a practically mandated requirement as otherwise things simply don’t work!
And yes jplay allows smallest buffers to be used of any player on the market: whereas most players advise users to increase buffers we advise ours to decrease them And we get pretty much unanimous feedback that with larger buffers differences between players tend to decrease (it would seem that buffers do not come ‘for free’ in reality which is again opposed to theory.)
> When (sound hardware) 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.
No Amir – That’s idealized vision which has nothing to do with real life.
Oh yes, things used to work like this in Stone Age (you look youthful but something tells me you do remember MS-DOS?) however this is most decidedly NOT what happens with Windows.
And pardon me for singling you out, but you of all should know this better than anyone else as, while what you describe is possible, Microsoft itself instructs driver developers NEVER EVER TO DO IT THIS WAY!
You should know what actually happens with ‘an interrupt’ is almost nothing at all! Sound driver will only make ‘should fill sound hardware buffer ASAP’ message and stuff it in an OS queue – that’s all….
Sound hardware buffer is NOT filled and all applications continue their execution as if nothing had happened. Including our music player blissfully unaware that sound hardware screams “I need data ASAP’!
Then, at some _later_ point in time, which while not far away is still variable, Windows will pick up this ‘fill sound hardware buffer ASAP’ message and execute task in charge (message is actually a procedure but like you I am trying hard not to lose majority of readers not interested in nitty-gritty technicalities).
ONLY now will e.g. USB buffer for USB-connected DAC get filled.
Point being what we have is a Windows-imposed _delay_ whose length of time is variable and totally out of our direct control.
Worse – this delay will depend on _other_ activities in the system that have nothing to do with audio whatsoever!
For example, network packet received, disk reading data, graphical card doing its stuff… ALL will generate their own ‘interrupt’ and OS _must_ handle all those tasks too, _on top_ of ensuring all applications and other tasks run ‘smoothly’ as well (which easily number 200-500 in total on a typical PC…I have 695 running while writing this, for example)
Obviously, we cannot control the exact length of this delay as it depends on far too many variables also out of our control – yet, we can influence it – How?
Simple: By reducing amount of variables!
OS is one of most (if not THE most) complex pieces of software ever made. I know you know this but please allow me an analogy for general reader:
In many ways OS is like a top acrobat juggler: mostly it has only 2 or 4 hands (CPU cores) yet it has to juggle 200-500 beanbags (tasks) together with any number of rings (interrupts).
Isn’t it obvious even super-juggler will start dropping rings as their number is increased?
And will he juggle with more ‘ease’ i.e. in a more predictable pattern with smaller number of beanbags?
Is this concept really so hard to grasp?
Not saying for you – I’m sure you ‘get it’ although you worry me very, very much with your following statement:
>I don't know what timer they think they have changed….Maybe they have mucked with the operating system time.
Bingo! And no, we never said it has anything to do with e.g. external clock in USB DAC – that is obviously impossible so it would be absurd to claim anything of the sort…
But as you inquire, why? Why would we ‘muck’ (as you put it) with system timer?
Well, looking at our acrobat-juggler it is easy to notice that less beanbags he needs to juggle the longer each individual beanbag rests in his hand. And the more beanbags, the less time each beanbag spends in his hands.
But OS is not like that: If you allow the analogy, OS always has ‘fixed time’ that a beanbag can spend in the hand: the shorter this time, the quicker a beanbag gets ‘thrown in the air’ or, looking at it from another perspective: the _sooner_ the beanbag we may particularly be fond of (‘audio beanbag’) gets ‘handled’.
Again – we can’t ever force OS to guarantee that ‘perfect timing’ we would like to have for our audio beanbag - but if we remove hundreds of beanbags we don’t give a damn about (enter JPLAY’s Hibernate mode) AND we make juggler ‘juggle faster’ (by increasing system timer), like pressing ‘fast forward’ while watching juggler video, we, in effect, again improve chances of our audio beanbag being handled closer to ‘right’ time and, more importantly, _decrease variability_ of Windows-imposed ‘delay’ mentioned above!
>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.
No offense but that 15ms you mention pretty much does not exist in real life. Yes I know it worked like that in very early Vista days – doesn’t any more….
For starters, are you aware USB2 standard (used by 100% USB DACs on the market) stipulates exactly this 1ms frequency which you seem to loathe because of jitter? Isn’t that scary?
And would it come to you as a surprise that even just opening a browser (IE, Chrome) or having any audio-activity including ‘your’ Windows Media Player will also routinely change system clock to 1ms?
Would it come to you as a surprise that Microsoft’s own Multimedia service (which is ‘on’ by default on all consumer versions of Vista, Win7 or Win8) would also switch to 1ms when audio streaming is detected by Windows? In effect, chances are 1ms is active all the time as the setting is global and cannot be changed upwards as long as any app has asked for higher precision system timer.
Based on your comments it would seem you were not aware of this, so would it also come to you as a surprise that Microsoft’s own Multimedia service will routinely _increase priority_ of audio-related tasks and actively look to _decrease_ number of interrupts during audio streaming?
But why would Microsoft itself bother doing this if, as you have previously suggested, nobody has any control over what OS ultimately decides to ‘do next’? (Please note MS Multimedia service is NOT part of core Windows OS and, in a manner of speaking, is in ‘the same league’ as JPLAY Audio Service!)
I gather you worked at Microsoft during development of ill-fated Vista: I would be very surprised if you don’t remember a well-publicized bug in Vista as it was directly related to Windows Audio and was easily triggered with ‘your own’ Windows Media Player: the very moment audio playback was started people noticed that faster the network card, more drastically the network speed was reduced! For example: 1Gbit card speed fell to 15% of capacity just because Windows Media Player was playing a tune!!!
And Why? Because Microsoft’s own Media service worked very hard (too hard in fact - that was the bug) at _reducing_ network activity i.e. interrupts!
But why would MS ever want to reduce network activity?
Because it was discovered during internal Vista-testing that ‘too many’ network interrupts during audio playback were causing glitches/pops!
Let me close debate about can we influence Windows by bringing in only one ‘witness’ and your former colleague: a single person at Microsoft who both knows how Windows _really_ works AND is allowed to talk about it publicly: Mark Russinovich a ‘Microsoft Technical Fellow’ and I hope your pal. If you never did so before, please do read his brilliant description of inner workings of Windows (and Audio in particular) where this legendary Vista Audio bug is dissected in fascinating detail:
http://blogs.technet.com/b/markrussinovich/archive/2007/08/27/1833290.aspx
If you allow me I’ll add some quotes from this article: (emphasis mine)
>The (Multimedia) service…_prioritizes_ the playback of video and audio in order to prevent other tasks from interfering with the CPU usage of the playback software.
…
When a multimedia application begins playback, the multimedia APIs (..will..) boost the priority of the playback thread….(so that) … applications won’t interfere with the playback.
Note that simply throwing buffers at the problem would apparently not have helped and a lot of complicated measures where needed just to ensure glitch-free playback.
So if this piece of software can influence what OS is doing why couldn’t any other? And why can’t we do a simpler job as opposed to this massive invasive action?
But let’s conclude this post with some more info that causes confusion (not only to you):
> 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.
No Amir – ‘All’ players don’t do this, you’re simply on a wrong track here.
In fact, only two players utilize this special RAM: JPLAY & XXHighEnd (and we told them how to do it but we’re fond of them so it’s ok ? )
And no, it’s not ‘high-speed memory’ (frankly, have no idea what you mean by that?) – we clearly said it’s ‘low latency’: that is quite something else….
But ok, no wonder you’re not aware of what we are talking about (although it’s mentioned on our web page): Not many people are and neither was JRiver programmer who said (paraphrased) ‘we’re full of BS ‘cause all RAM is same’. He even wrote a program to ‘prove’ it. And then we slightly modified his program to more accurately mimic audio-playback access patterns and lo & behold, it run 10x faster compared to ‘normal’ RAM….. JRiver’s been super-hostile towards us ever since but that’s old news and not very important…
Forgive me for not putting a link but this discussion is available on computer audiophile if you are interested (software technique used is a genuinely interesting topic and, if I may, I would advise you to learn about it as it painfully exposes what most software engineers take for granted is, in fact, a non-trivial issue showcasing more of OS-induced overhead and ‘hidden’ latency) but in the end this is not really that important either - it just shows another angle where we simplify things for CPU and cut out some hidden latencies.
So with all due respect, let me try to debunk your statement that ‘jplay cannot and doesn’t make things simpler’:
If jplay reduces amount of tasks OS has to take care of and reduces the amount of work needed to perform audio playback task (down to tiny details like optimizing RAM access) and makes this process more predictable – doesn’t that constitute simplification?
Put less technically:
If jplay-juggler juggles 50 beanbags AND moves beanbags twice as fast compared to jriver-juggler who is saddled with juggling 250-500 beanbags - which one has a ‘simpler’ job considering both have same (e.g. 4) number of hands?
Which juggler holds ‘audio beanbag’ in hand more often?
For which juggler is it simpler to predict and with higher accuracy when ‘audio-beanbag’ will be handled?
Anyway, that was our point and hopefully explained simply and not to aggressively…
Yes, yes – I know what you will say now…
You will say something like, ok, well, let’s ‘suppose’ you’re right with jplay juggler having less beanbags and all that jazz….
Let’s ‘suppose’ jplay _can_ affect things and _does_ make them simpler…
But it does not matter at all because jplay/jriver-jugglers are irrelevant! Only DAC-juggler matters and he ain’t got no beanbags to juggle apart from audio-beanbag so all you wrote above is worth squat!
And this is where we inevitably get into really contentious statements like ‘properly designed DAC’, ‘asynchronous USB’, ‘data re-clocking’, ‘jitter rejection’ etc etc….
Now these are really interesting questions: Things I described above to me are simple & logical, maybe because I’m just a software guy. But this is where it gets really hard to understand what is going on: Why would anything that happens in PC have an effect on an async USB DAC which reclocks incoming data anyway? This makes no sense theoretically and we can offer no explanation of our own: when we initially developed jplay pretty much all DACs were still synchronous so theory was easy: better clocking (as in more predictable) in PC leading to better input for DAC – but nowadays most are async yet we keep hearing from more and more people that it still matters and we hear the same and it’s very frustrating as nobody has come with any explanations much less measurements….
Would we ever bother with this if all questions had easily measurable answers? Never! Then we could just buy best-measured equipment and get back to listening to music which this whole damn hobby is supposed to be about…
But after all these years we still have to get whatever piece of audio equipment we consider buying into our homes and just listen… Because no measurement exists showing how music coming out from all that software/hardware really makes us _feel_...it simply does not exist…
Not that we are dismissive of measurements – just sceptical: we’ll sure be checking that work you mentioned when you provide a link.
But that compels me to repeat something a wise man told me some time ago:
When speaking about high-end audio we always need to keep one thing in mind: there is NOTHING like it except, perhaps, fine wine: not everybody can appreciate it (many simply aren’t capable – period), not everybody _cares_ about appreciating it and many, in fact, would choose beer over wine and, frankly, few have or are in position to taste the finest Bordeaux and even fewer are willing to pay through the nose for what most would describe are just undiscernible differences….
And, oh, no measurements either….
>No one is saying that simpler is not better.
You would be surprised how many people will fervently fight this notion for reasons we noted in our letter.
Glad we agree though that old audio adage ‘simpler is better’ _does_ apply to computer audio as well.
> While it is the position of Jriver that bit-perfect equals perfection, it is not mine. I acknowledge that timing is involved.
Good we agree on this too. Again - many wouldn’t for mysterious reasons.
Seems we have enough common ground here that hopefully we can make this a useful discussion and not a silly ****-match of ‘hoax’ accusations or claims that ‘bit-perfect equals perfection’ as you have eloquently put it – good!
> We are saying that they can't and aren't making things simpler.
We at jplay have exactly diametrically opposing view:
Yes, we DO make things simpler because, yes, we think we just _can_!
You’ve summed up the crux of our debate brilliantly simply with easy to understand two diametrically opposing views – Excellent!
You have also described reasoning behind your view in great detail without resorting to calling names or ad-hominem attacks which is rare these days and highly commendable (oh, you have not exactly been kind to us but that’s ok – we may not be kind in what we have to say below but hope you can see it’s nothing personal just a battle of opinions)
In addition, I understand that you not only have Microsoft background but have first-hand experience with Windows Audio as a key figure in development of Windows Media Player?
This again lifts you way above average ‘nickname’ poster and provides a higher level of credibility. You seem to know what you’re talking about and you have good credentials.
And it is this which worries me a great, great deal and why I am writing this.
It is one thing being called a ‘hoax’ by someone whose only credential is ‘I am CEO!’ (as if that somehow automatically makes everything he says ok???) and quite another being challenged on specific & technical level by someone with your background.
But what worries me here is precisely because of your excellent background you should know better – much better, in fact, than how you described Windows working ‘under the hood’.
What you described is a correct but naïve theoretical model which differs significantly from how Windows works in practice and, no offense, it exposes serious gaps in your knowledge which, with your permission, we hope to elucidate. After all, if you have misunderstandings of how things work is it any wonder so many people get confused?
In the interest of brevity, please allow me to skip most of what you wrote and put focus on things we believe you are simply wrong about but which do reflect the essence of your view pretty accurately.
> 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.
Yes, that is exactly the problem we are confronted with!
But wait - while it is an indisputable fact it’s OS & OS _only_ who decides ‘what happens next’, does it mean that we are totally powerless?
Does this mean we have absolutely no influence whatsoever?
I seriously hope that’s not what you wanted to say as it’d be absurd.
Yes – we cannot _force_ OS to do exactly what we want at exact time we want it done.
But we _can_ increase the odds.
How?
For starters, by simultaneously reducing priorities of non-audio tasks and maxing out priorities of audio-sensitive tasks.
Does this ‘guarantee’ OS will always ‘focus’ on audio-sensitive tasks first?
Not at all!
Consumer OS like Windows (or MacOS, or ‘non real-time’ Linux for that matter) gives NO guarantees whatsoever when it comes to timing – it’s simply designed for something else, it CANNOT give such a guarantee.
But it _does_ guarantee making a ‘best effort’ to honour priorities we set!
Point being: We cannot _control_ timing in OS (due to its design) but we can _influence_ it to a great deal indeed!
And why do we need to influence timing?
> 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.
Uh no: Adding ‘a buffer’ does not a real-time OS make just as ‘one swallow does not a spring make’…
It takes quite some effort to make a real-time OS but I’m sure you know that - let’s focus on this as you are hitting a key point:
What you are describing here is really just ‘a workaround’, said politely, or ‘a kludge’ said in a less politically-correct way, but one we simply have to live with when using consumer OS for audio playback.
A ‘kludge’ that cannot be fixed ever but kludge that we at jplay are simply (but obsessively) trying to perfect. Surprisingly, it turns out that size of this buffer which is a sort of a necessary evil, has an impact on sound as in, smaller buffers sounding better! We don’t know why (at least we can measure buffer size lol) but we can theorize that smaller is simply better as less data has to be moved around which means more of it (ideally all) can stay closer to CPU simplifying the process by minimizing ‘fetch data from ram bank’ steps.
The problem is, smaller buffer means greatly increased chances of glitches/pops especially in a ‘busy’ system so making things ‘simpler’ becomes not only a theoretically nice idea but a practically mandated requirement as otherwise things simply don’t work!
And yes jplay allows smallest buffers to be used of any player on the market: whereas most players advise users to increase buffers we advise ours to decrease them
And we get pretty much unanimous feedback that with larger buffers differences between players tend to decrease (it would seem that buffers do not come ‘for free’ in reality which is again opposed to theory.)> When (sound hardware) 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.
No Amir – That’s idealized vision which has nothing to do with real life.
Oh yes, things used to work like this in Stone Age (you look youthful but something tells me you do remember MS-DOS?) however this is most decidedly NOT what happens with Windows.
And pardon me for singling you out, but you of all should know this better than anyone else as, while what you describe is possible, Microsoft itself instructs driver developers NEVER EVER TO DO IT THIS WAY!
You should know what actually happens with ‘an interrupt’ is almost nothing at all! Sound driver will only make ‘should fill sound hardware buffer ASAP’ message and stuff it in an OS queue – that’s all….
Sound hardware buffer is NOT filled and all applications continue their execution as if nothing had happened. Including our music player blissfully unaware that sound hardware screams “I need data ASAP’!
Then, at some _later_ point in time, which while not far away is still variable, Windows will pick up this ‘fill sound hardware buffer ASAP’ message and execute task in charge (message is actually a procedure but like you I am trying hard not to lose majority of readers not interested in nitty-gritty technicalities).
ONLY now will e.g. USB buffer for USB-connected DAC get filled.
Point being what we have is a Windows-imposed _delay_ whose length of time is variable and totally out of our direct control.
Worse – this delay will depend on _other_ activities in the system that have nothing to do with audio whatsoever!
For example, network packet received, disk reading data, graphical card doing its stuff… ALL will generate their own ‘interrupt’ and OS _must_ handle all those tasks too, _on top_ of ensuring all applications and other tasks run ‘smoothly’ as well (which easily number 200-500 in total on a typical PC…I have 695 running while writing this, for example)
Obviously, we cannot control the exact length of this delay as it depends on far too many variables also out of our control – yet, we can influence it – How?
Simple: By reducing amount of variables!
OS is one of most (if not THE most) complex pieces of software ever made. I know you know this but please allow me an analogy for general reader:
In many ways OS is like a top acrobat juggler: mostly it has only 2 or 4 hands (CPU cores) yet it has to juggle 200-500 beanbags (tasks) together with any number of rings (interrupts).
Isn’t it obvious even super-juggler will start dropping rings as their number is increased?
And will he juggle with more ‘ease’ i.e. in a more predictable pattern with smaller number of beanbags?
Is this concept really so hard to grasp?
Not saying for you – I’m sure you ‘get it’ although you worry me very, very much with your following statement:
>I don't know what timer they think they have changed….Maybe they have mucked with the operating system time.
Bingo! And no, we never said it has anything to do with e.g. external clock in USB DAC – that is obviously impossible so it would be absurd to claim anything of the sort…
But as you inquire, why? Why would we ‘muck’ (as you put it) with system timer?
Well, looking at our acrobat-juggler it is easy to notice that less beanbags he needs to juggle the longer each individual beanbag rests in his hand. And the more beanbags, the less time each beanbag spends in his hands.
But OS is not like that: If you allow the analogy, OS always has ‘fixed time’ that a beanbag can spend in the hand: the shorter this time, the quicker a beanbag gets ‘thrown in the air’ or, looking at it from another perspective: the _sooner_ the beanbag we may particularly be fond of (‘audio beanbag’) gets ‘handled’.
Again – we can’t ever force OS to guarantee that ‘perfect timing’ we would like to have for our audio beanbag - but if we remove hundreds of beanbags we don’t give a damn about (enter JPLAY’s Hibernate mode) AND we make juggler ‘juggle faster’ (by increasing system timer), like pressing ‘fast forward’ while watching juggler video, we, in effect, again improve chances of our audio beanbag being handled closer to ‘right’ time and, more importantly, _decrease variability_ of Windows-imposed ‘delay’ mentioned above!
>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.
No offense but that 15ms you mention pretty much does not exist in real life. Yes I know it worked like that in very early Vista days – doesn’t any more….
For starters, are you aware USB2 standard (used by 100% USB DACs on the market) stipulates exactly this 1ms frequency which you seem to loathe because of jitter? Isn’t that scary?
And would it come to you as a surprise that even just opening a browser (IE, Chrome) or having any audio-activity including ‘your’ Windows Media Player will also routinely change system clock to 1ms?
Would it come to you as a surprise that Microsoft’s own Multimedia service (which is ‘on’ by default on all consumer versions of Vista, Win7 or Win8) would also switch to 1ms when audio streaming is detected by Windows? In effect, chances are 1ms is active all the time as the setting is global and cannot be changed upwards as long as any app has asked for higher precision system timer.
Based on your comments it would seem you were not aware of this, so would it also come to you as a surprise that Microsoft’s own Multimedia service will routinely _increase priority_ of audio-related tasks and actively look to _decrease_ number of interrupts during audio streaming?
But why would Microsoft itself bother doing this if, as you have previously suggested, nobody has any control over what OS ultimately decides to ‘do next’? (Please note MS Multimedia service is NOT part of core Windows OS and, in a manner of speaking, is in ‘the same league’ as JPLAY Audio Service!)
I gather you worked at Microsoft during development of ill-fated Vista: I would be very surprised if you don’t remember a well-publicized bug in Vista as it was directly related to Windows Audio and was easily triggered with ‘your own’ Windows Media Player: the very moment audio playback was started people noticed that faster the network card, more drastically the network speed was reduced! For example: 1Gbit card speed fell to 15% of capacity just because Windows Media Player was playing a tune!!!
And Why? Because Microsoft’s own Media service worked very hard (too hard in fact - that was the bug) at _reducing_ network activity i.e. interrupts!
But why would MS ever want to reduce network activity?
Because it was discovered during internal Vista-testing that ‘too many’ network interrupts during audio playback were causing glitches/pops!
Let me close debate about can we influence Windows by bringing in only one ‘witness’ and your former colleague: a single person at Microsoft who both knows how Windows _really_ works AND is allowed to talk about it publicly: Mark Russinovich a ‘Microsoft Technical Fellow’ and I hope your pal. If you never did so before, please do read his brilliant description of inner workings of Windows (and Audio in particular) where this legendary Vista Audio bug is dissected in fascinating detail:
http://blogs.technet.com/b/markrussinovich/archive/2007/08/27/1833290.aspx
If you allow me I’ll add some quotes from this article: (emphasis mine)
>The (Multimedia) service…_prioritizes_ the playback of video and audio in order to prevent other tasks from interfering with the CPU usage of the playback software.
…
When a multimedia application begins playback, the multimedia APIs (..will..) boost the priority of the playback thread….(so that) … applications won’t interfere with the playback.
Note that simply throwing buffers at the problem would apparently not have helped and a lot of complicated measures where needed just to ensure glitch-free playback.
So if this piece of software can influence what OS is doing why couldn’t any other? And why can’t we do a simpler job as opposed to this massive invasive action?
But let’s conclude this post with some more info that causes confusion (not only to you):
> 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.
No Amir – ‘All’ players don’t do this, you’re simply on a wrong track here.
In fact, only two players utilize this special RAM: JPLAY & XXHighEnd (and we told them how to do it but we’re fond of them so it’s ok ? )
And no, it’s not ‘high-speed memory’ (frankly, have no idea what you mean by that?) – we clearly said it’s ‘low latency’: that is quite something else….
But ok, no wonder you’re not aware of what we are talking about (although it’s mentioned on our web page): Not many people are and neither was JRiver programmer who said (paraphrased) ‘we’re full of BS ‘cause all RAM is same’. He even wrote a program to ‘prove’ it. And then we slightly modified his program to more accurately mimic audio-playback access patterns and lo & behold, it run 10x faster compared to ‘normal’ RAM….. JRiver’s been super-hostile towards us ever since but that’s old news and not very important…
Forgive me for not putting a link but this discussion is available on computer audiophile if you are interested (software technique used is a genuinely interesting topic and, if I may, I would advise you to learn about it as it painfully exposes what most software engineers take for granted is, in fact, a non-trivial issue showcasing more of OS-induced overhead and ‘hidden’ latency) but in the end this is not really that important either - it just shows another angle where we simplify things for CPU and cut out some hidden latencies.
So with all due respect, let me try to debunk your statement that ‘jplay cannot and doesn’t make things simpler’:
If jplay reduces amount of tasks OS has to take care of and reduces the amount of work needed to perform audio playback task (down to tiny details like optimizing RAM access) and makes this process more predictable – doesn’t that constitute simplification?
Put less technically:
If jplay-juggler juggles 50 beanbags AND moves beanbags twice as fast compared to jriver-juggler who is saddled with juggling 250-500 beanbags - which one has a ‘simpler’ job considering both have same (e.g. 4) number of hands?
Which juggler holds ‘audio beanbag’ in hand more often?
For which juggler is it simpler to predict and with higher accuracy when ‘audio-beanbag’ will be handled?
Anyway, that was our point and hopefully explained simply and not to aggressively…
Yes, yes – I know what you will say now…
You will say something like, ok, well, let’s ‘suppose’ you’re right with jplay juggler having less beanbags and all that jazz….
Let’s ‘suppose’ jplay _can_ affect things and _does_ make them simpler…
But it does not matter at all because jplay/jriver-jugglers are irrelevant! Only DAC-juggler matters and he ain’t got no beanbags to juggle apart from audio-beanbag so all you wrote above is worth squat!
And this is where we inevitably get into really contentious statements like ‘properly designed DAC’, ‘asynchronous USB’, ‘data re-clocking’, ‘jitter rejection’ etc etc….
Now these are really interesting questions: Things I described above to me are simple & logical, maybe because I’m just a software guy. But this is where it gets really hard to understand what is going on: Why would anything that happens in PC have an effect on an async USB DAC which reclocks incoming data anyway? This makes no sense theoretically and we can offer no explanation of our own: when we initially developed jplay pretty much all DACs were still synchronous so theory was easy: better clocking (as in more predictable) in PC leading to better input for DAC – but nowadays most are async yet we keep hearing from more and more people that it still matters and we hear the same and it’s very frustrating as nobody has come with any explanations much less measurements….
Would we ever bother with this if all questions had easily measurable answers? Never! Then we could just buy best-measured equipment and get back to listening to music which this whole damn hobby is supposed to be about…
But after all these years we still have to get whatever piece of audio equipment we consider buying into our homes and just listen… Because no measurement exists showing how music coming out from all that software/hardware really makes us _feel_...it simply does not exist…
Not that we are dismissive of measurements – just sceptical: we’ll sure be checking that work you mentioned when you provide a link.
But that compels me to repeat something a wise man told me some time ago:
When speaking about high-end audio we always need to keep one thing in mind: there is NOTHING like it except, perhaps, fine wine: not everybody can appreciate it (many simply aren’t capable – period), not everybody _cares_ about appreciating it and many, in fact, would choose beer over wine and, frankly, few have or are in position to taste the finest Bordeaux and even fewer are willing to pay through the nose for what most would describe are just undiscernible differences….
And, oh, no measurements either….
Brilliant exposition of exactly the same "points of contention" I had with Amir previously when he wrote:
Just one question: When you are talking about low-latency RAM you are talking about the CPU's cache RAM, right - the one right on the CPU die itself?
My reply which you have fleshed out in great detail:
Of course I know about muti-tasking OSes but you over-simplify. As you know muti-tasking is about splitting the CPU time across the currently "active" tasks according to controller algorithms or scheduler. How this is done & whether tasks are privileged so that they can't be interrupted can significantly affect their performance. Pre-emptive muti-tasking OSes can interrupt non-privileged tasks without their co-operation for resumption of that task at a later time. So if you are telling me that timing of time-sensitive processes, such as audio playback, can't be brought under better control by app developers that know deep level OS processes, that can privilege the pipeline then I have to disagree with you. Could a better timed/controlled pipeline for audio signal delivery to the devices be beneficial to the sound - I expect the answer is yes.
Just one question: When you are talking about low-latency RAM you are talking about the CPU's cache RAM, right - the one right on the CPU die itself?
Thanks for joining our forum Jplay and warm welcome despite the contentious aspect of the interchange that brought us together. Let me state that from this moment on, I am posting as an ordinary member and not an admin.
I read through your explanation or I should say I tried. Lack of proper paragraph spacing makes it hard to keep up with with what you are saying. It is late and I am tried from working on my boat electronics install all day (aggravating day with a part a vendor did not ship that was supposed to ). I will make some brief comments which I may add more to when I am in better mood and can think better :
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." All play without glitches and pauses to user's satisfaction. Can you get a glitch if the system is multi-use and stressed? Sure. 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 one I know that buys your software has expressed that they bought it because Jriver glitched and yours didn't. So much of what you say here and in your letter is off-topic.
2. You say you are software guy. That is a problem. Fidelity is a systems problem. And requires deep knowledge of psychoacoustics and how DACs, clock recovery, etc. work. I live and breath the full spectrum and it is in that context that I find issues with your approach. If I just put my software hat on, then everything you have done is an improvement. If I put my system hat on, I have to tell you that you may have wasted your time tweaking the playback pipeline.
3. I was clear that if PC is in charge of system timing as in motherboard PC sound, what you do may result in improvements in lower noise/Jitter. You should measure and document that as at least one reference point, i.e. the easiest test case, where your software makes a difference. All you need is a second PC to measure that as the other bloggers have done. They provide the complete cookbook which you could follow in probably similar time it took to write that letter.
4. I did not say this but let me say it now: it does take excellent knowledge of the OS and audio pipeline to do what you are doing. That is more reflected in your reply here. 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.
Again, welcome to the forum and sorry that it is in this type of circumstance.
I read through your explanation or I should say I tried. Lack of proper paragraph spacing makes it hard to keep up with with what you are saying. It is late and I am tried from working on my boat electronics install all day (aggravating day with a part a vendor did not ship that was supposed to
). I will make some brief comments which I may add more to when I am in better mood and can think better :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." All play without glitches and pauses to user's satisfaction. Can you get a glitch if the system is multi-use and stressed? Sure. 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 one I know that buys your software has expressed that they bought it because Jriver glitched and yours didn't. So much of what you say here and in your letter is off-topic.
2. You say you are software guy. That is a problem. Fidelity is a systems problem. And requires deep knowledge of psychoacoustics and how DACs, clock recovery, etc. work. I live and breath the full spectrum and it is in that context that I find issues with your approach. If I just put my software hat on, then everything you have done is an improvement. If I put my system hat on, I have to tell you that you may have wasted your time tweaking the playback pipeline.
3. I was clear that if PC is in charge of system timing as in motherboard PC sound, what you do may result in improvements in lower noise/Jitter. You should measure and document that as at least one reference point, i.e. the easiest test case, where your software makes a difference. All you need is a second PC to measure that as the other bloggers have done. They provide the complete cookbook which you could follow in probably similar time it took to write that letter.
4. I did not say this but let me say it now: it does take excellent knowledge of the OS and audio pipeline to do what you are doing. That is more reflected in your reply here. 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.
Again, welcome to the forum and sorry that it is in this type of circumstance.
Nothing is beneficiary to sound unless you can show cause and effect. You can hope, wish or pray that it is. You have to connect the dots from the pipeline all the way to the DAC clock. And be able to show that objectively using measurements. If it is some other benefit you can't quantify, then any reasoning you give is neither here, nor there. It is all hope and wish.
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.
Similar threads
 | Steve Williams Site Founder | Site Owner | Administrator |  | Ron Resnick Site Owner | Administrator |  | Julian (The Fixer) Website Build | Marketing Managersing |