Every LC3 payload of exactly nbytes bytes contains four parts. The key insight is that two independent write/read pointers are used — one starting from the front (byte 0) and one from the back (byte nbytes−1) — and they grow toward each other until the payload is fully packed.

The diagram below shows how the four regions fit within the nbytes payload. The two dynamic regions grow toward each other and must not overlap — if they would, the codec must truncate the spectrum or reduce residual data to fit.

The side information and signs/LSBs all use the same backward write pointer (bp_side, mask_side). The AC data uses a separate forward write pointer (bp). The residual occupies whatever gap remains between them after all other data is written — the encoder computes exactly how many residual bits will fit and writes that many.

The bidirectional layout is a clever solution to two competing requirements:

• Side information must be read first (the decoder needs Pbw, ggind, TNS flags, SNS data, etc. before it can decode the arithmetic stream), so it sits at the back where it can be read immediately without knowing the AC stream size.
• Arithmetic-coded spectral data is variable-length and grows from the front — the range coder naturally emits a forward-growing byte stream.
• Residual data fills whatever gap is left in the middle — the encoder doesn’t need to pre-compute its exact size before writing the other parts.

This layout is very efficient: every bit in the payload has a clear purpose, there is no padding, and the decoder can always parse the side information starting from byte nbytes−1 regardless of what is in the forward AC region.

LC3 supports changing the compressed frame size (nbytes) at any time — even frame by frame. This is called external rate adaptation because the rate change comes from outside the codec (from a Bluetooth audio profile or a link-layer rate controller), not from the codec’s own bit allocation algorithm.

The change is seamless — no teardown, no re-initialization, no gap in audio. The encoder simply starts using the new nbytes value from the current frame onward, and the decoder automatically determines the new bitrate from the received packet size:

Whenever nbytes changes, these variables are recomputed from nbits = 8 × nbytes:

The session parameters {fs, Nms, Nf, Nc} do NOT change during rate adaptation — those require a full session teardown and re-initialization. Only nbytes changes.

In Bluetooth LE Audio, the BAP profile supports Content Control and Codec_Specific_Configuration updates mid-stream via ASE (Audio Stream Endpoint) reconfiguration. The LC3 codec simply responds to the new SDU size without any internal state reset:

/* Rate adaptation: encoder side — just change the byte count argument */
/* Previous frame: nbytes = 100 (80 kbps at 48 kHz 10ms)              */
/* New frame: nbytes = 60 (48 kbps)                                    */
/* No re-init needed — just pass new nbytes to encode call             */

int old_nbytes = 100;
int new_nbytes = 60;   /* received from profile/BAP controller */

/* Encode with new rate starting this frame */
lc3_encode(encoder,
           LC3_PCM_FORMAT_S16,
           pcm_input,
           /* stride */ 1,
           new_nbytes,       /* ← new byte count */
           payload_out);

/* Decoder side: byte count is inferred from received packet size      */
/* The ISO socket tells you how many bytes arrived — that is nbytes    */
ssize_t received = recvmsg(iso_fd, &msg, 0);   /* = 60 bytes */
lc3_decode(decoder, payload_rx, (int)received, LC3_PCM_FORMAT_S16, pcm_out, 1);
/* lc3_decode uses received length as nbytes — rate change automatic  */