YouTube’s audioSampleRateMismatch warning means your primary and backup streams are using different audio sample rates. Set both paths to the same rate, then check the exact message in Live Control Room: a warning about the rate itself is distinct and may name a specific requirement.
In FFmpeg, -ar sets the encoded output audio rate. Check the rate actually sent to YouTube rather than relying on the source file’s properties, and make sure the primary and backup outputs agree.
What the audio sample-rate warning means
A sample rate describes how many audio samples are represented each second. It is expressed in hertz: 44.1 kHz means 44,100 samples per second, while 48 kHz means 48,000. For this warning, the important question is not which number is inherently best. It is whether the streams YouTube compares have matching rates and whether the message imposes a separate requirement.
YouTube’s Live Streaming API health-status documentation describes audioSampleRateMismatch as a difference between the primary and backup streams. Its instruction is to configure the streams to have the same audio sample rate. That is a relationship between two inputs, not a claim that one particular rate is universally required.
The API lists 44.1 kHz and 48 kHz as recommended rates for the separate audioSampleRate issue. YouTube Help’s example dashboard error, however, tells the creator to correct the rate to 44.1 kHz. These descriptions address different contexts. Do not assume that choosing 48 kHz will resolve a message that asks for 44.1 kHz, or that every mismatch warning means the rate itself is invalid.
For an always-on channel, this distinction matters when you have a backup encoder or failover path. A primary stream encoded at 48 kHz and a backup at 44.1 kHz can trigger a mismatch even if each path appears reasonable on its own. The fix is to align the paths, then confirm that the aligned rate satisfies any specific requirement shown for your stream.
If you are building a channel from recorded content, keep the whole signal path in mind: the media file, FFmpeg’s filters and encoder, and the stream sent to YouTube. The guide to setting up a prerecorded YouTube stream in India covers the wider workflow; this page focuses on diagnosing the audio-rate warning within it.
Read the exact YouTube message
Open YouTube Live Control Room and inspect the stream health details, not just a remembered warning or a general label. Record the issue name and the full wording. The exact text helps distinguish an unequal primary/backup pair from an individual rate that YouTube is flagging.
The API issue identifier audioSampleRateMismatch is specifically about primary and backup rates not matching. The separate audioSampleRate issue reports the current rate and provides recommended rates in the API health table. YouTube Help’s live-stream error list includes an example that asks the creator to correct the audio rate to 44.1 kHz. The wording and context should guide your next step.
You can read the YouTube Live Streaming API health-status reference for the issue descriptions and the YouTube Help list of live-streaming errors for dashboard examples. These official sources are useful together, but do not collapse their recommendations into a universal rule: one describes recommended rates in a health table, while the Help example gives a concrete correction for its particular message.
YouTube says the dashboard shows health messages with timestamps, and an unresolved message continues to appear. Use those timestamps as a practical check. If you change an encoder setting and the relevant warning appears again with a later timestamp, the fault may still be present or the new output may not yet be what you think it is.
Keep a note of which output you changed, when you applied it, and which message remains. This is particularly helpful if another person manages the backup stream or if the issue appears overnight. A short record prevents repeated changes to the primary path when the mismatch is actually on the standby path.
Check the primary and backup stream rates
A backup stream is not merely a copy of the main encoder’s intention. It is a separate stream, often produced by a second FFmpeg command, another encoder, or a different preset. Each can have its own sample-rate setting. Compare what each path actually encodes, not just what a setup document says it should encode.
Start by identifying the primary and backup outputs as YouTube receives them. For each path, inspect the FFmpeg command or encoder profile for the output audio rate. Check any audio filters too, because the filter chain and output options determine what is encoded. If you are using a pre-recorded file, its source rate may differ from the output rate; source metadata alone does not prove what the transmitted audio rate is.
If both commands are available, place their relevant audio output settings side by side. For example, if the primary command outputs at 44100 Hz and the backup at 48000 Hz, make a deliberate choice based on the Live Control Room message and configure both to that same choice. The example illustrates a mismatch; it does not mean either rate is right for every stream.
Also check whether the backup has really been configured. A channel can have a carefully tuned primary command and a default backup profile that was never revisited. If failover is infrequent, that inconsistency may only become visible during a health check or when the backup is activated. Do not wait for an outage to discover that the standby path differs.
If you operate several channels, keep separate notes for their primary and backup settings. Some channels may have a single encoder path; others may use a backup. The operational advice in this overview of scheduling multiple 24/7 YouTube channels is relevant when you need to keep configurations clear across channels, though it does not replace checking each stream’s health message.
Choose a rate that meets the applicable requirement
Choose using the message you actually have and the output you can verify. The API’s health table recommends 44.1 kHz and 48 kHz for audioSampleRate; the Help page’s example asks for 44.1 kHz. For audioSampleRateMismatch, the central requirement is that primary and backup use the same rate. The correct decision may therefore depend on which issue is present, not on a universal preference for one number.
| What you see | What it indicates | Practical response |
|---|---|---|
audioSampleRateMismatch |
Primary and backup rates differ | Configure both outputs at the same rate and verify each encoded output. |
audioSampleRate in the API health table |
YouTube is flagging the individual audio rate; 44.1 kHz and 48 kHz are listed as recommended | Check the message and output rate, then choose a recommended rate compatible with the stream configuration. |
| Help example says to correct the rate to 44.1 kHz | That example names 44.1 kHz as the correction | Follow the applicable wording shown for your stream and align the backup to the same rate. |
If Live Control Room asks for 44.1 kHz, use that rate for both primary and backup rather than changing only one side. If the message is only the mismatch issue and does not specify a rate, compare both paths and select one rate for both, taking the documented recommendations and your existing configuration into account. If you are unsure which message applies, consult the official references or check the current dashboard wording before changing a working path.
For a devotional or regional-language audio stream, changing the output sample rate is a technical encoding choice, not a content edit. It should not be confused with metadata, song selection or the quality of the source recording. For context on the latter, the article about regional-language song metadata on an Indian YouTube radio stream addresses presentation, while the sample-rate setting belongs in the audio output configuration.
Set FFmpeg’s output audio rate
FFmpeg documents -ar as an audio sampling-rate option. In an output command, an example is -ar 44100 or -ar 48000, placed among the output options before the output destination. Select the value that satisfies the applicable YouTube message and use it consistently for the primary and backup outputs.
A schematic example is:
ffmpeg -i input.mp4 -c:v copy -c:a aac -ar 44100 output
This illustrates where an output audio-rate option can appear; it is not a complete YouTube ingest command or a tested command for your input. Your stream may need different video and audio encoders, mapping, filters, format options and an output destination. FFmpeg’s codec documentation explains its audio sampling-rate option. Check the documentation for the FFmpeg version and output format you use if your command behaves differently.
Apply the same intended output rate to every path that can send a stream to YouTube. If primary and backup are separate commands, do not assume that adding -ar to one will affect the other. Edit each output configuration, and check for a later option or an audio filter that changes the rate. Where a profile or wrapper generates the FFmpeg command, update that configuration rather than making a change that will disappear when it restarts.
It is usually sensible to make one controlled change at a time. First make the rates match; then confirm the encoded output. If you simultaneously alter the codec, channels, bitrate, filters and video settings, a new warning or audio change is harder to trace. This page does not prescribe those other settings because the reported issue concerns sample rate.
For an always-on broadcast, repetitive manual restarts after a small encoding change can also become a maintenance task. StreamNeo is useful when the specific burden is keeping an uploaded video broadcasting without leaving your own computer on, while monitoring and restarting a dropped broadcast; the sample-rate setting still needs to meet YouTube’s message before the channel is left running.
Verify the output and recheck stream health
After changing -ar, verify the audio rate FFmpeg is actually encoding or sending. Do not treat the text in the command as proof: confirm you edited the active command, that the option belongs to the intended output, and that the command is not overridden by a profile or wrapper. Where the primary and backup paths are distinct, inspect both outputs independently.
Then check Live Control Room again while the stream is running. Look for the same issue identifier or rate instruction, and note its timestamp. A warning that remains with a new timestamp is a reason to keep investigating rather than assume the edit worked. Confirm that the dashboard is showing the current output and that both paths are configured alike before trying another rate.
If the warning clears, retain the final settings with the stream’s runbook. Include the output rate for each path and the applicable message that informed the choice. That small record is useful when you later replace an encoder, recreate a command, or bring a backup online after a long period of primary-only operation.
Do not infer that a clear sample-rate warning proves every aspect of stream health is satisfactory. It only resolves the issue being checked. If the channel also reports connection or video problems, investigate them separately rather than changing audio settings in response to an unrelated alert. For network-side planning, see the YouTube live-stream upload speed requirements by resolution, which addresses a different part of the broadcast path.
Common rate-mismatch checks
The source file is 44.1 kHz, but YouTube still warns. The file’s sample rate is not necessarily the output rate. FFmpeg can resample or encode audio at a different rate, and another part of the command may affect the output. Check the encoded output and the exact health issue rather than relying on the input file’s properties.
The primary rate is correct, but the mismatch remains. Check the backup path. A standby encoder with a different output option is a common configuration gap, particularly when it is maintained separately or rarely used. Compare both paths and align them rather than changing the primary alone.
Both commands show the same -ar value. Verify that these are the commands currently feeding YouTube, that the option is associated with the audio output, and that no generated profile, filter or later setting changes it. The rate reported by the encoded output is more useful than a copied configuration that may not be active.
You see a request for 44.1 kHz and a table listing 48 kHz. Those statements are not interchangeable. The API table gives recommended rates for its health issue, while the Help example uses 44.1 kHz in a particular dashboard error. Read your own message and follow its applicable instruction, keeping primary and backup aligned.
The issue returns after a restart. A restart may have loaded an older profile or a different command. Check what starts the broadcast, where its settings are stored, and whether primary and backup are launched from separate configurations. Save the corrected settings at the source so they persist through the next restart.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Does audioSampleRateMismatch mean I must use 44.1 kHz?
Not by itself. The API describes this warning as a difference between primary and backup rates and says to make them the same. YouTube Help’s example rate error names 44.1 kHz, so follow that if it is the message shown for your stream.
Is 48 kHz always the fix?
No. YouTube’s API health table lists both 44.1 kHz and 48 kHz as recommended for the individual audioSampleRate issue. A specific dashboard message may name 44.1 kHz, and a mismatch issue requires the primary and backup rates to agree.
Where should -ar go in an FFmpeg command?
Use it as an output audio-rate option before the output destination, such as -ar 44100. The command shown here is schematic; your input, filters and output format can require other options. Verify the actual encoded output.
Why check the backup if it is not currently active?
YouTube’s mismatch warning compares primary and backup stream rates, so the standby configuration matters even while the primary is live. Align and verify both paths before relying on the backup.