Bitstream audio sends the encoded audio track from the player to the AVR, processor, or soundbar for decoding. It is central to formats such as TrueHD, DTS-HD MA, Atmos, and DTS:X.
Bitstream is an output mode, not an audio format. When a player is set to bitstream, it passes the encoded audio track down the HDMI cable untouched and lets the receiving device do the decoding. The alternative is PCM, where the player decodes the track itself and sends finished, uncompressed audio instead.
The distinction only matters because of where it puts the decoder. Bitstream moves decoding to your AVR or processor. PCM keeps it in the player. Both can be correct — but only one preserves formats your AVR needs to receive intact.
| Behaviour | Bitstream | PCM |
|---|---|---|
| Decoding happens in | AVR, processor or soundbar | The player or media app |
| Carries object metadata | Yes — Atmos and DTS:X survive the trip | No — objects are already rendered to channels |
| AVR front panel shows | The format name, e.g. Dolby TrueHD | Multichannel PCM |
| Player-side mixing | Not possible — the stream is untouched | Possible, including secondary audio |
| Fails when | Any device in the path cannot carry the format | The player cannot decode the codec |
Dolby TrueHD and DTS-HD Master Audio are lossless carriers. Dolby Atmos and DTS:X add object metadata on top of them. That metadata is what allows a mix to place sound in three dimensions rather than assigning it to fixed channels.
When a player decodes to PCM, it renders those objects into a fixed channel layout first. The result can still sound good, but the spatial decisions have already been made by the player rather than by your processor, and the receiver will report multichannel PCM rather than the format name. If you want an AVR to apply its own object rendering to your speaker layout, the stream has to arrive still encoded — which means bitstream.
This is also why bitstream alone guarantees nothing. It preserves whatever the source contained. If the file only holds a lossy track, bitstream faithfully delivers a lossy track.
Audio returning from a television to an AVR is a common point where lossless formats can be lost or converted. Enhanced ARC (eARC), introduced with HDMI 2.1, was specified to support higher-bandwidth audio formats that legacy ARC commonly cannot transport — see the HDMI Forum's eARC specification overview.
A player connected directly to the AVR, with video passed onward to the display, avoids the return path entirely. A player connected to the television, relying on ARC to send audio back, is limited by whatever that return channel supports.
| What you observe | Where to look first |
|---|---|
| AVR reads multichannel PCM | Player is set to PCM output, or the app is decoding internally before handing audio over. |
| AVR reads a lossy format | The source track is lossy, or the return path has fallen back to what standard ARC can carry. |
| Format name appears, no height effect | The lossless carrier arrived but object metadata did not, or height channels are not configured in the AVR. |
| Audio drops on scene changes | Handshake or EDID negotiation between player, display and AVR rather than the audio format itself. |
| Server reports transcoding | The media server is re-encoding before the signal ever reaches the player. Nothing downstream can recover this. |
The only reliable evidence is what the receiving device reports, not what the player claims to be sending.
A correct format name on the receiver confirms delivery. It does not confirm that speaker levels, distances, crossovers or room correction are right, and it does not confirm the mix is being rendered to the layout you actually own. Delivery and performance are separate questions, and only the first one is visible on a front panel.
Related reading: how TrueHD, Atmos, DTS-HD MA and DTS:X relate to each other, what DTS:X requires from a chain, and why a media server transcodes instead of direct playing.
No. Bitstream is better when your AVR should be doing the decoding and the whole path can carry the format. If the return path cannot carry it, PCM from the player often delivers a better result than an encoded stream that falls back to a lossy format.
It confirms the format arrived intact, which rules out a large class of problems. It does not confirm the mix is being rendered to your speaker layout, or that levels, distances and crossovers are set correctly.
Something upstream decoded it first. The usual causes are a player set to PCM output, a media app decoding internally, or a server transcoding before the player ever receives the track.
No. Bitstream preserves whatever the source contains. If the track is lossy, it passes a lossy track through faithfully.