Audio Testing

From JRiverWiki
Jump to: navigation, search


This topic was written to address the claims that some players make about special memory management affecting audio quality. We believe it doesn't.


The best audio outputs, ASIO and WASAP Event Style, periodically ask the player for data. This data is needed by the soundcard or DAC for playback.


There are two important things a player should do.

  1. Deliver perfect bits (or the best bits possible if you use processing)
  2. Deliver the bits without delay

Let's assume all good players are able to achieve bit-perfect playback, meaning #1 above is equal for all players if you don't use processing. There are many reasons that JRiver's 64bit audio engine and the deep, flexible DSP stack are valuable, but we'll ignore that here.

Let's focus on speed (#2), remembering that the _only_ thing the player does is fill a buffer when asked.


JRiver believes all modern computers are fast enough at #2, and that more speed is not relevant. But some companies make claims to the contrary, so let's test performance.

It's easy to measure how fast different players are at this. This is done by compiling an ASIO driver that includes instrumented timing of its calls back to to the player for data (the ASIO call bufferSwitchTimeInfo).

The tests below time the average buffer fill performance during the course of a five minute song. The test machine is an i7 running Windows 7 x64.

Here is how several players stack up in this regard, testing ASIO output as 32-bit integer (a common hardware format):


Player Samples per µs (higher is better)
JRiver 1019.2
MediaMonkey 1013.8
cPlay 864
Foobar2000 364.9
HQPlayer 167.4

JRiver still believes that speed doesn't matter.