“Why does my YouTube radio livestream keep disconnecting from the audio source?” can describe a capture problem, a silent published stream, or a complete broadcast disconnect. Those are not necessarily the same fault: watch the encoder’s audio meter and make a local recording first, then follow the evidence towards capture and routing or towards the outbound connection.
Note exactly what stops: an input vanishes in the encoder, audio goes quiet while video continues, or the whole stream disconnects. A check in one setup cannot identify every cause, but comparing the encoder and local file with what viewers receive is a useful first separation.
First distinguish capture loss from stream disconnection
The phrase “audio source” can refer to the device or application feeding sound into the encoder. “Disconnecting” might mean that this input stops registering, that viewers hear silence while the encoder still runs, or that YouTube loses the whole broadcast. Each symptom calls for a different investigation.
Start while the problem is happening. Look at the encoder’s audio meter and note whether it moves with the programme. Make a local recording if the encoder allows it, then check the relevant part of the file. Separately note whether the video and broadcast stay live, whether the encoder reports a disconnect or dropped frames, and whether YouTube Live Control Room shows an error.
| What you observe | Where to investigate first | What it does not prove |
|---|---|---|
| The encoder meter stops and local recording is silent | Selected input, routing, playback or capture device | That the device itself is broken |
| Meter moves and local recording has audio, but viewers hear silence | Encoder output mix, stream status and YouTube-side evidence | That the network is the only possible cause |
| Local audio remains healthy while the entire stream disconnects | Encoder connection status and outbound network path | That the audio source caused the disconnect |
| Symptoms vary or evidence conflicts | Repeat the checks and compare timestamps | A single confirmed cause |
YouTube’s live-stream troubleshooting guidance asks creators to inspect encoder output, errors and the local archive, and directs attention to the outbound internet connection if the encoder output is healthy. Use it as a sequence of checks, not as a diagnosis before you have compared the evidence.
Keep a short note of the time, symptom and what each check showed. For a radio loop, also note what was playing when the fault occurred: a gap in source material can look like a dropped input, while a whole-stream disconnect may happen independently of the programme audio.
Watch the encoder audio meter
A meter shows whether the encoder is receiving level from the source it is measuring. It does not show exactly what a viewer hears after encoding and delivery, so combine it with the local file and stream status rather than treating a moving meter as proof that the public stream is healthy.
Watch the meter during normal playback and again when the reported failure occurs. If it remains active while the stream disconnects, the capture path may still be working. If it falls silent, check whether the source programme itself paused or ended before changing devices. A quiet passage, silence in a track, muted source or incorrect scene can all produce a still meter without demonstrating hardware failure.
If you use OBS, check the active scene as well as Settings → Audio. OBS can capture an input or output device at scene level, while global audio settings can capture devices too. If the same device is captured in both places, OBS warns that duplicate capture can cause echo. That is a reason to review routing, not to add more copies of the input.
Some workflows send music from a media player, a playlist tool or another application rather than from a microphone. Confirm that the encoder is measuring the intended playback device or application. A meter for a microphone will not tell you whether a separate desktop-audio source is reaching the broadcast. For a playlist-based programme, the guide to looping Tibetan singing-bowl audio with FFmpeg is relevant to playback continuity, but it does not replace checking the actual encoder input.
Make and inspect a local recording
A local recording lets you compare what the encoder is producing with what arrives on YouTube. If the recording has the same silence as the published stream, the problem is likely at or before the encoder’s output, though you still need to distinguish a source pause from a device or routing issue. If the file has continuous sound but viewers report silence or the whole broadcast drops, examine the outgoing stream path and status as well.
Record enough to include the lead-up, the failure and a little after it. Then listen at the matching time and inspect whether the file ends, continues silently, or contains audio throughout. If you only check a short sample before the fault, it cannot tell you what happened later in the night.
YouTube advises checking the local archive and encoder output, alongside encoder errors and CPU load. This is useful for overnight channels because the failure may be intermittent: a recording can preserve evidence that is no longer visible in the current meter or scene. Be mindful of storage, especially when recording long programmes, and test the recording process before relying on it.
A recording is evidence about the encoder’s local output, not a guarantee about the final viewer experience. If video continues and the local file has audio, but the published stream is silent, compare the encoder’s audio output configuration and YouTube’s stream health information before changing the source device. If the whole broadcast disconnected while the local file continued, the gap is more consistent with a transport or ingest interruption than with audio capture loss.
Check the selected source and device routing
When both meter and local file lose audio, verify the intended source before buying or replacing equipment. In OBS, make sure the source belongs to the scene currently live, and check its selected device. If using a scene-level Audio Input Capture or Audio Output Capture, review whether the same device is also enabled in global audio settings. Change one routing item at a time, then make another test recording.
For a hardware input such as an interface or mixer, check the device name in the operating system’s sound settings and see whether it remains available there during the failure. Note its connection type and whether reconnecting it restores the meter. If the device disappears from the operating system as well as the encoder, that is stronger evidence to investigate the device connection or system-level recognition, but it still does not on its own establish which component is faulty.
OBS documents platform-specific capture choices: its audio source guidance describes device capture on Windows and macOS, and points Linux users to ALSA or PulseAudio sources. Confirm that the source type matches your operating system and workflow. A guide for moving an OBS playlist stream without rebuilding its sources can help when a setup has recently moved machines; check each device selection on the new computer rather than assuming old routing carries over.
Check for simple changes around the failure: a restarted media player, a changed scene, an operating-system update, a device being unplugged, or a power-saving setting. These are things to investigate, not presumed causes. If a source is external, record the exact device name, operating system and connection type before seeking support. Only consider replacing an interface or input after tests point to the hardware or its connection; the evidence here does not justify treating every reported source disconnect as a device failure.
If local audio is healthy, inspect encoder status
If the meter and local recording stay healthy while the stream has trouble, look at encoder status and logs around the same time. Distinguish an audio-only complaint from a complete broadcast disconnect. Check whether the encoder reports dropped frames, an interrupted connection, an encoder error, or unusually high CPU load. Match timestamps to reports in YouTube Live Control Room where available.
Dropped frames or intermittent disconnects are evidence about the path between the computer and the remote ingest service, not evidence that the audio input disappeared. OBS’s connection troubleshooting guide discusses bitrate, network conditions, ingest selection and security or network software. Follow its checks in a controlled way so you can tell which change affected the symptom.
Do not rotate a stream key as a general remedy for silence or unstable networking. YouTube describes stream keys as credentials that tell the encoder where to send a feed and allow YouTube to accept it. A new key is relevant to particular encoder startup errors; it does not repair an input that stops feeding the encoder or a weak connection that interrupts an existing stream. See YouTube’s stream key guidance and act on that step only when the error matches.
If you change encoder settings, keep a note of the original values and test one adjustment at a time. For example, a lower video bitrate may help if evidence points to upload capacity, but it will not fix a missing audio source. Likewise, changing the stream’s keyframe interval is a separate encoder setting; the OBS keyframe interval guide for a low-end PC addresses that setting, not audio capture or network diagnosis.
Check outbound connection and YouTube stream health
If local audio continues but the stream drops, compare the encoder’s connection log with dropped-frame status and YouTube’s live health indicators. Check whether the problem coincides with a Wi-Fi interruption, router restart, VPN, firewall or antivirus event, or network-prioritisation software. This list is a set of possibilities to test, not a claim that any one is responsible.
Where symptoms point to unstable Wi-Fi, test with wired Ethernet if practical. A cable can help determine whether the wireless link is involved; it cannot make a missing audio device reappear in the encoder. You can also compare another network or ingest server if your encoder offers one, keeping the content and encoder configuration otherwise unchanged. A result that changes across networks is useful evidence, though it does not automatically identify the faulty component.
Compare the video bitrate with stable upload capacity, not a best-case speed test. OBS’s connection guidance offers 75% of total upload speed as a starting point for video bitrate, subject to stable capacity and the streaming service’s limits. It is a heuristic, not a guaranteed setting or a YouTube specification. Avoid adopting it as a fixed number without checking the actual connection and the platform’s current requirements.
If you suspect security software, a temporary controlled test may help, but restore protection afterwards. If the test points to interference, use the software’s supported exception settings rather than leaving protection disabled. OBS also recommends checking current network drivers from the computer or motherboard maker. Restarting a modem or router can help test general connectivity; replacing a router, cable, network card or other hardware is best left until checks isolate it. If the fault persists across local checks, contact your ISP with timestamps, logs, bitrate, connection type and whether another network changes the result.
For a continuous channel, the practical goal is to preserve enough evidence to separate a one-off interruption from a repeatable fault. A short log with the time, encoder status, local recording result, connection type and YouTube error is more useful to support teams than a general report that the radio “disconnected”. YouTube also asks creators with continuing live-stream issues to report the problem through its support route.
If an overnight broadcast depends on a computer staying awake and a local playback setup, that is a separate operational concern from diagnosing a source or network fault. StreamNeo turns an uploaded video into a YouTube live stream, which can remove the need to keep your own computer running for that file-based broadcast; it does not change the need to establish that your audio and programme are ready before going live.
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
Why does the encoder meter move when viewers say the stream is silent?
The meter shows level at the point being measured in the encoder, not necessarily the complete path through encoding and delivery. Check the local recording at the reported time, the encoder’s audio output configuration and YouTube’s stream status before replacing the input device.
Should I buy a new audio interface if the source keeps disconnecting?
Not on that symptom alone. First see whether the source disappears from the operating system, whether the encoder meter and local recording both fail, and whether a different connection or source changes the result. Consider replacement only when evidence points to the hardware or its connection.
Will changing my YouTube stream key fix audio that cuts out?
Usually that is not the right first check for audio capture loss or intermittent network trouble. YouTube’s key guidance concerns where the encoder sends the feed and startup errors; use a new key when the reported error matches that case.
What should I send to support if the stream keeps dropping?
Include the time of the failure, whether the encoder meter and local recording retained sound, the encoder’s errors or dropped-frame status, and your connection type. Add the relevant bitrate and whether the issue changes on another network, then share the matching logs with your ISP or report the continuing live-stream problem to YouTube.