The Concept

For Windows only

Windows OS has two built-in sound subsystems: professional ASIO from Steinberg, which is the de facto standard for high-quality sound recording, and the original WASAPI Exclusive from Microsoft with the ability to play in mode without processing the audio stream.

In the Apple ecosystem, the Core Audio subsystem has been primarily focused on iOS for iPhone for the last decade and a half, which is understandable, macOS is secondary and is used mainly for developing iOS applications. There is also lack of support for the Native DSD output mode.

In Linux, there is no single sound subsystem. Different versions and builds may use different subsystems. Setting up quality sound output in Linux is complex and unpredictable. A player that plays music well on one system may not work on another.

Professional approach

A few years ago, after unsuccessfully trying to find an audio player comparable in sound quality to professional applications, I decided to write a player focused only on quality, albeit without the usual functionality.

The main difference is that you can only add files with the same sampling frequency to the current playlist. This alone makes audio stream management more logical, smooth, and predictable.

Absolute precision

In the basic versions of the player, the audio stream is transmitted unchanged, without any processing. Built-in algorithms only optimize the path through the system for its uniform, uninterrupted movement.

Of course, at the customer's request, audio signal processing can be added to the player that does not contradict the main concept. For example, downsampling or equalizing for a specific audio path.

Native source code

Usually, when writing audio players, high-level programming languages are used. In the simplest case, one operator is enough: Play (path to file), the compiler and operating system will do the rest. This will work quite well in modern systems if you are satisfied with the usual level of sound quality. Serious players use more complex algorithms, but high-level languages are almost always used. It is simpler, more convenient and can be easily compiled for different platforms.

I write code in a basic level language and use only the basic functions of the Windows OS, without using Open GL, DirectX, .NET Framework, etc. Well, the core of the audio engine is written in assembler, which allows direct control of the audio stream without unnecessary layers.

No jitter

When the player is launched, space is reserved in the RAM not only for the usual double buffering, but also a special large area for normalizing the audio stream, which allows for the complete removal of jitter and, using the physical principles of operation of SDRAM microcircuits, any other digital artifacts that arise on the path from the original audio file to the memory cells.
This functionality places increased demands on system resources, but it's worth it.

Automatic setup

The player's audio engine automatically adjusts to the system and DAC, as befits a quality user-oriented application. No tedious manual settings, sometimes obscure, the selection of values of which can take days, months, or even years.

No tags

ID3 tags were invented a long time ago for small mp3 files. Modern files with high-resolution recordings are much larger. To read the track titles, you need to open each file and find the necessary information, which is written at the very end of the file. This takes time and resources. It is much easier to read the file name, which is usually the track name.