Media Player Q&A: Q4 What makes one media player sound different from another?

4. What makes one media player sound different from another?

Jonathan Reichbach, President, Sonic Studio (Amarra)

Most can agree that each software application sounds different. Each has a different "fingerprint" with regards to how they interact with the hardware and software in the computer and how it sounds. For great sound we find that the quality of the audio processing for gain, dither, and EQ all contribute to a different sound. Another determining factor is how the data (music) is read from the disk drive and processed. As Amarra uses the dedicated SSE we are able to optimize every aspect to fine tune your sound. Apple's Core Audio is much more general purpose and this comes with certain tradeoffs that can effect sound quality.
Damien Plisson, Founder, Audirvana, (Audirvana Plus)
The audio signal path can be very different, with different level of optimizations. Not all include full optimized path down to the kernel CoreAudio implementation itself. The computer activity synchronous to the audio signal needs to be tightly controlled, especially for the purity of the bass frequencies.
Tim Murison, Co-Founder & CTO, BitPerfect Sound Inc., (BitPerfect)
If we're talking only bit perfect playback then I'd argue that the efficiency of getting music to the DAC is the main determinant of sound quality.
Stephen F. Booth, Founder and Developer,, (Decibel)
I think that obvious variations in sound are due to differences in DSP applied by the player. For example, if software sample rate conversion is being performed the sound will be different based on which sample rate converter is being used and how it is configured. If digital volume is being used, the sound will be different based on how the gain is applied. For lossy file formats like MP3, smaller differences in sound can be caused by the type of decoder that is used. Each of these small differences adds up to a different sonic signature for each player.
Jussi Laako, Owner, Signalyst, (HQ Player)
From my perspective, different processing (upsampling, dithering, etc) algorithms.

There are also hardware dependent differences due to different software architectures of players. But this is less deterministic and smaller difference.

Another is digital volume control. Background noise of good quality DAC is so low that using digital volume control for adjusting volume within normal listening volume range is completely feasible. With DSD there are not even "bits to lose", DSD even works better when it's not pushed to the max.

Josef Piri & Marcin Ostapowicz, JPlay (JPlay)
It would seem that almost everything can have an effect: for example, GUI. JPLAY plugins are available for JRiver, iTunes and foobar2000. In theory all these plugins should sound the same because the same JPLAY playback engine (which operates as completely isolated Windows service) is used. Yet, each plugin sounds different! GUI is just one example. There are many other factors like memory management, output method (direct sound, wasapi, asio or kernel streaming), buffering etc - all of which do not modify music bits in any way and yet have an effect on sound quality.
Jim Hillegass, Founder and CEO, JRiver (JRiver Media Center)
The way it addresses the sound device may not be bitperfect. It may not be capable of upsampling or playing high sample rate files at their native bit depth.
Dr. Rob Robinson, Director of Engineering, Channel D, (Pure Music)
This sort of question is impossible to answer without seeing the “innards” of all considered players, and comparing them. It is kind of like asking a question comparing high performance automobiles without taking a look under the hood. However, I can speak about the design of our products.

I have discussed signal flow and streamlined algorithm design elsewhere, see for example the 2010 Advances In Computer Audio panel session video on the Rocky Mountain Audio Fest website and Jim Smith’s Get Better Sound website interview, among other places. There is no single or main factor or difference, it is a combination of many small things in the design, tied together in the implementation. On a high level, for example, the memory play feature that circumvents the need to access the music storage media / hard drive during music playback; the dithered volume control that reduces distortion caused by the word length reduction of a digital attenuator, and the upsampling feature which can deliver better performance. But these are comprised of many tiny pieces that must work together.

There are many ways of implementing a Memory Play feature, and we have probably tried all of them over the course of programming audio software on the Mac OS over the years. Circular buffer, double buffer; these easy to use and traditional techniques for handling streamed data have their place and are used in our other products. But we have diverged from the usual approach in Pure Music / Pure Vinyl and don’t use them, because a no-compromise music player allows an unconstrained choice of design approaches.

Then there are the not so concrete aspects of the design. This is part of our IP “sweat equity” that came about as a result of understanding best programming practices for smooth data throughput and instruction execution, developed over 27 years of experience writing software for the Apple Macintosh platform. This included writing driver level code to support custom hardware for specialized laboratory instrumentation.

Developing driver level code requires you to carefully contemplate the effect of small changes you might make. The timing of instruction execution and data transfers is critical. If you are designing a word processor or database application, those factors doesn’t matter much, if at all. But real-time processing such as audio playback is a different matter.

It’s a bit like designing a boat hull to carve through the water with the minimum of turbulence and drag. A small design change can cause an unexpected result (usually for the worse). Driver-level code has to run fast and smooth, and the same design principles apply to any real-time programming task such as audio player software. We want to create the minimum amount of “turbulence” (for example in the form of spikes in CPU usage) during the time when music is being played, parceling tasks to the CPU as smoothly as possible. As one example, computer power draw fluctuates with CPU usage, and these fluctuations can pollute power supply ground references, contributing to digital jitter (as I explained in the 2010 video referenced above). A steady-state, “non- turbulent” design circumvents this problem. Understanding driver design gives the insight needed for player software that uses the CPU and computer resources as smoothly and efficiently as possible.

Wavelength's picture


Look I have been trying to figure this out for years. I have tested 3 of these apps in the following setup:

Computer<---USB--{USB Analyzer}-->USB->SPDIF===>Prism dScope.

Then off the USB->SPDIF converter I have an I2S analyzer.

So I have the following bit perfect transactions:

0) File dumped in standard PCM stereo format.

1) Timed USB Analyzer with buffers of PCM data.

2) Saved PCM from the Prism dScope III analyzer.

3) Saved PCM + TIme information from the I2S analyzer.

All three applications had the same results. This is a much better test than most bit perfect tests and they all passed the 1 minute song.

But again they all sounded different as does operating systems.

At this point I would rather look at more interesting testing and see what the differences could be.



Michael Lavorgna's picture

At this point I would rather look at more interesting testing and see what the differences could be.

Do you have any ideas where to start looking?

On a somewhat related note, Charlie Rose: The Brain Series has been fascinating and my guess is if we want to deal with the question of whether or not certain things some people perceive in hi-fi are real or imagined, we need to be looking at the brain's response to listening.

robpriore's picture

I think we can all agree with the axiom that the least amount of interaction, attenuation, distortion, etc., on our music is best.  A computer should faithfully export ALL the music data to an audio only interface.  Since this is not a typical design feature of our computers we must use software to achieve that end.  If an external DAC with proper reclocking is not in your system then relying on any of these softwares alone will not get you closer to purity.  What's amazing about computer served audio is if you get it right there's no transport on earth, at any price, that will best your stream.