One issue with USB is that it sends regular bursts of info like the start of frame packet - "The SOF packet consisting of an 11-bit frame number is sent by the host every 1ms ± 500ns on a full speed bus or every 125 µs ± 0.0625 µs on a high speed bus". If the timing of this shifts or is variable, this could elicit a different & variable reaction from the USB receiver & translate into a different & varying jitter or noise spectrum. Making the PC end as solid & stable as possible without undue processing could be one factor in ameliorating this variation. It might not be the low level of jitter that we notice but the variation in jitter - that's one reason why I say that the measurements we currently run seem not to be capable of picking up these issues or we are not directing them to the correct target for measuring.
Jplay : Wow
- Thread starter rhbblb1
- Start date
One issue with USB is that it sends regular bursts of info like the start of frame packet - "The SOF packet consisting of an 11-bit frame number is sent by the host every 1ms ± 500ns on a full speed bus or every 125 µs ± 0.0625 µs on a high speed bus". If the timing of this shifts or is variable, this could elicit a different & variable reaction from the USB receiver & translate into a different & varying jitter or noise spectrum. Making the PC end as solid & stable as possible without undue processing could be one factor in ameliorating this variation. It might not be the low level of jitter that we notice but the variation in jitter - that's one reason why I say that the measurements we currently run seem not to be capable of picking up these issues or we are not directing them to the correct target for measuring.
This is my first post as well.
I'm currently using JRiver v.16 and found it superior to Media Monkey (both for sound and as a database manager) on my Goodwin's Silent Server. Tried to use JPlay with it and it was VERY problematic. My question for you is whether you tried JRiver by itself before you added JPlay and whether there was a significant improvement.
I'm currently using JRiver v.16 and found it superior to Media Monkey (both for sound and as a database manager) on my Goodwin's Silent Server. Tried to use JPlay with it and it was VERY problematic. My question for you is whether you tried JRiver by itself before you added JPlay and whether there was a significant improvement.
My analyzer is "dual domain" so can measure in analog domain in addition to FFT based digital.
OK, will it show noise modulation? I'm asking this in complete innocence & without any judgement. I f you can uncover differences I would be interested.
I started with Media Monkey, then switched to JRiver v.17, then added JPLAY for JRiver. Each step was an improvement. The step up to JPLAY was bigger than the switch from Media Monkey to JRiver. I believe you need to upgrade to JRiver v.17 before adding JPLAY.
Or you could try running Jplay in standalone mode to hear what it sounds like - JPlaymini & then use whatever front end suits your needs - Foobar or JRiver or MP3Toys or ......
This information is suspect. rhbblb signed up to post about jplay and seven of eight posts are about jplay.
JRiver has asked jplay to remove all references to JRiver from their site. So far, they have not done so.
Mr. J River,
Get a life. The last time I looked this was a hobby. If you think I signed up to WBF to post about JPLAY you are sadly mistaken. If you believe that it is suspect that JRiver is superior to Media Monkey, so be it. nuff said.
Steve williams
Site Founder, Site Owner, Administrator
I stumbled upon this thread searching for JPlay feedback. It is clear there is a lot of FUD about this. I am ONLY interested in analytical results. My suggestion is that those that are invested 'proprietors' should refrain from comparisons, or characterization of those who are not in this to make money. JMHO
My view is I would prefer NOT to spend $50 for software to hear audiophile quality music on my computer. After all this can be mereley about getting the exact bits to the external decoders, whether a USB DAC or HDMI receiver. I good free MySQL like database should be sufficient to find the music and then cause the bitstream to be sent out the port. Am I thinking clearly?
My view is I would prefer NOT to spend $50 for software to hear audiophile quality music on my computer. After all this can be mereley about getting the exact bits to the external decoders, whether a USB DAC or HDMI receiver. I good free MySQL like database should be sufficient to find the music and then cause the bitstream to be sent out the port. Am I thinking clearly?
Last edited:
No, you are not thinking correctly if you think it is all about the correct bits being delivered - this is a basic & fundamental requirement of all playback software!
$50 buy a lot of FUD
It IS about 1-The correct bits delivered out USB or HDMI ports and 2-the external DAC being clocked properly (no audible jitter).
I don't know if your post was agreeing or dis-agreeing?
But really that is ALL THERE IS. Correct bits delivered externally, and the external DAC using these bits. The desired bitrate analog conversion rate is/should be known to the external DAC device
Like I wrote, there is a lot of FUD from JRiver and others. $50 buys a lot of FUD. Be smart and use your dollars wisely.
It IS about 1-The correct bits delivered out USB or HDMI ports and 2-the external DAC being clocked properly (no audible jitter).
I don't know if your post was agreeing or dis-agreeing?
But really that is ALL THERE IS. Correct bits delivered externally, and the external DAC using these bits. The desired bitrate analog conversion rate is/should be known to the external DAC device
Like I wrote, there is a lot of FUD from JRiver and others. $50 buys a lot of FUD. Be smart and use your dollars wisely.
No, you miss an important third point - noise on the USB line (forget HDMI as it's badly compromised) & the effect this noise has on the D/A stage!!
It IS about 1-The correct bits delivered out USB or HDMI ports and 2-the external DAC being clocked properly (no audible jitter).
I don't know if your post was agreeing or dis-agreeing?
But really that is ALL THERE IS. Correct bits delivered externally, and the external DAC using these bits. The desired bitrate analog conversion rate is/should be known to the external DAC device
Like I wrote, there is a lot of FUD from JRiver and others. $50 buys a lot of FUD. Be smart and use your dollars wisely.
As a guy who used to manage a 50 person team that developed media players, "them are fighting words!"It IS about 1-The correct bits delivered out USB or HDMI ports and 2-the external DAC being clocked properly (no audible jitter).
I don't know if your post was agreeing or dis-agreeing?
But really that is ALL THERE IS. Correct bits delivered externally, and the external DAC using these bits. The desired bitrate analog conversion rate is/should be known to the external DAC device
Like I wrote, there is a lot of FUD from JRiver and others. $50 buys a lot of FUD. Be smart and use your dollars wisely.
There is a lot more to a media player than how it stores the bit and how it opens the device to spit them out. For starters, is the interface. How easy is it to manage and store all of your metadata? People seem to like Jriver for its extensive metadata handling for classical music and such. Other considerations are richness of album metadata service and ripping accuracy. Most importantly for me personally is usability. How easy is it to find your content on the PC and increasingly these days, on a remote device? Is there a rich iPad or Android experience for example?
I am personally not a fan of Jriver, having found it lacking in usability so I am not saying to defend Jriver. But let's not trivialize what is in these media players. I think the one we were developing crossed the one million lines of code!
He is asking why he can't go and use MySQL to build his own player and asking why a third party player would cost $50. The $50 didn't just toward reading and writing bits.
It IS about 1-The correct bits delivered out USB or HDMI ports and 2-the external DAC being clocked properly (no audible jitter).
I don't know if your post was agreeing or dis-agreeing?
But really that is ALL THERE IS. Correct bits delivered externally, and the external DAC using these bits. The desired bitrate analog conversion rate is/should be known to the external DAC device
Like I wrote, there is a lot of FUD from JRiver and others. $50 buys a lot of FUD. Be smart and use your dollars wisely.
Except for the FUD part, I completely agree. But there is a very vocal contingent who believe that bits are not always bits.
The timing problems people believe that USB introduces can be corrected or not by the DAC. A DAC should buffer and use the bits with it's own clock.
Similar threads
- Sticky
