pcm, short for pulse-code modulation, represents audio as a sequence of sampled waveform values. linear pcm stores those values in evenly spaced steps without compression. the samples can travel as raw bytes or sit inside a file container such as wav, which carries information a player needs to interpret them.

how does pcm audio work?

a waveform's amplitude changes over time. pcm represents it with samples taken at regular intervals. the sample rate tells you how many samples belong to each second in each channel.

bit depth determines how many bits represent a sample. a signed 16-bit sample uses two bytes and can represent positive or negative amplitude values. mono audio has one channel, while stereo has two.

the receiving application needs to know how those bytes are arranged. for a multi-byte sample, byte order determines which byte comes first. reading little-endian data as big-endian changes the sample values and can turn speech into distorted sound.

raw pcm doesn't include a file header describing its sample rate, channels, or sample representation. those settings have to come from the api contract or other metadata. mdn's digital audio guide explains how samples and channels form the audio data.

linear pcm stores the waveform values directly. formats such as mp3 and opus encode audio differently and need a matching decoder before playback.

pcm audio example

for example, a language-learning app could stream a spoken exercise from rumik silk into its audio player. silk's default websocket output is raw 24 khz mono signed 16-bit little-endian pcm.

if the app groups that audio into 20-millisecond playback portions, each portion contains:

24,000 samples per second × 0.020 seconds = 480 samples
480 samples × 2 bytes × 1 channel = 960 bytes

24,000 samples per second × 0.020 seconds = 480 samples
480 samples × 2 bytes × 1 channel = 960 bytes

that's 960 bytes of audio for the app's chosen portion, excluding transport overhead. it doesn't imply that each websocket message arrives with exactly that size or duration.

the player needs the same format settings as the incoming data. treating those bytes as 8-bit samples or stereo channels would change how it reconstructs the waveform. supplying the correct sample rate also keeps playback at the intended speed.

pcm audio vs wav

pcm describes the audio representation. wav is a container that can hold audio along with a header describing it.

silk's default http response wraps its 24 khz mono signed 16-bit pcm in wav. omitting audio_format selects that response. explicitly requesting pcm returns raw audio bytes.

the distinction matters when passing audio between systems. a receiver expecting raw samples can't treat a wav header as part of the waveform. changing a filename from .wav to .pcm doesn't remove the header or change the audio representation.

why does pcm audio matter for voice agents?

with raw linear pcm, your app can put incoming samples into a playback buffer without first running a decompressor. it still needs to interpret and schedule those samples correctly.

the tradeoff is data volume. silk's 24 khz, 16-bit, mono pcm contains 48,000 audio bytes per second. a compressed format can reduce the amount sent over the network, but its decoder adds another step in the playback path.

the broader pcm family also includes companded encodings. mu-law represents samples differently from linear pcm, so an app must use the correct decoder for the bytes it receives.

choosing pcm doesn't change the voice model's pronunciation or expression. it determines how the resulting waveform reaches the application. an app processing waveform samples and a telephone gateway can require different outputs even when they use the same voice.