Summary
StreamedAudioResult._transform_audio_buffer decodes streamed PCM16 bytes with np.frombuffer(..., dtype=np.int16), which uses the host native byte order. The voice pipeline receives PCM bytes, and the repository test helper pcm16_samples explicitly encodes those samples as little-endian (<i2). On a big-endian host, every non-symmetric sample is byte-swapped before it reaches the caller.
This was found while reviewing #4778; it is a separate, pre-existing issue and is not caused by that PR's dtype-spelling change.
Reproduction
For a provider byte stream containing two little-endian PCM16 samples:
raw = b"\x01\x02\x03\x04"
# The provider samples are [0x0201, 0x0403] == [513, 1027].
On a big-endian host, the current np.frombuffer(raw, dtype=np.int16) interpretation is [258, 772] (0x0102, 0x0304) instead. The same wrong samples are used for both np.int16 and np.float32 output.
Relevant implementation: src/agents/voice/result.py. The little-endian test encoding is in src/agents/voice/testing.py.
Expected behavior
Decode provider PCM16 as little-endian on every host, then return the existing native np.int16 or np.float32 output shape. Preserve the current cross-chunk sample-boundary and odd-byte padding behavior.
Root cause
Passing np.int16 to np.frombuffer requests native-endian decoding. The byte stream has a fixed provider encoding, so its byte order must be explicit.
Proposed fix and validation
Use an explicit little-endian i2 decode and normalize the resulting array to native np.int16, with a regression test that simulates a big-endian host and asserts the sample values. I will validate the focused voice tests and the repository's required format, lint, type-check, and test commands in a separate branch.
Summary
StreamedAudioResult._transform_audio_bufferdecodes streamed PCM16 bytes withnp.frombuffer(..., dtype=np.int16), which uses the host native byte order. The voice pipeline receives PCM bytes, and the repository test helperpcm16_samplesexplicitly encodes those samples as little-endian (<i2). On a big-endian host, every non-symmetric sample is byte-swapped before it reaches the caller.This was found while reviewing #4778; it is a separate, pre-existing issue and is not caused by that PR's dtype-spelling change.
Reproduction
For a provider byte stream containing two little-endian PCM16 samples:
On a big-endian host, the current
np.frombuffer(raw, dtype=np.int16)interpretation is[258, 772](0x0102,0x0304) instead. The same wrong samples are used for bothnp.int16andnp.float32output.Relevant implementation:
src/agents/voice/result.py. The little-endian test encoding is insrc/agents/voice/testing.py.Expected behavior
Decode provider PCM16 as little-endian on every host, then return the existing native
np.int16ornp.float32output shape. Preserve the current cross-chunk sample-boundary and odd-byte padding behavior.Root cause
Passing
np.int16tonp.frombufferrequests native-endian decoding. The byte stream has a fixed provider encoding, so its byte order must be explicit.Proposed fix and validation
Use an explicit little-endian
i2decode and normalize the resulting array to nativenp.int16, with a regression test that simulates a big-endian host and asserts the sample values. I will validate the focused voice tests and the repository's required format, lint, type-check, and test commands in a separate branch.