Add an optional minimal processing playback mode

[tweakerrobin]

Music Assistant currently processes all audio internally as 32 bit floating point PCM before sending it to the player. That is a strong and valid design choice, but some (audiophile) users want explicit control over whether playback follows the full internal processing path or the most direct path possible. An optional minimal processing playback mode would serve that group without changing the default behavior for everyone else. This would improve user control, better support high end audio use cases, and make MA more flexible for different listening priorities.

[iVolt1]

Interesting idea. What are the advantages of the most direct path possible other than maybe latency? Assuming the destination players can handle the source losslessly, is there digital audio information lost converting to and from 32 bit floating point PCM?

[tweakerrobin]

There are two aspects here: control and determinism of the playback chain.
From a purely theoretical perspective, converting to 32 bit floating point PCM is effectively transparent for most material, so this is not about claiming obvious data loss in the traditional sense. The question is more about what happens to the signal path as a whole once everything is forced through a unified processing pipeline.
The main advantages of a more direct playback path are:
Full control over the exact transport and format that reaches the DAC, without intermediate transformations that are not strictly required.
Predictable behavior for formats that rely on specific encapsulation or framing.
Avoiding unnecessary format conversions that may introduce edge cases, resampling steps, or player side incompatibilities depending on the chain.
Alignment with hardware driven playback models where the endpoint (DAC/player) is intentionally responsible for handling the native stream
In practice, this is less about “losing bits” and more about avoiding transformations altogether when they are not needed.
A concrete example is DSD (over DoP). In setups where the DAC and player support DoP end to end, users may prefer to keep that delivery mechanism intact instead of having it converted into PCM earlier in the chain. Another example is maintaining strict gapless playback without relying on server side stitching or re-encoding strategies.
So the request is not based on the assumption that 32 bit float processing is inherently harmful. It is about giving users the option to bypass it when their hardware and use case allow for a simpler and more direct playback path.

[OzGav]

Thanks for the thoughtful reframe, but honestly this is asking MA to stop being MA. The unified 32-bit float PCM pipeline isn't an aesthetic choice we can toggle off with a flag — it's the substrate that every core feature sits on top of. Volume normalization, per-player DSP, crossfade and smart-fades, announcement mixing, multi-room sync, seek, and the unified queue all assume a canonical internal representation they can safely manipulate. F32 gives those features the headroom they need to chain gain and filter stages without accumulating audible error; 24-bit integer would drift under repeated processing and 16-bit would be obviously wrong. The conversion itself is mathematically lossless — a smaller integer placed into a larger floating-point container — and it's never what reaches the DAC: FFmpeg re-encodes to whatever the player protocol actually accepts (FLAC, raw PCM, etc.) before transport. The remaining transformations on the way out (PCM decode from the source codec, and sample-rate negotiation against the player's declared capabilities) aren't things a server can drop without either stopping being a server or breaking the player it's talking to.

A true "minimal processing mode" as described wouldn't be a small addition — it would be a parallel pipeline through the most load-bearing code in the project: source-codec passthrough branching before the PCM buffer (so FLAC/ALAC never round-trip through PCM), per-player sample-rate passthrough with no rate-clamping, per-protocol native-gapless negotiation to replace server-side stitching (different work for UPnP, SlimProto, AirPlay, Snapcast, Cast, Sonos), and — if DSD/DoP is in scope — an entirely separate non-PCM pipeline since DSD fundamentally isn't PCM. It also forces awkward policy decisions about features users expect to "just work": if bypass is engaged and the server isn't allowed to touch the stream, then announcements (doorbell TTS, alarms, Home Assistant notifications) have nowhere to be mixed in, volume normalization is off, and group sync across a mixed set of players — some in bypass, some not — becomes undefined. You end up either silently dropping those features when bypass is active or tearing bypass down every time one of them fires, neither of which is good UX. The concrete examples you raised are better served as their own narrow features (native gapless where the endpoint supports it, DSD support as a distinct effort) rather than bundled under a global bypass switch. And on the sonic side, you already acknowledged that F32 processing is "effectively transparent" and that the request "is not based on the assumption that 32 bit float processing is inherently harmful." The ABX literature backs that up. Given that, spending a core redesign's worth of effort, complexity, and ongoing maintenance burden on a mode whose own justification isn't audible improvement is a trade we don't think is worth making.

[tweakerrobin]

Thanks, this is a very clear explanation of the architectural trade-offs and it makes sense that a full bypass would effectively require a parallel pipeline. I agree that the current design is internally consistent and enables a strong feature set.
I think the key point from my side is not to challenge that foundation, but to explore where additional flexibility could exist without undermining it. There is a subset of users who explicitly value control over the playback path, even if that means giving up certain features in specific scenarios.
I do think there is value in looking at narrower, well-scoped opportunities where MA could expose more direct handling when the conditions allow it.
Allowing format preservation in specific cases (e.g. DSD over DoP) when both the source and player chain explicitly support it
Introducing per-player or per-session modes where advanced features are intentionally disabled in exchange for a simpler playback path
This would keep the core architecture intact, while giving advanced users a way to opt into different trade-offs depending on their setup.

[OzGav]

Appreciate the narrower framing. Taking them one at a time.

On DSD/DoP: this is a legitimate request but it's genuinely a new feature rather than a narrower scope of the bypass discussion. MA has no DSD plumbing today — no .dsf/.dff decode path, no DoP wrapping, and the majority of our player providers (SlimProto, AirPlay, Chromecast, Sonos, Snapcast) can't carry a DoP stream even if we produced one. Adding it means a parallel non-PCM path alongside the existing one, because DSD fundamentally isn't PCM and can't go through the PCM buffer. Happy to track it as its own standalone issue titled something like "DSD / DoP source and passthrough support" so demand can be gauged and we can see which player providers could realistically carry it, but I'd rather not conflate it with the general bypass discussion.

On per-player or per-session "reduced features" modes: worth pointing out that the features you'd want to disable for a simpler path — volume normalization, DSP, crossfade / smart-fades — are already per-player settings today. A user who wants a more direct path on a specific endpoint can turn those three off on that player right now, without any new mode. What a "reduced features" mode would remove beyond that is the PCM decode and the canonical internal buffer — and those aren't really features in the toggleable sense, they're the substrate the queue, seek, track transitions and announcement mixing are built on. So while the scope label is narrower, the implementation cost isn't: the expensive part is a parallel source-codec passthrough path before the PCM buffer, and that cost is the same whether the mode is global, per-player, or per-session. Combined with the earlier acknowledgement that F32 processing is effectively transparent, I doubt we would look to carry a second pipeline for a gain that isn't audible.