If your stream is not playing sound, check the file locally first, then follow the signal through its source, routing, encoder output and the viewer’s device. A file playing on your computer does not prove its audio is being sent to the stream.
If OBS shows audio but viewers hear silence, the mixer is only one checkpoint. The steps below use OBS Studio and YouTube Live as examples; other software and platforms may label controls differently or require different output settings.
Check that the sound file plays locally
Open the exact file you intend to stream in a normal media player. Listen through the beginning and a later part, rather than assuming that a thumbnail, file name or waveform means there is audible content. Check that your computer’s player is not muted and that its output device is one you can hear.
This first check separates a bad or silent file from a problem in the live path. If the file is silent locally, test another known-good audio file in the same player. If that plays, the original file may be empty, damaged, or encoded in a way that the player cannot decode. If neither plays, investigate the player, device or system output before changing stream settings.
When the sound is part of a video file, check whether the video contains more than one audio track. A recording might have a commentary track, a music track, or a track in another language. The player may default to a track that is silent or not the one you expect. Use its audio-track selector and listen to each relevant choice.
Also check the specific segment that goes quiet. A devotional playlist, lecture recording or long ambience file may contain an intentional pause, an opening without audio, or a quiet passage. Scrub to the section that viewers say is silent. For a loop, listen across the point where the file restarts, because a gap at the boundary is different from a file that never had sound.
Write down what you have established: which file, which track and which time position play audibly. That gives you a repeatable test for the next step. If local playback fails, fix or replace the source before rebuilding your live scene. If local playback works, leave the file unchanged while you check how the streaming application reads it.
Confirm the source and audio track
In the streaming application, confirm that the active scene or playlist actually contains the file you tested. A source can exist in a different scene, be hidden, be disabled, or point to an older copy in another folder. Check the source path and the scene that is currently being sent to the stream. If the file was moved or renamed, relink it rather than assuming the application has found the right version.
Choose a source type that can decode the media you are using. In OBS Studio, a Media Source is the direct way to add a media file. OBS Project documents MP3, AAC, OGG and WAV as supported audio types for that source. Its Media Sources guide also describes audio-track selection for media sources. Other applications may provide a media, file, playlist or browser source; check the documentation for the application you use rather than treating OBS labels as universal.
For a video with multiple audio tracks, select the intended track in the source properties, not only in the desktop media player. Choosing the right track in one application does not necessarily carry over to another. Restart playback after changing the selection and listen to the same passage you checked locally.
For extended media support or a playlist in OBS, the VLC Video source is another example. OBS says it uses VLC libraries and requires VLC to be installed; OBS running in 64-bit mode requires 64-bit VLC. If that source is present but cannot decode or play the file, check the dependency and architecture before assuming the audio track itself is defective.
If the source appears to play but remains silent, remove one uncertainty at a time. Try a short, known-good audio file as a temporary source in the same scene. If that works, the original file or its track selection remains suspect. If the test file is silent too, the cause is more likely in the scene, source configuration or downstream audio path. Do not leave test files in a live playlist by accident.
For a channel built around a repeating playlist, source selection and the hand-off between clips matter as much as the sound in each clip. The guide to avoiding audio gaps in a looping sleep-sounds stream covers the loop boundary; here, first establish whether the currently selected media source produces sound at all.
Check format and application compatibility
A file can play in one application and fail in another because decoders do not support every container, codec or track arrangement in the same way. If you have confirmed the source path and track, check the streaming application’s supported media formats. In OBS, the documented audio types for Media Source include MP3, AAC, OGG and WAV, but that is not a blanket guarantee for every codec variant, container or application version.
A practical compatibility test is to make a short copy or export in a format listed by your application, then load it as a temporary source. Keep the original unchanged. If the converted test plays while the original does not, the issue points towards decoding or media compatibility. If both fail, conversion is unlikely to address the routing or output problem, so continue tracing the signal instead of repeatedly changing file formats.
Avoid converting a library wholesale before a controlled test. Re-encoding may change the sound, remove track choices, or take time without fixing a mute or routing error. For a video with several tracks, make sure the export contains the intended one. For a single audio file, compare the test at the same playback position and volume so that you are not mistaking a quiet passage for a format failure.
If you are using a playlist feature, check whether the application treats audio-only files differently from video files, and whether it advances to the expected item. A source might decode one file but fail on the next because the playlist includes a different format. Test the problem item on its own. Once it works alone, restore the playlist and check the transition.
Keep platform-specific output requirements separate from file compatibility. A source that decodes in your application can still be sent in an audio format the destination does not accept. Conversely, a platform’s recommended stream format cannot repair a file that the source fails to read. Use the destination’s current documentation only after confirming the file reaches the encoder.
Verify routing, monitoring and mute controls
Check every mute point between the source and the output. A source may have its own mute control, the application mixer may have another, and an audio track or scene may have separate routing. Confirm that the source is included in the stream mix or output track you are sending. Interface names vary, so follow the signal path in your application’s own documentation.
In OBS Studio, start playback and look at the source in the Audio Mixer. Its meter and mute control are useful checkpoints, and the OBS Audio Mixer Guide explains monitoring controls as well. If the meter moves, audio has reached that mixer source. It does not, by itself, establish that the stream output includes that source or track.
Monitoring is a separate question from what viewers receive. The monitor control routes source playback to your configured monitoring device. If you cannot hear the source locally, check the selected device and monitoring configuration. A faulty headphone connection or a monitor output set to another device can make you think the source is silent when the stream mix is receiving it. The reverse is also possible: you may hear monitoring while the source is not routed to the stream output.
Use a simple signal trace. First listen to the file in a player. Then listen through the application’s monitoring path, if available. Next inspect the mixer meter and mute state. Finally, confirm which output or track is sent to the platform. Record each result rather than making several changes at once; otherwise you may lose the clue that identified the failure.
If your channel uses a mix of music, voice and effects, test one source at a time. Temporarily mute other sources and play the affected file. This makes it easier to spot a source that is routed to a different track, masked by another sound, or set to an unexpectedly low level. Restore the intended sources and routing when the test is finished.
Inspect levels in the streaming application
With playback running, inspect the source meter in the application. A meter that remains still suggests the source is not delivering audio to that mixer point, the wrong source is selected, or playback is paused. A meter that moves confirms activity there, but not necessarily at the encoder output. Follow it with a short recording or stream test before concluding that the audience can hear it.
Check for a mute state and for a fader set so low that the signal is effectively inaudible. Keep the test controlled: use the same short passage, change one control, then check again. If you move a fader while troubleshooting, note its starting position so you can restore your mix. Do not increase everything indiscriminately; a louder output can distort even when the original issue lies elsewhere.
Look at the meter during a known audible section, not during an intro or pause. A waveform with occasional peaks may not show continuous activity. If there is a voiceover or other source at the same time, temporarily isolate the media source to see which meter responds. Your aim is to identify whether the intended file reaches the mixer and whether the level is sensible, not to achieve a particular number on a meter.
For recurring channels, repeat the check after switching scenes or advancing the playlist. A source can be audible in one scene and absent from another. This is especially relevant if you alternate a holding scene, a music scene and a notice screen. The nonstop bhajan playlist OBS settings guide can help with the broader scene and playlist setup, but use your own application’s controls for any non-OBS workflow.
Separate encoder output from viewer playback
If the source meter moves, investigate whether the audio is actually included in the outgoing stream. Check the streaming application’s output-track assignment and encoder status, then check the destination’s stream-health information. A local monitor signal and a moving mixer meter are valuable, but neither alone proves that the platform is receiving a usable audio stream.
YouTube Live is one example of a destination with its own encoder guidance. Its live encoder settings page lists AAC or MP3 as audio codec options for RTMP/RTMPS and gives audio settings for particular channel configurations. It lists 44.1 kHz for stereo, 48 kHz for 5.1, and 128 Kbps for stereo audio. Treat these as YouTube-specific guidance, not universal requirements for every platform; verify the current settings in the destination documentation and dashboard.
If the outgoing stream has no audio or an unsupported audio stream, the destination may report a health warning. YouTube Help’s live-stream troubleshooting guidance recommends checking sound in the encoder and stream-health errors. Its troubleshooting distinguishes a problem in the encoder or source path from an issue with the outbound connection. Use the error shown by your own platform rather than guessing which setting applies.
If the encoder reports healthy output but viewers still hear nothing, check the stream on another browser or device and compare with the local file. This helps separate an all-viewer failure from a playback-specific issue. YouTube documents that stereo audio with poor mono compatibility can lose quality or become muted when converted to mono on mobile, and advises checking phase. That is a possible branch when the issue is device-specific, not a general explanation for every silent live stream.
A useful comparison is to ask another person to listen to the test from a different connection or device, without changing the live mix in the meantime. If one device plays the sound and another does not, investigate that playback path. If all tests are silent while the application meter moves, return to output routing and destination health. If the destination reports no incoming audio, return to the encoder output and track assignment.
Run a short private test before changing the live channel
When the file and mixer appear correct, make a short test using the destination’s private or unlisted option where available. Keep the test brief and use a clearly audible passage. Check the actual viewer playback, not just the encoder preview or your headphones. This verifies the final hand-off to the platform without changing the public channel’s ongoing programme.
Use a simple test record: file and track, source type, meter activity, selected output track, platform health message, and whether playback worked on another device. That record can make a later recurrence easier to diagnose, especially if you maintain a 24/7 stream and do not want to disturb a working scene to repeat earlier guesses.
Change one thing between tests. If you alter the track selection, codec and fader together, a successful result will not tell you which change mattered. Restore settings that were not part of the test. For a platform warning, follow its current official instructions and test the result again; do not assume a value recommended for one service will apply elsewhere.
If the stream is silent only after a disconnect or restart, verify that the source and output track resume as expected when the stream reconnects. The automatic restart troubleshooting guide addresses recovery after a disconnect; audio still needs its own check after the encoder returns. A picture coming back is not proof that sound has returned.
If you need a long-running file-based channel but do not want your own computer left on to keep sending the programme, StreamNeo can remove that particular burden by running an uploaded video as a YouTube live stream while you are away from the computer. It does not remove the need to prepare an audible file, select the correct track and confirm the resulting stream with a test.
When you can identify the stage where sound disappears, keep the diagnosis narrow: repair the file if local playback fails, correct the source or track if decoding fails, fix routing if the mixer or output misses it, and follow the destination’s current guidance if ingest reports an audio issue.
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 my stream not playing sound?
Start by playing the exact file locally, then check the source and track, mixer activity, output routing and destination health. Each checkpoint narrows the cause; no single setting fixes every silent stream.
OBS shows audio but my stream is silent. What should I check?
A moving OBS mixer meter shows audio has reached that mixer source, not that it is assigned to the outgoing stream. Check mute controls, output-track routing and YouTube or your destination’s stream-health information, then verify with a short viewer test.
Why can I hear the sound in my headphones but viewers cannot?
Your headphones may be receiving the application’s monitor path while the stream uses a separate output route. Check which source and track are sent to the encoder, and listen to an actual test stream from another device.
Why does sound work on my computer but not on a phone?
Compare the stream on another browser or device and check whether the problem occurs only on mobile. YouTube notes that stereo audio with poor mono compatibility can be affected when converted to mono on mobile; treat phase as one possibility for that symptom, not a universal cause.