If a live-stream alert sounds doubled or repeats with a short delay, use OBS Studio’s Audio Mixer to find which sources react when you trigger one test alert. Then check those sources for duplicate capture or a monitoring route that feeds audio back into OBS; the cause depends on your setup, so validate each change with a recording.
OBS Studio does not supply stream alerts itself. Third-party alert overlays are usually added to a scene as a Browser Source, so the useful starting point is to trace how that source’s sound travels through your mixer and into the stream.
Trigger a Test Alert and Watch the Audio Mixer
Start with one alert and watch the meters, rather than changing several audio settings at once. OBS’s guide to adding stream alerts explains that alerts are provided by third parties and embedded through a Browser Source. Find the alert source in the scene you are testing, and make sure its audio activity is visible in the Audio Mixer.
Trigger a test alert using the alert provider’s test control. Watch which mixer meters move, and note whether they move at the same time as the alert. This is a practical way to narrow down possible overlap; it is not a formal OBS echo test, and meter activity alone cannot tell you exactly what a listener hears.
For example, if the Browser Source meter moves and Desktop Audio moves in sync, the alert may be reaching OBS through both paths. If only the Browser Source meter moves, a duplicate capture route is less obvious, but monitoring or another source may still be involved. Write down what you see before changing anything. Then repeat the same test after each adjustment so you can tell whether that change helped.
Use the same active scene and alert each time. If you switch scenes between tests, the source layout may change too, making the comparison less useful. Keep other audio quiet where practical, so a game, music bed or microphone does not obscure the alert’s response in the mixer.
Identify Which Sources React
Treat the meters as clues about routes, not proof that a particular source is at fault. A source that reacts when an alert plays may be capturing the alert directly, receiving it through a device, or reacting to unrelated audio at the same moment. Look for a second source whose meter follows the alert closely, then inspect what that source represents.
The Browser Source is the first place to look because that is where the alert overlay enters the scene. Also check Desktop Audio, Audio Output Capture, application audio sources, and any scene-level capture sources that could include the computer’s playback. If the alert also plays through a browser or other application outside OBS, that application may be another route worth testing.
Keep a simple observation table while you work:
| Test observation | What it suggests | Next check |
|---|---|---|
| Browser Source meter moves alone | The alert is visibly active in its intended source | Record a short test; also review monitoring |
| Browser Source and Desktop Audio move together | The alert may be present in both a direct and a general output path | Check global Desktop Audio and captured playback devices |
| Browser Source and an Audio Output Capture meter move together | The same output may be captured in the scene and elsewhere | Compare the device selected in the source with Settings → Audio |
| A source moves but the alert is not heard in the recording | Meter movement may be unrelated or routed differently from stream output | Check source routing and make another controlled recording |
The table describes useful troubleshooting inferences, not guaranteed mappings. OBS’s Audio Mixer guide describes mixer and monitoring controls, but the exact route depends on the sources and devices you have set up.
Check for Duplicate Global or Scene Capture
Compare scene-level capture sources with global devices in Settings → Audio. OBS warns that an Audio Input/Output Capture source can cause echo if the same device is also selected under Settings → Audio. Its Audio Sources guide recommends disabling the global device when you capture that device directly in a scene.
In practice, choose one route for a device you do not need to capture twice. If you have added an Audio Output Capture source for a particular output, check whether that same output is also selected as global Desktop Audio. If both are active, disable one route, trigger the alert again, and watch whether the duplicate meter activity disappears. You can reverse the change if it removes audio you need.
Apply the same reasoning to microphones, while keeping the symptom in view. A microphone source would not usually be the direct source of an alert sound, but it can contribute if speakers or another playback route feed the alert into the microphone. Do not disable a microphone simply because its meter moves; first determine whether it is actually carrying the sound you hear doubled.
Global and scene-level routes are not interchangeable in every setup. A global device can make desktop sound available broadly, whereas a scene source can be controlled or removed with that scene. Keep the path that serves your stream and remove only the redundant one. If you maintain several scenes, review their sources as well as the global settings rather than assuming one scene’s layout applies to all of them.
Inspect Monitoring and Capture Routes
OBS monitoring lets you hear a source through a configured monitoring device. That local listening route is separate from the question of what is sent to the stream, but it can become relevant if its output is routed back into a device OBS captures. Check the alert source’s monitoring setting in Advanced Audio Properties, then check which device OBS uses for monitoring and whether that device is also being captured.
If the stream recording contains one alert but you hear two while monitoring locally, the monitoring path deserves attention. If the recording itself contains two, inspect the sources routed to the stream as well; a local monitor setting by itself does not establish why viewers would hear a duplicate. These are diagnostic distinctions, not a guaranteed way to map every symptom to one setting.
A useful test is to temporarily set the alert source so it is not monitored, without changing its stream output, and record another short test. If the recording remains clean but local listening changes, that helps separate the monitoring experience from the stream mix. If the duplicate remains in the recording, restore any listening setting you need and continue checking capture sources.
Be careful when changing the configured monitoring device. You may rely on it to hear alerts or other sources while working, and changing it can affect local listening without improving the stream output. Make one adjustment at a time, note the original setting, and use the recording—not just headphones—as the check on what the stream mix contains.
Disable Redundant Audio Paths
When your meter observations point to overlap, remove one route at a time. If a device is captured both globally and in a scene, disable one of those paths. If a monitored output appears to be looped back into a captured device, change either the monitoring route or the capture route so the sound does not return as a second input. Then repeat the same alert test.
On Windows, OBS documents Application Audio Capture for Windows 10 version 2004 or later and Windows 11. When using per-application capture sources, OBS advises disabling global Desktop Audio to avoid echo. Its Application Audio Capture guide also notes that Window Capture and Game Capture can include application audio beginning with OBS Studio 30.1. Those details describe documented Windows support, not identical behaviour on macOS or Linux; check the guide and your installed version before following that route.
A per-application source can be useful when you want to control an application separately from general desktop sound. A single global Desktop Audio path may be simpler if you want ordinary playback captured together. For alerts, the key question is whether the alert is already present in a browser source and then captured again through one of those broader routes. Choose the path that gives you the control you need without duplicating the same sound.
Do not add a virtual cable as a first response to an alert echo. OBS’s guide mentions VB-CABLE as a workaround for some Windows applications that do not work with Application Audio Capture; that is a limited application-capture case, not a general alert fix. If you need an application-specific workaround, follow the current OBS instructions for your platform and test the resulting routes rather than assuming a cable will remove duplication.
If alerts seem to repeat only after a scene switch or source refresh, check whether the alert Browser Source is present more than once across the active scene collection. You can also inspect its visibility and refresh properties, such as shutting it down when not visible or refreshing it when a scene becomes active. Treat these as secondary checks: the presence of those properties does not show that they are the cause or a general remedy for echo.
Record a Short Test
Once you have made a change, record a short test in OBS before going live. Include a quiet moment, one test alert and any background audio that is normally present in the scene. OBS’s Quick Start Guide encourages checking meters and testing settings before a live stream; a local recording gives you a way to inspect the resulting output without relying on the headphone monitoring path.
Listen to the recording on the device you normally use to check your stream. Does the alert sound once? Does it have a short repeat or a faint second copy under it? Does the sound remain clear when music or other scene audio is present? If the test is inconclusive, simplify the scene temporarily and repeat it, rather than changing several routes together.
Keep the test comparable: use the same alert, scene, playback level and source settings while checking one change. If a change removes the alert entirely, the route you disabled may have been the only one carrying it. Restore the sound and choose another route to test. The goal is not to make every meter motion disappear; it is to make the stream output contain the alert once, with the rest of your intended audio intact.
Listen Back Before Going Live
Listen for the difference between a doubled alert in the recording and an alert that you hear twice only through local monitoring. If the recording is clean but local listening is not, recheck the monitoring device and source monitoring mode. If the recording is doubled, return to the mixer observations and inspect the sources that feed the stream output. Avoid assuming a clean headphone preview means the recorded mix is clean, or the reverse.
Test again after any final scene or source change. An alert source may be visible in more than one scene, or its behaviour may change when it becomes visible or is refreshed. If you change a Browser Source property, verify that the alert still appears when needed and that the resulting audio remains single in the recording. OBS interface labels can vary by version, so confirm the current controls in the documentation for your installed release.
Write down the working arrangement in plain terms: which source carries the alert, whether general desktop audio is enabled, and whether the alert is monitored locally. That note helps if you later add a new scene or audio source and the symptom returns. If you move a 24/7 channel to a different computer or change its audio devices, treat that as a new routing setup and run the same controlled test again.
When a channel depends on an unattended playback file rather than a person managing OBS through the night, the operating question changes from audio routing to keeping the broadcast available. StreamNeo removes the need to leave your own computer running for a file-based, always-on YouTube stream; it does not change how you should test alert audio in OBS before a live setup.
If you are also planning how the channel runs continuously, this guide to cloud service versus a home PC for a 24/7 YouTube ambient stream compares the operating trade-offs. For a computer-based setup, our notes on finding the process behind a 24/7 stream that stops on an Indian VPS cover a different failure mode, not alert audio.
If a test alert repeats only after changing scenes, you may also find it useful to review how to organise a YouTube 24/7 schedule for videos with different aspect ratios, particularly when the scene layout varies between programme segments. For a separate broadcast interruption issue, see YouTube stream disconnections on a VPS in India; it is not a fix for duplicate alert capture.
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 are my stream alerts echoing?
In OBS Studio, a doubled alert can point to overlapping capture routes or a monitoring path that feeds audio back into a captured device. Trigger one test alert and watch which mixer meters react, then inspect those sources rather than assuming one cause explains every setup.
Why does my alert sound play twice in OBS?
Check whether the alert’s Browser Source and a broader capture source, such as Desktop Audio, are both carrying the sound. Also compare global audio settings with scene-level capture sources, and make a short recording to check the stream mix after each change.
Why do I hear two alerts but the recording has one?
That difference makes local monitoring worth checking, because monitoring is for listening through OBS’s configured device. Confirm the alert’s monitoring mode and whether that output is also captured; the recording helps distinguish the local listening route from the stream output.
Does this advice work the same way outside OBS Studio?
No. These steps describe an OBS Studio workflow and its documented audio sources and monitoring controls. Other streaming applications organise capture and monitoring differently, so use their own documentation and test their recorded output.