Audio Testing: Difference between revisions

From wiki.jriver.com
Jump to navigation Jump to search
No edit summary
No edit summary
 
(3 intermediate revisions by the same user not shown)
Line 15: Line 15:


==Testing==
==Testing==
JRiver believes all modern computers are fast enough at #2, and that more speed isn't relevant. But some companies make claims to the contrary, so let's test performance.
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. Here is how several players stack up in this regard, testing ASIO output as 32-bit integer (a common hardware format):
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):


==Results==
==Results==
Line 37: Line 41:
| Foobar2000
| Foobar2000
| 364.9
| 364.9
|-
| HQPlayer
| 167.4
|-
|-
| JPlay
| JPlay

Latest revision as of 17:25, 14 February 2012

Overview

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

Drivers

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.

Players

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.

Testing

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):

Results

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


JRiver still believes that speed doesn't matter.