Audio Sample Rate Mismatch in Online Radio Streams

A radio stream sample rate mismatch occurs when the audio produced by the automation system does not match the format expected by the encoder, or when a later stage changes the sample rate before the audio reaches listeners. A typical path might involve 44.1 kHz output from playout, a 48 kHz encoder input, an encoded stream with its own declared format, and further conversion by the player or listening device. The audible result can resemble general streaming audio distortion, so avoid changing settings blindly. First establish whether the fault is genuinely sample-rate related or stems from another stage in the audio chain, then identify the first boundary at which the format changes. Record the format at each stage—automation output, encoder input and output, server endpoint and player—and compare those observations with the relevant guidance in the FAQ and the checks available from Monitor Your Streams.

Radio streaming setup with audio equipment and waveform monitoring

Introduction: identify the sample-rate problem before changing settings

What a sample rate is and why the mismatch matters

A radio stream sample rate mismatch means that different parts of the audio chain disagree about how many samples represent one second of sound. In online broadcasting, it is not enough for the stream to be reachable; each boundary must also use the same timing and format assumptions.

Files or live audio entering the automation system have a source audio rate. Playout software may then use an internal processing rate while mixing, resampling or applying processing. Before compression, the encoder accepts or uses its own encoder sample rate. The output stream carries audio frames with a format that is declared or implied by the encoded stream, while the listener’s device may perform a further conversion for its audio hardware.

A 44.1 kHz source, for instance, may be converted to 48 kHz inside the encoder. That is not automatically a fault: a defined and correctly implemented conversion can be transparent. The problem comes when one boundary assumes 44.1 kHz while the samples are treated as 48 kHz, or when conversion is applied inconsistently.

The connection may remain healthy even when listeners hear altered speed or pitch, clicks, timing irregularities or other streaming audio distortion. Unrelated faults can produce the same symptoms, so treat them as clues rather than proof. Diagnosis depends on comparing the declared and actual rate at each boundary.

Symptoms that point to a radio stream sample rate mismatch

A radio stream sample rate mismatch may occur at only one point in the broadcast chain, so the symptom alone seldom identifies the faulty component. Use the patterns below to determine where to compare the source, automation, encoder and public stream formats.

Audio plays at the wrong speed or pitch: this strongly suggests that audio labelled as 44.1 kHz is being interpreted as 48 kHz, or the reverse, at the automation or encoder boundary. It does not establish that the stream server is responsible, so confirm the rate at both the source and encoded output first.
Clicks appear immediately after a source change: an unsuitable hand-off between files, live input and the automation system is one possible cause, particularly when their sample rates differ. The symptom does not confirm a sample-rate fault; an abrupt edit, clock discontinuity or format change can produce a similar click.
Distortion affects only certain programmes or files: mixed source formats, or a conversion path that handles some inputs incorrectly, may be responsible. This is less consistent with a permanently incorrect encoder sample rate, which would normally affect everything. Check for clipping separately before changing the rates.
The problem starts after an encoder or automation change: compare the old and new input and output declarations, including 44.1 kHz and 48 kHz. A changed setting is a useful lead rather than proof, since gain, codec or channel configuration may also have changed.
Local monitoring sounds clean but the public stream does not: check the encoder output, stream server input and public endpoint in sequence. Local playback may bypass the faulty conversion boundary, while a listener’s player or connection can introduce separate faults.

Trace the complete audio path from playout to listener

Map every hand-off before changing settings. A typical chain runs from the automation or playout system through the audio driver or mixer, encoder, Icecast or Shoutcast server, reverse proxy or relay, public endpoint and player to the listener connection. A radio stream sample rate mismatch can be introduced at any of these boundaries and then carried through the rest of the chain.

Playout: note the source file or device sample rate, such as 44.1 kHz or 48 kHz, together with the channel layout.
Driver or mixer: check the active input and output rates and whether sample-rate conversion is applied. Do not assume that the device follows the file rate.
Encoder: document the input rate, channel configuration and declared encoder sample rate. Record the encoded format and the exact connection target as well.
Server: identify the mount or stream path and record the format received by the server. Icecast or Shoutcast can accept a live source while still relaying incorrectly timed audio.
Delivery: test any relay, proxy and the final public URL separately. Note redirects, response headers and the stream URL actually used by the player.
Playback: compare the result in a known player with the local encoder output. Record whether the audio is normal, silent, pitched or affected by streaming audio distortion.

Repeat the test with the local source, the server-side endpoint and the public endpoint. A running encoder or server process shows only that the process is active; it does not confirm that correctly timed audio reaches listeners.

44100 vs 48000 radio workflows: choose a deliberate reference rate

Neither 44.1 kHz nor 48 kHz is automatically the right choice for every station. Select one as the reference rate for the main production chain, then document where conversion occurs. That makes it less likely that a radio stream sample rate mismatch will remain hidden in a driver, mixer or encoder.

When 44.1 kHz is the natural reference

If the automation library is predominantly 44.1 kHz, the station may retain that rate through playout and into the encoder. This can avoid unnecessary conversion for music files, provided the sound card, virtual audio device and encoder all accept and preserve the same format. Check the actual device format rather than relying on the project setting alone.

When 48 kHz is the natural reference

Live production systems often use 48 kHz, particularly when the microphone feed, mixing desk, studio interface or programme inserts already operate at that rate. Set the automation or mixer path deliberately in this workflow instead of allowing each application to select its own format.

Mixed libraries are not, by themselves, a fault. The playout system may convert 44.1 kHz tracks to a 48 kHz programme bus, or convert them in the opposite direction. The important point is that the conversion takes place at a known boundary. Do not allow Windows, macOS, a virtual cable and the encoder to resample independently.

Record the reference rate at the automation output.
Check the sound-card and virtual-device rates.
Confirm the live microphone and programme-insert formats.
Set the encoder sample rate to match its actual input.

When the encoder reports one rate but its input device supplies another, correct that boundary first. The stream server generally carries the encoded result; it does not demonstrate that the upstream format was consistent.

How to diagnose a radio stream sample rate mismatch

A radio stream sample rate mismatch occurs when two connected stages make different assumptions about the audio clock, commonly 44.1 kHz versus 48 kHz. Work through the chain boundary by boundary, from playout output to public playback, to establish whether conversion is deliberate, misplaced or inconsistent.

Reproduce the fault. Note the exact source, time and listening route. Play a known-good item followed by the problem item without changing the station setup. If only one source fails, inspect that file or feed before changing the encoder.
Inspect the automation output. Confirm the actual sample rate and channel format being sent instead of relying on the library’s usual setting. A matching result at this boundary indicates that the next device or application is responsible if the fault remains.
Check the audio device or virtual mixer. Look for a fixed device rate, shared-mode conversion or a separate rate for each application. If automation sends 44.1 kHz while the device is fixed at 48 kHz, conversion is occurring here. That may be acceptable when intentional, but it identifies the stage to test and document.
Review the encoder input. Compare its selected input rate with the rate arriving from the device or mixer. Do not assume an encoder’s sample rate field describes the source; it may control a resampler or only the encoded output.
Review the encoder output and stream server. Record the encoder’s output rate and the format it announces to the server. Icecast or Shoutcast receives the encoder’s stream; it does not demonstrate that the original automation rate has passed through unchanged.
Inspect the public endpoint. Use a media-inspection tool capable of reporting decoded sample rate and channels. Compare its result with the encoder’s output and the server’s declared Icecast audio format. A mismatch at this point indicates conversion or altered headers between the encoder and public endpoint.
Compare playback paths. Test the public URL in two suitable players, then compare both with a local capture taken before encoding. If the local capture is clean but every public player shows the same issue, investigate the encoder-to-server boundary. Different results between players may indicate a problem with their interpretation rather than with the stream itself.

Check the encoder and Icecast audio format without guessing

At this boundary, a radio stream sample rate mismatch is usually identified by comparing the automation system’s output with the encoder’s expected input. Do not infer the setting from the station’s advertised format or simply because the encoder is connected.

Record the automation output. Check whether playout is supplying 44.1 kHz, 48 kHz or another rate, and note whether the output is PCM, a device feed or an already encoded source.
Review the encoder. Identify its input mode, sample rate or samplerate setting, channel format and any resampling option. Depending on its configuration, an encoder may accept a fixed input rate, follow the input device or convert the audio before encoding.
Compare the two sides. If automation supplies 44.1 kHz while the encoder assumes 48 kHz, select matching settings or enable one deliberate, documented conversion. Avoid enabling resampling at several stages without confirming which stage is active.
Confirm the encoded output. Where available, inspect the encoder’s status or diagnostic information and verify the output format against the documentation for that encoder version.

Icecast or Shoutcast generally distributes the encoded stream received from the source; the stream server is not normally where the automation audio is corrected. Check the relevant version’s official documentation for exact controls, and do not copy configuration directives from another encoder or release unless they are supported.

Check relays and proxies separately

When a relay or reverse proxy sits between the server and the public endpoint, test both URLs. Confirm that they expose the same encoded stream and format rather than a second source or conversion path. A difference between the direct and public endpoints identifies the relay or proxy boundary for further investigation.

Fix the mismatch at one controlled point

Once the failing boundary has been identified, correct the radio stream sample rate mismatch at one point rather than changing several components at once. If the automation output is 44.1 kHz and the encoder input is set to 48 kHz, decide first which rate the complete chain will use.

Choose one deliberate conversion stage

Align the automation output with the encoder sample rate when both applications support the same rate reliably.
Use one explicit resampling stage where the software documents that function. A 44.1 kHz-to-48 kHz conversion may be appropriate, but avoid enabling further conversions elsewhere without a reason.
Standardise live inputs and automated playout so that changing sources does not silently introduce a different rate.
Replace or bypass a faulty audio-device path if it reports, locks or converts the rate incorrectly.

Repeated conversion in the automation system, device, encoder and another intermediate process makes the fault harder to isolate. Different sources may also behave differently, even when the final stream appears to use one Icecast audio format.

Record the current settings before making changes. Then keep a short change log, make a test recording or monitoring session covering both live and automated audio, and confirm the result at the public endpoint. Retain the previous configuration and define a rollback step before restarting the encoder.

Verify the fix on the public stream

Test the corrected chain as a listener would, rather than relying solely on the studio computer. Confirm that the encoder remains connected and is receiving the intended source, then open the public stream endpoint directly in a suitable player. Check that playback continues beyond the initial connection.

Play the endpoint in two relevant players or on two devices, such as a desktop player and a mobile device. Compare the result with the encoder’s local output.
Switch deliberately between automation playback and the live input. Listen for changes in pitch, timing, clicks or other signs of streaming audio distortion as the source changes.
Allow a complete programme transition, including the handover into and out of live audio. The fix is not confirmed if it works with only one source.
Repeat the test after the stream has been running long enough to expose a reconnect or source-change problem.

An external connectivity check can show whether the public endpoint is reachable, while a silence monitor can indicate that it is connected but carrying no audible programme. These checks provide useful evidence of availability, and their event history may reveal recurrence. They do not identify the exact conversion boundary or replace waveform inspection and sample-rate analysis when the fault remains intermittent.

Prevention checklist for station engineers

To prevent a radio stream sample rate mismatch, record the station’s confirmed reference rate, such as 44.1 kHz or 48 kHz, and maintain it through the automation system and encoder. Check the documented format of every audio device in the signal path, including interfaces and operating-system inputs.

Set the automation output and encoder sample rate deliberately, rather than relying on an unspecified default.
Where conversion is necessary, resample at one defined boundary instead of allowing several components to convert independently.
Test song changes, adverts, scheduled items and live-source transitions at the chosen rate.
Record configuration changes, including software, driver and hardware updates.
Verify the public endpoint after updates, not just the local encoder output.
Repeat the check periodically and after any change to the automation, encoder, audio device or stream server.

Document the confirmed signal path from the automation output to listener playback, noting the format at each boundary. Keep a short, known-good test source at the reference rate so future checks can use the same material for comparison.