Software playeri - zvučne razlike

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.