JRiver MC Version 18
- Thread starter Ki Choi
- Start date
Hi, this is my first post. I had trouble with the JPlay trial version a couple years ago and I didn't purchase it. A month ago I did purchase it and I am using the JPlay mini mode that shuts off all unnecessary computer processes. In my system, with a Lindeman 825 CD Player/ DAC, the sound is more detailed with JPlay than with just JRiver 18. Definitely worth the small amount of money for the improvement in sound quality. The issue is that I need more RAM to load the music into as it reads it from the RAM. I would advise everyone to try the trial version and see if it makes a difference in their system.
No, it is all about delivering bit-perfect to the hardware. A quick primer:
Normally, Windows takes audio from every app, converts it to high resolution floating point (from integer), and them mixes and optionally resamples the audio before converting/dithering for delivery to the driver. The driver then hands the bits to hardware. Even if there is one app running, and you set the sample rate to the one that the hardware is set to, the conversion to and from floating point/dither still occurs. This can cause the bits to change. Hence the request for "bit perfect."
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 Steinberg years ago. The main reason for existence was reducing delay which we don't care about in music applications. This interface became quite popular and the standard in pro world. At Microsoft, we wanted to support it "out of box" but couldn't because we didn't own the specs. So we created a competing one called WASAP which accomplished the same thing. In its "exclusive" mode WASAPI sends out the bits as is, achieving bit direct functionality. WASAPI can work in "push" or "pull" modes. The pull mode is called the "event style WASAPI." This is what the link above says.
Push and pull modes change how the PCM data is sent to the driver as far as timing. So the system behavior changes. The bits will be identical in both cases. Which one "sounds better" is unknown per my last post.
Steve Williams
Site Founder, Site Owner, Administrator
Bruce B
WBF Founding Member, Pro Audio Production Member
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)?
According 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.
So, I don't understand how you can say that JRiver's recommendation of WASAPI event style is " all about delivering bit-perfect to the hardware."
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)?
According 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.
So, I don't understand how you can say that JRiver's recommendation of WASAPI event style is " all about delivering bit-perfect to the hardware."
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."
Ok, so there is a bug in Microsoft's USB driver using WASPI which needs WASAPI event style for correct operation - nothing whatsoever to do with push/pull operation? Is this correct?
Yes, I know pull methods make more sense but if everything delivered is bit-perfect then it shouldn't matter, right?
Yes, I know pull methods make more sense but if everything delivered is bit-perfect then it shouldn't matter, right?
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'm trying to work out the inconsistencies apparent in JRiver's statements (& your seeming defense of their position):
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?
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.
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.
Anyway, who cares - it will all become clear in time.
Last edited:
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.
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.
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).
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.
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?
The above of course is my stance in audio
. When can get objective data and we don't, then my antenna is up.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.
If one of the benefit to JPlay is their exclusive modes where less process are run in the background, I wonder if JRiver can benefit from using Fidelizer (http://www.windowsxlive.net/fidelizer/)?
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.
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.
OK, I take your take on it.
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.
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.
If you can suggest such a measurement, I'm sure there would be great interest.The above of course is my stance in audio
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?
Based on your stated position & theirs - a consistent & honest statement from them would be that JRiver sounds no different to any other bit-perfect playback software so choose based on criteria other than sound quality.
Last edited:
Do 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.
Bruce B
WBF Founding Member, Pro Audio Production Member
Similar threads
 | Steve Williams Site Founder | Site Owner | Administrator |  | Ron Resnick Site Co-Owner | Administrator |  | Julian (The Fixer) Website Build | Marketing Managersing |