mu-law, also written as μ-law, is a form of companded pcm used in telephone audio. in g.711 telephony, it encodes each sample in eight bits at 8,000 samples per second, producing 64 kilobits per second for one channel. it uses a nonlinear mapping to represent a range of speech amplitudes.

how does mu-law audio work?

mu-law uses companding: compression of the signal's amplitude range during encoding, followed by expansion during decoding. its mapping gives quieter samples finer spacing between representable values and louder samples wider spacing.

that lets an eight-bit encoded sample cover a wider amplitude range than an eight-bit linear sample with uniform steps. the conversion is lossy, so decoding doesn't recover every value from the original higher-resolution signal.

mu-law and a-law are the two companding forms associated with g.711. for the mono, 8 khz audio discussed here, the audio bitrate is:

8,000 samples per second × 8 bits = 64,000 bits per second

8,000 samples per second × 8 bits = 64,000 bits per second

that's 8,000 audio bytes per second before transport overhead. base64 encoding or network packet headers add to the data transmitted.

sample-rate conversion is a separate operation. converting 24 khz linear pcm to 8 khz mu-law involves both resampling and encoding. setting an 8000 label on the original bytes doesn't perform either conversion.

mu-law audio example

for example, an appointment-reminder app could use rumik silk to generate speech for a call carried by a bidirectional twilio media stream. the app could send a synthesis request with these fields:

{
  "model": "muga",
  "text": "[neutral] your appointment is on friday at three.",
  "audio_format": "mulaw"
}

{
  "model": "muga",
  "text": "[neutral] your appointment is on friday at three.",
  "audio_format": "mulaw"
}

silk's mulaw option returns raw 8 khz mono g.711 mu-law audio. the app receives the requested encoding directly, without converting silk's default wav response itself.

the app then packages and sends the audio according to the phone system's requirements.

mu-law vs linear pcm

mu-law belongs to the pcm family. the comparison below uses "linear pcm" for uncompressed samples with evenly spaced amplitude steps.

a-law also uses eight-bit samples at 8 khz in g.711, but its companding mapping differs. a receiver needs to know which law the audio uses. decoding a-law bytes as mu-law can distort the sound even when the sample rate matches.

silk offers both mulaw and alaw. choose the one specified by the receiving system, as described in the audio-format guide.

why does mu-law audio matter for voice agents?

a generated reply has to reach the caller in a format the call system accepts. a clean wav recording may sound right in a desktop player but still need conversion before a telephone interface can play it.

mu-law is useful when that interface expects g.711 mu-law audio. silk's output option lets an application request the required encoding as part of speech synthesis. the model's spoken wording and tone remain separate choices from the delivery format.

the main limit is the phone-audio path. an 8 khz signal carries a narrower frequency range than higher-rate speech audio. converting it back to a higher sample rate doesn't restore detail lost earlier in the chain.

listen to the reply over the phone connection, including names and dates that need to remain clear. a local preview of the original wav doesn't show whether the encoded reply plays correctly in the call.