You're an hour into a video call, doing almost nothing. Listening, mostly. The other person is talking while you sit there, and yet your phone is warm enough that you've shifted it from one hand to the other without quite knowing why.
That warmth is not a bug or a battery quirk. It's the cost of decoding, and it's higher than almost anyone expects.
The job that looks easier is actually messier
When a phone encodes audio, compressing your voice into an AAC or Opus stream to send over the network, it starts with something clean and predictable: raw PCM audio, a straight river of samples at a known sample rate, typically 48 kHz. The encoder's job is to throw away information the human ear won't miss, using psychoacoustic models to decide what to discard. That process is complex, but it runs in one direction, on input the phone itself generated, at a pace it controls.
Decoding runs the other way. The terrain is rougher.
Incoming audio packets arrive over a network late, early, out of order, occasionally not at all. Before the decoder touches actual audio data, the processor is managing a jitter buffer: a small queue that holds incoming packets and smooths out the arrival chaos into something a decoder can consume at a steady rate. That buffer logic is constant, low-level work, running in parallel with everything else the chip is already doing.
Then the decoding itself starts. A codec like Opus uses range coding, a form of arithmetic entropy decoding, to reconstruct the signal. Entropy decoding is inherently sequential, like reading a mystery novel where each chapter only makes sense because you read the last one. Each symbol depends on the state left by the previous one, so the processor cannot pipeline or parallelize the work the way it can with most other tasks. It has to resolve step one before step two exists.
Modern chips are built around doing many things simultaneously. A strictly sequential dependency chain is exactly the workload that fights that architecture.
Encoding, by contrast, can look ahead. The encoder knows the input signal in advance, can analyze a window of samples, then decide. It has options. The decoder gets what it gets, one entropy-coded token at a time, reconstructing reality from a compressed description of it.
A scenario that makes this concrete
Imagine two people, Priya and James, running the same music streaming app on identical phones, same codec, same 256 kbps bitrate. Priya is the broadcaster, encoding a live set from her laptop through a USB interface. James is a listener decoding the same stream.
Priya's encoder is doing heavy psychoacoustic analysis, but it runs on predictable input with lookahead buffer available. Her chip's branch predictor handles it well. Cache hit rates stay high. Her phone runs warm.
James's phone is warmer. His decoder is chasing a live stream: reconstructing spectral coefficients, running inverse MDCT transforms, managing concealment for dropped packets (filling in plausible audio where data went missing, which is its own small compute job), and doing all of it under a hard real-time deadline. Miss the deadline and the audio glitches. No grace period.
Real-time constraints change everything. The chip cannot throttle down to save power the way it might on a background task, because the audio pipeline will stall and the user hears a dropout. So it runs at a clock speed sufficient to guarantee it finishes in time, which burns more power, which generates more heat.
What people assume, and why it's wrong
The common assumption is that creating something is harder than consuming it. That intuition works in most of life. It does not map onto digital signal processing.
Encoding is harder in the sense of making decisions. Decoding is harder in the sense of operating under constraints with imperfect input. Those are genuinely different kinds of hard, and the second one costs more processor cycles in practice, especially on a phone where the audio stack sits on top of an OS managing radio hardware, screen rendering, and background app activity all at once.
A subtler point that most write-ups skip: encoders on consumer devices often run slightly above real-time and bank the headroom. Decoders cannot bank anything. They are always spending.
So when your phone gets warm during a long listening session and some part of you thinks it shouldn't be working this hard, ask yourself what you actually mean by "just listening." The phone isn't playing audio. It's reconstructing it, packet by packet, against a clock that doesn't stop. Working hard is precisely the right description.