No, it is all about delivering bit-perfect to the hardware. A quick primer:Amir, Can you explain why JRiver might then have this recommendation on their forum regarding use of JRiver
Is this for some other reason than bit-perfect operation? http://yabb.jriver.com/interact/index.php?topic=80614.msg548590#msg548590
Traditional method for having the hardware play the exact bits that the hardware is set to is "ASIO." This is a driver interface invented for pro audio by Steinway years ago.
1. Objective macro level fidelity. At this level, it is easy to prove that jplay makes no difference. Bits get out the same way bits get out using Jriver. Calling it hoax in this school of thought is defensible, albeit in bad taste.
This is where we look at timing of the bits, noise radiating from PC, etc., bleeding into DAC. It might seem that we can put value behind Jplay in this model of the universe. But I have a hard time accepting this validates performance of Jplay. There is no way an app on a PC can ever control what all a PC does. The operating system is in charge and there is so much asynchronous activity going on, outside of the control of the playback app, that no argument in my opinion can easily stick that there is an improvement. For all we know, changing how things work, may make it worse, not better! So on this front, I think Jriver may be 90% right if not 100%.
Because they say the push mode USB driver has a bug in it. The pull method does the same thing and doesn't have that problem. In general, pull methods work better as the target device is better aware of when it needs data.Amir,
Exactly my point & why I asked you. WASAPI pushes data to the sound device, WASAPI event style allows the sound device to pull data. In both cases the data delivered to the hardware is bit-perfect. My question to you was why JRiver would suggest to use one bit-perfect delivery over another (they suggest to use WASAPI event)?
Not in this context. Their preference here is strictly based on functionality. I am not reading into anything they have said to improve fidelity. Here is their Wiki: http://wiki.jriver.com/index.php/WASAPIAccording to your previous parsing of the situation your conjecture was that JRiver are only interested in macro-level fidelity
Based on JRiver's recommendation for WASAPI event style over plain WASAPI, it appears that they are not just concerned with bit-perfection but have some interest in Objective micro level fidelity.
Because they say the push mode USB driver has a bug in it. The pull method does the same thing and doesn't have that problem. In general, pull methods work better as the target device is better aware of when it needs data.
Not in this context. Their preference here is strictly based on functionality. I am not reading into anything they have said to improve fidelity. Here is their Wiki: http://wiki.jriver.com/index.php/WASAPI
"There are two main ways to communicate using WASAPI. Both deliver the same audio data and will sound the same. One may work better with specific hardware."
This has several advantages:
- It lets the audio subsystem pull data (when events are set) instead of pushing data to the system. This allows lower latency buffer sizes, and removes an unreliable Microsoft layer documented below.
- It creates, uses, and destroys all WASAPI interfaces from a single thread.
- The hardware (or WASAPI interface) never sees any pause or flush calls. Instead, on pause or flush, silence is delivered in the pull loop. This removes the need for hacks for cards that circle their buffers on pause, flush, etc. (ATI HDMI, etc.).
- It allows for a more direct data path to the driver / hardware.
- The main 'pull loop' uses a lock-free circle buffer (a system that J. River built for ASIO), so that fullfilling a pull request is as fast as possible.
It doesn't look like you are trusting the answers I am providing, even though my team developed these interfaces. There is no reason for me to keep answering if you are going to dismiss them out of hand this way. And what you call selective is the direct quote from JRiver's Wiki on this very question. They couldn't say it more clearly. Not sure why you think there is another answer to hunt around for. But sure, if you know better than them and me, why not take the bullets and walk us through in what way you think the analog output of the DAC changes for the better because of them?Think you are being a bit selective in your extract, Amir
Here's what they say about Event Style WASAPI:
Do you still think that they are solely concerned with bit-perfection? I see a number of advantages they specify which have nothing to do with bit-perfection - "latency", "direct path", "pause or flush calls"
It doesn't look like you are trusting the answers I am providing, even though my team developed these interfaces. There is no reason for me to keep answering if you are going to dismiss them out of hand this way. And what you call selective is the direct quote from JRiver's Wiki on this very question. They couldn't say it more clearly. Not sure why you think there is another answer to hunt around for. But sure, if you know better than them and me, why not take the bullets and walk us through in what way you think the analog output of the DAC changes for the better because of them?
I am not in any way defending their position. I have no dog in this hunt. Don't use the software (Jriver or Jplay) and don't care what it does. I was attempting to explain why they would have the view that they have. So please don't paint any animosity you have toward their on me.I'm trying to work out the inconsistencies apparent in JRiver's statements (& your seeming defense of their position):
Simple: you are misunderstanding the explanation -- both theirs and mine. WASAPI is a mechanism to get bit perfect. There are two ways to implement it and they are explaining the difference. The destination, i.e. getting WASAPI to work and achieve bit perfect, is identical in both. So when I or they say this is about being "bit perfect" that is what it is. It is the goal and whether you use pull or push method, is the means to get there. The implementation details are not means to something else as you aiming at.How would "more direct data path to the driver / hardware." make any difference to bit-perfection data at the output? What exactly is the "advantage" here?
How would "fullfilling a pull request is as fast as possible." make any difference to delivering bit-perfect data at the output? Again what exactly is the "advantage" here?
What has ""creating, using, and destroying all WASAPI interfaces from a single thread" got to do with bit-perfection?
Jplay makes absolutely no difference with respect to *data* being output. If the bits physically change when Jplay sends them out, then it is flat out broken software. PCM bits better get out the same either way. The only thing that Jplay can impact to improve/change fidelity is impacting the data timing or noise from the PC. As I explained, it is outside of their means to impact those factors in a multi-tasking OS. Here is a simple test to prove that. Install Jplay and then run process monitor. Tell it to show you processes from all users. You will see dozens of background processes. Look at your hard disk light. Does it blink away seemingly randomly even if you are not doing anything? That is because of background activity.Their argument (& your defence of it) with Jplay is that JPlay makes no difference to the data on the output. If they can show how the "advantages" above make any difference to the output data then maybe there would be some consistency in what is being said here.
Anytime you change system behavior, by definition it can bleed into the output. If you believe the chances of that making an improvement is one a trillion, you would not accept that as mattering. That is the position that Jriver is taking based on my read of the few lines quoted from them. I allow larger odds but no way near it mattering absence some data since such change may be a negative, not a positive.Edit: I see you mentioned timing as being a difference between standard & event style WASAPI with the disclaimer that it may not make any difference to the sound. You therefore allow the possibility that it does make a difference whereas JRiver state it makes NO difference.
Not animosity, just like to understand when I see double-speak & hypocrisy from a company especially when it reaches the level of calling a product a "hoax" & banning posts about it on their forum. For instance, they have not removed a thread started on their forum which purported to show how JRiver produced lower jitter than Foobar, even though the graphs & analysis produced were untenable. So again, do they reject the concept of anything other than bit-perfection being of importance & if so why not delete a thread that is mis-information or even comment on it. Double-speak, in evidence it would appear - it flatters JRiver so therefore it remains.I am not in any way defending their position. I have no dog in this hunt. Don't use the software (Jriver or Jplay) and don't care what it does. I was attempting to explain why they would have the view that they have. So please don't paint any animosity you have toward their on me.
My pointing out the WASAPI event style "advantages" is to point out this double-speak. These "advantages" have no relevance to their/your claim of bit-perfection. According to their stance ASIO & KS would also sound exactly the same. As per your example, all bit-perfect players sound the same.Simple: you are misunderstanding the explanation -- both theirs and mine. WASAPI is a mechanism to get bit perfect. There are two ways to implement it and they are explaining the difference. The destination, i.e. getting WASAPI to work and achieve bit perfect, is identical in both. So when I or they say this is about being "bit perfect" that is what it is. It is the goal and whether you use pull or push method, is the means to get there. The implementation details are not means to something else as you aiming at.
OK, I take your take on it.The choice of implementation does have ramification on how things work. One such ramification is how reliable it works and whether you will get buffer underruns and hence hear a glitch. Creating and destroying Wasapi handles for example is a resource (and coding accuracy) concern. It is something a developer would need to know. They are simply saying it is a harder implementation to get right. Fullfilling a request means that if Jriver falls behind due to other activity in your system, there is less chance of a glitch occurring than in the other method. More direct path says there is less layers of software that may have bugs in it (and they give an example of USB class driver).
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 effect 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.Jplay makes absolutely no difference with respect to *data* being output. If the bits physically change when Jplay sends them out, then it is flat out broken software. PCM bits better get out the same either way. The only thing that Jplay can impact to improve/change fidelity is impacting the data timing or noise from the PC. As I explained, it is outside of their means to impact those factors in a multi-tasking OS. Here is a simple test to prove that. Install Jplay and then run process monitor. Tell it to show you processes from all users. You will see dozens of background processes. Look at your hard disk light. Does it blink away seemingly randomly even if you are not doing anything? That is because of background activity.
I suggest that it's not a case of getting lucky. You seem to suggest that these developers are floundering around trying out "tweaks" to get lucky? I see no compunction on them to produce any such data as you seem to demand, much as no other playback software vendor does. Until such an agreed measurement is recognised & agree, the free trial model seems appropriate to those who can trust their ears, sighted and/or blind.Can you get lucky and have Jplay reduce noise/jitter? Sure. It is possible. It is just as possible that it would make things worse. And at any rate, they have the responsibility to show, even in the best case scenario, that this occurs. They are the manufacturer of this software. They owe us at least some data here. Even an audiophile amp will have power and frequency response measurements. Why can't they instrument the output of a system and show an AB? I am not taking a position against them. I simply dismiss them because I know if I were in their shoes, I could do the instrumentation that I talked about. As such, they should be just as capable. But they are not going there. Why?
If you can suggest such a measurement, I'm sure there would be great interest.The above of course is my stance in audio. When can get objective data and we don't, then my antenna is up.
I really don't follow your logic that a reduction in noise can be detrimental, particularly if it is a reduction in correlated noise. You seem to take a simplistic view of this?Anytime you change system behavior, by definition it can bleed into the output. If you believe the chances of that making an improvement is one a trillion, you would not accept that as mattering. That is the position that Jriver is taking based on my read of the few lines quoted from them. I allow larger odds but no way near it mattering absence some data since such change may be a negative, not a positive.
Let's say our background activity the bleeds into the output of the DAC is reduced by a factor of 10 using Jplay. Would you assume that this made the fidelity better or worse? Likely you would say better. But it could be exact opposite. Let's say that background activity was completely random as a GHz CPU would naturally generate as it is executing code. If you replace timing/noise variations that occur in millions of times per second and put in place something that occurs at thousands/sec, you have now pulled that jitter/noise into audible band, even though you reduced its frequency by orders of magnitude! Less is not more here. What matters is the nature of before/after. And without any instrumentation or data you can't know if you are in reality making this worse.
So we have three states here: it makes no difference. It makes things better. It makes things worse. Two out of three factors is against them. People who don't know how this technology works, allow two states here: it makes things better (since there is less activity) or makes no difference. So it is natural that they give it the benefit of doubt more than I would. And more than the reality dictates.
I have no experience with Jplay. But I did test Foobar2000 against Windows Media Player. The first time I installed Foobar2000, I was shocked how much better it sounded. More ambiance, more resolution, more air, you name it. I thought it was that way because it was using exclusive mode, etc. I searched and realized by default it was the exact same pipeline as WMP! Indeed the developers in their FAQ said it sounds identical. I repeated my tests blind and this time the two sounded identical! I listened sighted and the difference went away. Then I talked myself into thinking it is there and once more, I heard all of those great benefits! I know we like to dismiss such tests but please guys, keep this factor in mind. When differences are this small, and this subtle, then placebo factor may be way, way more powerful effect than what the system difference is. This may explain why you don't always think it makes a difference. Or why others do not.
2. Objective micro level fidelity. This is where we look at timing of the bits, noise radiating from PC, etc., bleeding into DAC. It might seem that we can put value behind Jplay in this model of the universe. But I have a hard time accepting this validates performance of Jplay. There is no way an app on a PC can ever control what all a PC does. The operating system is in charge and there is so much asynchronous activity going on, outside of the control of the playback app, that no argument in my opinion can easily stick that there is an improvement. For all we know, changing how things work, may make it worse, not better! So on this front, I think Jriver may be 90% right if not 100%.
...
As far as I can tell, Jriver folks live in land of #1 so in that regard, it is perfectly justifiable for them to say what they said since countless other people believe in the same view of the world. Even if they traveled to #2, I believe the weight of evidence is on their side. No one has shown objectively how the PC acts differently on the output of the DAC when the playback pipeline is changed with Jplay.
Why can't it do anything about noise? As Amir said, changing system behaviour can change the noise at the outputs - I would say the spectrum of the noise at the outputsDo we understand how JPlay affects things? To me, the two largest evils in digital audio are jitter and noise; so I am wondering if JPlay somehow improves jitter performance (it surely can't do anything about noise).
I agree with you on #2 in principle, but I have to clear that one question... And perhaps those who can't hear JPlay's alleged performance increase (if we accept, for argument's sake, that it does increase performance) do so because the noise in their digital playback overshadows purported micro-jitter improvements.
How do we define noise?
![]() | Steve Williams Site Founder | Site Owner | Administrator | ![]() | Ron Resnick Site Co-Owner | Administrator | ![]() | Julian (The Fixer) Website Build | Marketing Managersing |