If your LiveReacting stream has no sound on YouTube, first find out whether the producer can hear the source and whether the silence affects one viewer or everyone. Those two checks help you locate the break: in a viewer’s playback, a shared browser tab, LiveReacting’s selected input, or the outgoing stream.
Work through the audio path in that order. Avoid changing unrelated video, network or channel settings until a test points to them; otherwise you can make the stream harder to diagnose without restoring sound.
Find out who cannot hear audio
Ask a viewer to describe exactly what they hear, and check the stream yourself on a separate device if possible. Does one person hear silence while others hear the programme? Do several people on the same network have the same problem, or do viewers in different places report it? Is the audio absent from the beginning, or did it stop after the stream had been running normally?
The pattern is evidence, not a verdict. One silent viewer makes local playback settings worth checking first. Several viewers reporting silence suggests you should inspect the source and broadcast path, but it does not prove that the fault is on the producer’s side. YouTube’s live-stream troubleshooting guidance also distinguishes reports from one viewer, multiple viewers on one network, and viewers on different networks.
Next, listen at the producer end. Can you hear the microphone, camera, music file or browser tab that is supposed to supply the sound? If LiveReacting or the encoder provides a way to monitor or preview the outgoing programme, does that sound contain audio? Keep the answers separate: a source can be audible locally while the published stream is silent, and a YouTube player can be muted even when the broadcast is healthy.
Make a short note of the source type and what each check shows. For example: “Chrome tab is audible locally; one viewer on a phone hears nothing; another viewer hears the stream.” That points to a different next step from “microphone is audible locally; all viewers hear silence.”
Check viewer playback and mute settings
If only one viewer reports silence, have them check the YouTube player’s volume and mute state first. They should also check the browser or device volume and the device’s sound settings. On a phone, for example, the player may be audible in principle while the phone’s media volume is turned down; a computer may be sending sound to headphones or another output the viewer is not listening to.
Ask the viewer to try another video or audio source on the same device. If that is also silent, the issue is unlikely to be specific to your LiveReacting broadcast. YouTube Help recommends checking browser or device volume, checking sound settings, and restarting the browser or device when YouTube sound does not work. Its no-sound troubleshooting steps are a sensible viewer-side checklist.
If other YouTube videos play normally, ask the viewer to reload the live page and check the player again. If convenient, have them try a second browser or device. These are comparison tests, not a reason to ask every viewer to change settings. If the second device has sound, continue investigating the first device’s playback path rather than rebuilding the broadcast.
Record whether the report comes from one person, multiple people on the same network, or viewers on separate networks. This distinction matters throughout the diagnosis. A message saying “the stream has no sound” may describe one muted phone, a shared browser-tab capture problem, or an outgoing stream issue; the symptom alone does not identify which.
Test whether the producer hears the source
Now listen to the original source on the producer’s side. If the programme uses a microphone, speak into it and check whether the expected monitoring or local preview responds. If it uses an audio file, play the file directly. If it uses music or a video in a browser tab, confirm that tab itself produces sound before you test sharing.
Keep this test as close to the source as possible. Do not infer that the microphone is working because its device name appears in a menu, or that a music file is silent because the YouTube stream is silent. The question is simply whether the intended sound exists and can be heard locally at the point it enters the production workflow.
If the source is silent locally, stay on the input side. Check that you are testing the intended device or file, and whether its own playback or mute state explains the result. If the source is audible locally, note that fact and move on to how LiveReacting captures it. Replacing a microphone or changing broad system settings before this distinction is made can add new variables.
A hardware change is only worth considering when evidence points to the input device itself: for example, the chosen microphone produces no sound when tested independently. LiveReacting’s feature description says its camera and audio-device feature supports internal or external cameras and audio devices, including microphones, and describes choosing the device from a dropdown. That does not establish that any particular device is faulty or that buying another microphone will fix a browser-tab or broadcast-routing problem.
Check shared browser-tab audio
If the missing sound comes from a browser tab, test the screen-sharing route rather than the microphone route. LiveReacting’s screen-sharing documentation says audio sharing is supported in Chrome and directs users to choose a Chrome Tab source, enable “Share Audio”, then select “Share”. Follow that documented route if you are sharing a tab that plays music, a video, or other browser audio.
Do not assume that sharing the whole screen or an application window captures sound in the same way. The documented audio-sharing path is specifically a Chrome tab with its audio-sharing option enabled. If you need sound from a tab, select the tab itself and make sure the share action includes audio. Then play a short, recognisable test sound and check whether the producer can hear it through the shared source.
If the tab is audible on the producer’s computer but not in the shared output, stop and repeat the sharing test carefully. Confirm which tab is selected, whether audio sharing was enabled before sharing, and whether you are using Chrome. Make one change at a time, then test again. This lets you tell whether the failure follows the source selection or is somewhere later in the path.
If you are sharing a screen or window for a reason other than tab audio, do not treat the absence of sound as proof that YouTube is dropping the broadcast audio. First compare with the documented Chrome-tab method. LiveReacting’s instructions are on its screen-sharing help page. They describe a particular sharing workflow; they do not establish that every browser, operating system or sharing mode behaves identically.
Verify LiveReacting’s selected input
For microphone or camera audio, check that LiveReacting is using the intended audio device. The device selected for a camera or audio source may not be the one you expect, especially if you have switched between a built-in microphone, a USB device or a camera with its own audio. Compare the selected input with the source you just tested locally.
LiveReacting’s feature post describes selecting a camera and audio device from dropdowns and notes that the feature was in beta when the post was published. Treat that as useful product guidance, not a guarantee that every current interface or device combination will look the same. If the selected input is wrong, choose the intended one and test again. If it is already correct, do not keep cycling through devices without a reason.
Check the source itself after selection. Speak or play a short test, and listen at the available preview or monitoring point before going live again if the workflow allows. If the input is audible at its source but not after selection, note the device name and the point where it disappears. If it is audible there but absent to viewers, continue to the outgoing path instead of repeatedly changing the input.
LiveReacting’s YouTube Live settings guidance also recommends an audio quality of 128k unless you know the destination supports higher-quality audio input. Check that setting when you have a reason to suspect an audio-quality compatibility problem, but do not treat it as a universal explanation for silence. A quality setting is not a substitute for confirming that the correct source is selected and reaching the output.
For a channel that runs continuously, write down the selected source and the result of each test before making a change. A clear record is useful if the issue returns: “USB microphone selected; local test audible; LiveReacting preview silent” is more actionable than “audio settings changed”. If the stream uses an always-on computer-based setup, the distinctions in this guide to running a 24/7 Telugu devotional stream with OBS can also help you describe which source and broadcast path you are using, without assuming that an OBS workflow is the same as LiveReacting.
Inspect the outgoing encoder path
If the source and selected input are audible, inspect the outgoing programme. YouTube recommends checking how the stream looks and sounds directly in the encoder. Listen to its preview or monitoring output if available, and check a local recording or archive if your setup creates one. These checks help separate a problem before the encoder from one that occurs as the stream is sent onward.
If the encoder preview or local recording is also silent, revisit the sources routed to the encoder and any reported encoder errors. YouTube’s guidance also points to CPU load as something to investigate when encoder output is not as expected. These are checks to make when the evidence points there; do not assume a busy computer or an encoder error just because a viewer reported silence.
If the encoder output sounds healthy but the YouTube playback is silent, the sound has made it through the local production checks. Investigate the outgoing connection and the published stream path next. Compare playback from more than one viewer and network, and check whether the silence is consistent. A single viewer’s device remains a plausible explanation if other viewers hear the stream.
When an outage interrupts a computer-based broadcast, audio and video may behave differently as the stream reconnects. If your diagnosis shows a dropped connection rather than a source issue, this reconnection checklist for an FFmpeg YouTube live loop covers that separate problem. It is not a fix for a muted player, an unshared Chrome tab, or an incorrectly selected audio input.
If you need to escalate, gather evidence before changing several things. Note the source type, selected device, browser and sharing mode if applicable, whether the source is audible locally, whether the encoder preview or local recording contains sound, and how many viewers are affected. Include whether those viewers are on one network or different networks. YouTube’s live-stream guide advises reporting persistent stream trouble to its team; a concise record of where sound stops makes that report more useful.
Retest with viewers
After a change, test the same path that failed. If you corrected a shared-tab selection, play a short clip in that tab and confirm that the shared output contains it. If you selected a different microphone, speak into it and check the monitoring point. If the encoder path was under investigation, verify its output and then ask viewers to check the published stream.
Ask at least one viewer who previously heard silence to reload and test again. If possible, compare a different device or network as well. Tell viewers exactly what you changed and ask whether they hear sound now; vague reports such as “it seems better” do not tell you whether the original symptom has gone away.
Keep a simple log with the time, source, change and result. For a 24/7 channel, this is especially useful if the sound disappears overnight or after a device is reconnected. A repeatable record can show that the problem follows one input, one sharing method or one reconnect event. It also prevents a later helper from undoing a working change because nobody remembers why it was made.
If the sound is still missing, return to the last confirmed point in the audio path. If the source is audible, but the LiveReacting preview is not, focus on the selected input or sharing method. If the preview and encoder output are audible but several viewers cannot hear the broadcast, investigate the outbound path and collect evidence for support. Avoid declaring the issue fixed until viewers can hear the published stream.
For the separate question of sending a looping video to YouTube continuously, this explanation of using a YouTube stream key for an always-on playlist covers the broadcast setup. A stream key or playlist arrangement does not by itself diagnose silent audio, so keep the audio checks above tied to the source, capture and outgoing path.
When a recurring issue is caused by needing to keep a local computer running for a file-based 24/7 broadcast, StreamNeo can remove that particular operating burden by running an uploaded video as a YouTube live stream while your computer is off; it will not diagnose a silent LiveReacting source or fix a viewer’s muted device.
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 is there no sound on my YouTube livestream?
The silence may be at the viewer’s playback device, in the source or capture route, or later in the outgoing stream. First ask whether the producer hears the source and whether one viewer or several are affected, then test the path where the sound appears to disappear.
How do I share YouTube tab audio in LiveReacting?
LiveReacting’s documented method is to use Chrome, choose a Chrome Tab source, enable “Share Audio”, and then click “Share”. Check that the tab itself plays sound and retest the shared output; a screen or application window is not the documented route for tab audio.
What if I can hear the source but viewers cannot?
Check whether the LiveReacting or encoder preview and any local recording contain sound. If they are silent, inspect the selected input, source routing and any encoder errors; if they sound healthy, compare reports from viewers on different devices or networks and investigate the outgoing path.
Should I change the audio quality setting?
Only test it when there is a reason to suspect an audio-quality compatibility issue. LiveReacting recommends 128k unless you know the destination supports higher-quality audio input, but that recommendation does not prove the setting caused silence.