Pure Player Mode

Part 01What “Pure Player” actually does

Pure Player Mode is a single toggle inside Anantar Ultimate. Tap it on, reboot once, and from that moment Infinity Player is the only process the DX340 audio device will accept. The Android audio server — the layer that normally mediates every sound on every Android device on Earth — is taken out of the path. The bits that come off your file arrive at the FPGA without anybody else getting to touch them on the way.

In plain language: when Pure Player is on, your DX340 stops behaving like a phone running a music app and starts behaving like a dedicated CD transport — one job, one process, one path. The volume slider stops nudging digital samples and starts driving analogue attenuation in the DAC. Notification dings disappear. The whole audio subsystem becomes a single-purpose tunnel from file to ear.

As a user, you don't need to know how the swap is implemented. You flip a switch in Anantar Ultimate, the device reboots, and on the next boot Infinity Player owns the audio device. Flip it back off, reboot again, and the device returns to ordinary Android behaviour — everything else (apps, library, accounts, settings) is untouched either way.

If this idea sounds familiar, it should. iBasso's own MangoOS — the second, stripped-down operating system that ships on DX-series players — solves the same problem the same way: it removes Android from the audio path so the music app talks directly to the hardware. The trade-off with MangoOS is that you reboot into a different OS and lose everything Android does for you (streaming apps, browsers, system services). Pure Player follows MangoOS' principle — one process owns the audio device end-to-end — but does it without leaving Android: you keep your apps, your accounts, and your streaming services, while the audio path becomes as direct as it would be on the bare-metal OS.

Pure Player is not just an “exclusive mode” flag inside the player. It is a system-level handover of the audio device — the same idea as MangoOS, applied inside Android instead of replacing it. That is why it requires a reboot, and why no Android music app on the market — Neutron included — can produce the same result from userspace.

Part 02Why the Android audio server matters — even when it doesn't resample

A common misconception is that the headline Android-audio problem is sample-rate conversion. On a modern DAP it is not: the DX340's standard HAL already passes the file's native rate through — 44.1 to 384 kHz — with no resampling. So if Pure Player doesn't escape something Android was doing wrong with the rate, what does it actually do?

It removes audioserver (AudioFlinger) from the path. Even without resampling, the audio server still has four effects on what the DAC sees:

• Software volume. AudioFlinger multiplies every sample by the stream-volume scalar. At reduced volumes, the lowest-significance bits are gone before the DAC ever sees them.
• Buffer chain. App buffer → mixer buffer → HAL buffer → ALSA — four links, each adding latency. Pure Player has one.
• Cross-process IPC. Frames hop between processes before reaching the kernel. Each hop is a context switch the scheduler can delay; small but not deterministic.
• Shared device. The audio server keeps the stream alive for any notification or system click that might want to mix in. Pure Player switches the device to exclusive.

Part 03How playback reaches the DAC — before and after Pure Player

The clearest way to see what Pure Player changes is to draw both paths next to each other. First, how every Android music app on DX340 — Neutron, UAPP, Hiby, Tidal, the stock player — reaches the DAC today:

Neutron and UAPP do everything an app can do inside the Android sandbox — high-priority audio thread, native-rate request, codec-gain writes in “Direct” mode. But every frame still passes through audioserver on its way to the kernel. The mixer thread, the software gain stage, the four-deep buffer chain, the IPC hop — they don't go away from inside the sandbox.

Now flip Pure Player ON and reboot. The same chain collapses into this:

Three things change in a way the user can feel:

• One owner, one path. The kernel holds the audio device exclusively for Infinity Player — no notifications, no keyboard click, no other app can write a sample.
• Native rate, single buffer. Same 44.1–384 kHz the standard HAL already preserves, but through one buffer instead of four — less latency, less jitter.
• Bit-perfect volume. The slider writes directly to codec_volume — analogue attenuation in the DAC, no software multiplier eating bits.

Part 04What we can prove — on-device diagnostics

Audio claims should be testable. We will not pretend that Pure Player produces a measurably better number on a 1 kHz sine wave at the DAC pins — iBasso's standard Android HAL on DX340 is already excellent at the things you can measure with a meter, and the analogue output looks similar in both modes. What Pure Player can prove is something a meter cannot show: who owns the audio device, and whether the path is what we say it is.

The two snapshots below come from a real DX340 running the same FLAC file in two different scenarios. The commands are ps (which app is alive), lsof /dev/snd/pcmC0D0p (which process holds the audio device), and cat /proc/asound/card0/pcm0p/sub0/status (what state the kernel device is in). They are reproducible on any unit.

The two snapshots are the entire argument for Pure Player condensed onto one screen. The output sample rate is the same (96 kHz). The DAC is the same chip. The numbers a meter would read at the headphone jack would look very similar. What is different is structural — and structurally provable: in scenario A, the kernel reports the audio server as the device owner; in scenario B, the kernel reports the music app itself. That is not a subjective claim, and it is not something an Android player can produce from inside the sandbox no matter how clever its code.

In other words: Pure Player's value is not “measurably louder/quieter/cleaner at the jack”. Its value is determinism — you can prove, on demand, that nothing else is in the path. And once you have that proof, every other claim built on top of it (bit-perfect volume, lowest latency, no system-sound interruption) becomes verifiable rather than promised.

Part 05Side-by-side: Pure Player vs Neutron / UAPP / typical Android player

Here is the honest comparison. We are not saying Neutron is a bad player — it is one of the best Android music apps ever written, and on DX340 in particular it gets as close to bit-perfect as Android allows. The point is that “as close as Android allows” still has a ceiling, and Pure Player is above that ceiling by design.

In one sentence: Neutron is the best music app you can write inside the Android sandbox; Pure Player is what you get when the sandbox is set aside and the player is allowed to own the audio device directly.

Part 06Streaming use case — Tidal & Qobuz under Pure Player

A common question: if Pure Player owns the audio device exclusively, can I still stream Tidal or Qobuz? Yes — and that is the point. Streaming services run inside Infinity Player, not as separate apps. The Tidal and Qobuz browsers, your library, your playlists, and the player itself are one process. So when Pure Player hands the audio device to Infinity Player, hi-res streaming comes with it.

This is what MangoOS cannot do. On MangoOS you reboot into a stripped Linux that has no Tidal app, no Qobuz app, no network streaming stack — just local files. Pure Player keeps you on Android, so the WiFi stack, the streaming SDKs, and your accounts are all still alive while the audio path stays single-owner.

• Native rate end-to-end. A 24-bit / 192 kHz Qobuz stream stays 24-bit / 192 kHz from the CDN to the DAC. No transcoding, no resampling, no software-volume scaling on top.
• Gapless streaming. Infinity Player pre-resolves the next track's CDN URL ~5 seconds before the current one ends, so album-mode Qobuz/Tidal listening crosses tracks without the usual streaming gap.
• Exclusive device, even while streaming. WiFi can interrupt, the network can stutter, but no other process on the device can write a sample — the kernel still reports Infinity Player as the sole owner of /dev/snd/pcmC0D0p.
• Same volume rules apply. The slider drives codec_volume directly — analogue attenuation in the DAC. Streaming hi-res at low volume is not bit-reduced.

In short: Pure Player + streaming is the scenario MangoOS was never designed for, and the one ordinary Android players can't cleanly deliver. It is the reason this approach exists inside Android instead of on a separate OS.

Part 07When to turn it on, when to turn it off

• Turn it ON if you mostly use the DX340 as a dedicated music player, listen to one track at a time, and care about a deterministic, bit-perfect path with no software-domain volume losses.
• Turn it OFF if you want notification sounds, BT call audio, video apps, or any scenario where multiple apps need to share the audio device.
• You can leave it on permanently on a device used only for music; that is what most listeners do. The reboot is a one-time cost.
• If switching from another music app, give Infinity Player about three seconds before you tap Play — the kernel needs that long to release the audio device from the previous holder.
• If something sounds wrong (silent, noisy, distorted), the first diagnostic is to toggle Pure Player off, reboot, and try again. If the problem disappears, it is in the Pure Player path; if it persists, it is somewhere else.

Pure Player is one of two features in this product that genuinely cannot be reproduced by an Android app — the other is direct FPGA harmonic tuning. Both depend on owning a layer of the operating system that ordinary apps cannot reach. That is the difference between a player on a DAP and a player that is the DAP.