Audio Bitstream Passthrough
Audio bitstream passthrough sends a supported encoded audio presentation to another device for decoding.
A receiver can decode a movie soundtrack only if it receives a compatible encoded presentation. Bitstream passthrough arranges that delivery, leaving audio reconstruction to the downstream decoder rather than producing ordinary PCM in the player.
The server's Direct Play decision happens earlier. It can retain a file that the player either decodes locally or passes onward.
Encoded audio inside the transport framing
The player reads the selected track and its codec configuration. It then supplies the encoded audio using the output API and transport convention required for that format.
IEC 61937 defines transport of encoded audio in a digital-audio framework. Transport data includes framing and format identification so the receiver knows that it contains a coded payload to unpack, not ordinary amplitude samples to play directly.
A declared carrier rate or channel arrangement can consequently describe the transport, while the encoded content has its own audio rate and presentation. Microsoft's transport documentation explicitly distinguishes those fields.
| Boundary | What must happen |
|---|---|
| File to player | Find the correct coded track and configuration |
| Player to output API | Request the proper encoded format |
| Driver/link | Carry the required framing without treating it as normal mixed PCM |
| Intermediate device | Forward a compatible presentation where present |
| Receiver | Recognize, unpack, and decode that presentation |
This is why receiver capability alone cannot fix a player/output route that never supplied the encoded format.
Why normal sample processing changes the route
A volume multiplier acts on decoded sample amplitudes. Multiplying bytes in a compressed packet would instead alter coding symbols or headers, corrupting their meaning.
Likewise, mixing a notification into a soundtrack requires sample-domain combination or a specially supported codec-aware path. An ordinary PCM mixer cannot simply combine arbitrary encoded packets and expect a valid soundtrack.
A player may therefore disable some local effects during passthrough, choose PCM when processing is needed, or control downstream volume separately. Those are consequences of where the reconstruction happens, not inherently defects in the source.
Confirm the input before interpreting a listening mode
If a compatible receiver detects the intended encoded format, its decoder can reconstruct that presentation. It may afterward apply an upmixer, bass management, or other listening mode.
The processing-mode name and detected input answer different questions. A height-speaker mode on a conventional input is not the same observation as receiving the original immersive bitstream.
For an Emby immersive track, retaining the suitable encoded payload is one way to keep its spatial information available downstream. An object-aware decoded MAT path can perform a different supported route; ordinary channel PCM does not carry original objects just because it has many channels.
Use these distinctions to locate a failed boundary: did the player request the format, did the link forward it, and did the decoder accept it? That trace is more informative than changing unrelated codec or speaker settings together.
See Also
- Decoded PCM Output
- Dolby MAT Audio Transport
- The Audio Playback Path
- Preserving Immersive Audio Metadata