A Streamlabs alert sound that does not play may be a troublesome file, or it may be an alert configuration or audio-routing problem. First test the alert in Streamlabs; then follow the file path or the routing path according to what that test shows.
For Alert Box sounds, Streamlabs lists MP3, OGG and WAV as supported formats. Its sound-file article recommends trying OGG for a troublesome MP3, but changing the format alone cannot establish that an alert is configured, unmuted or routed to the place you are listening.
Check whether the problem is the file or the alert
Start by identifying what is supposed to make the sound. The format guidance below applies to audio attached to Streamlabs Alert Box events, such as a notification sound for a follow, subscription or donation. A missing game sound, music player or microphone is not an Alert Box file problem; it has a different capture path.
Run a test alert using the relevant Alert Box controls in Streamlabs. If the alert appears and its sound plays, the alert path can produce audio, and the issue may be limited to a particular uploaded sound or event setting. If the alert appears silently, do not assume that converting the file is the answer: check whether the alert sound is enabled, whether the test uses the event you changed, and where its audio is sent.
A useful comparison is another alert sound that you know has worked in the same setup. Keep the event and test conditions the same and change only the sound file. If one asset fails while another plays, investigate that file first. If both are silent, broaden the check to alert settings, mute state, monitoring and OBS routing. This is a diagnostic comparison, not proof of a specific underlying fault.
Also note where you expect to hear the test. You may hear an alert through a monitoring device, in a recording or stream output, or both. A silent headset does not by itself prove that the alert is absent from the broadcast mix; likewise, hearing it locally does not prove that it is included in the track sent to OBS or YouTube.
If you are building a channel from recorded material, keep alert assets separate from the video and music files used in the programme. This distinction is also useful when planning a pre-recorded video workflow for YouTube Live: the alert is an overlay event with its own audio settings, not simply another sound embedded in the uploaded programme.
Confirm the supported audio formats
Streamlabs' current Alert Box setup guide lists .mp3, .ogg and .wav as supported audio formats. Use one of those extensions for an Alert Box sound, but treat the extension as a starting check rather than a guarantee that every file with that name will play. The guide does not, in the material reviewed here, establish codec, sample-rate, bitrate, duration or file-size rules that you can use to diagnose a particular asset.
You can confirm the current list in Streamlabs' Alert Box setup guide. The guide concerns alert setup; it should not be read as a promise that any specific sound file will be audible in every configuration. A file can have a supported extension while still being corrupt, incompletely uploaded, or assigned to the wrong event.
Streamlabs' separate sound-file article recommends converting a troublesome MP3 to OGG as a workaround for compatibility issues with some streaming software. That advice is narrower than saying only OGG works: the current Alert Box guide names three supported types. The sound-file article was last updated on 17 December 2021, so use its OGG suggestion as a practical test, not as a replacement for current format guidance.
If the file already is OGG or WAV, there is no reason to convert it merely because an alert is silent. First check that the chosen event has that sound assigned and that you can hear the test through the expected path. Changing formats without isolating the problem can make troubleshooting less clear because it changes one variable without ruling out configuration issues.
Convert or re-upload a troublesome sound
Use conversion as a test for an individual troublesome file, especially when it is an MP3 that fails while another sound works in the same alert setup. Keep an untouched copy of the original. Convert a copy to OGG with an audio tool you trust, then upload that converted file to the same alert event. This lets you compare the result without losing the source or changing the alert at the same time.
Streamlabs' sound-file article says a newly uploaded file should be converted to OGG when the upload completes, and recommends OGG for sounds that do not work. Allow the upload process to finish before testing. If an upload is still processing, selecting the sound or testing immediately may not tell you whether the completed asset works.
After re-uploading, check the displayed sound selection for the event you mean to test. If there are several events with similar names, verify each one rather than assuming all alerts share a single sound setting. A new file can be uploaded successfully but remain unused if the event still points to its previous selection.
Do not treat conversion as a universal repair. The official documentation reviewed here does not define codec-level requirements for all files, nor does it say OGG fixes every failure. If the converted asset is still silent, move to the test and routing checks below. Avoid repeatedly converting the same file in different tools before checking whether other Streamlabs audio works.
For channels with spoken segments or recurring jingles, sensible file organisation makes it easier to tell which upload is being tested. A consistent naming scheme for an original and its converted copy can prevent you selecting an outdated version by mistake. If your programme includes many recorded tracks, this is the same practical concern covered in organising podcast files for an always-on stream; keep alert sounds easy to identify separately from programme audio.
Save settings and run a test alert
After changing a sound assignment or re-uploading a file, save the alert settings before testing. Then use the Alert Box test control or Streamlabs Desktop's test widgets, as appropriate for the setup. A test checks the configured alert path inside the software before you rely on it during a live broadcast.
Make the test useful by changing one thing at a time. For example, save a single new sound selection, run a test, and record what you observe: visual alert present or absent, sound present or absent, and which device or output you checked. Then move to another setting only if the first test has not answered the question. This simple sequence avoids confusing a stale setting with a failed file.
If there is no visual alert either, revisit the alert configuration and event selection before focusing on audio routing. If the visual alert appears but the sound does not, check the sound assignment and the audio controls. If you hear the test locally but not in a recording or stream output, the file itself is less likely to be the main issue than output routing or track selection.
A local test is not a substitute for checking the actual broadcast path. When practical, make a short private or otherwise controlled test recording and review it before using the alert in a public stream. This distinguishes what you hear in headphones from what the software is sending to the output. Do not infer that the sound is in the broadcast mix solely because it is audible in your room.
For a longer-running channel, a repeatable check matters more than a one-off success. A devotional channel that uses a brief bell at the start of a segment, for instance, can test that event after editing the alert rather than waiting for the next live occurrence. Keep a note of the event, selected sound and output checked, so a later change has a clear comparison point.
Check mute and monitoring settings
If the test alert is visible but inaudible, inspect mute state before changing the file again. Streamlabs' alerts troubleshooting guidance calls out the recent-events sound mute control and audio settings as relevant checks. Confirm that alert sounds have not been muted in the interface, and that the control you changed applies to the alert being tested rather than another source.
Next consider monitoring. A monitor device determines where you listen to audio locally; the selected device may differ from the desktop audio device or speakers you expect. Streamlabs' troubleshooting guide says to select both monitor and output when the monitoring device differs from desktop audio. Menu names can move between software versions, so look for the monitoring and output choices in the current audio settings rather than relying on an old screenshot.
Check whether the alert is being sent to an output at all, not only whether you can hear it. Monitoring and output are related but not identical: you can configure audio for local listening, for the mix being recorded or streamed, or for both. The right choice depends on your setup and whether you are using OBS alongside Streamlabs.
If other sounds are audible in the same device but the alert is not, return to that alert's sound assignment and mute state. If alerts and other desktop sounds are both missing, investigate the broader device or routing path. That distinction narrows the work: it is more useful than repeatedly replacing an asset that may already be valid.
Also consider whether duplicate alert sources or pop-out windows are playing the same event. Streamlabs' alert-echo guidance suggests closing extra pop-out windows and checking browser-source behaviour; if a source is misbehaving, removing and recreating it may help. These checks are more relevant when a sound repeats or echoes than when it never plays, but duplicate sources can make a test confusing.
Check track selection and OBS routing
When Streamlabs Desktop is used with OBS or an OBS-based workflow, check the path between the alert and the output. Streamlabs' alerts troubleshooting guide includes the alert's selected audio track and the “Route Audio to OBS” option. If the sound is heard locally but missing from the OBS mix, verify that routing is enabled where required and that the selected track is included in the output you are monitoring or recording.
Track names and interface wording can vary across versions. The principle is to trace the alert from its event setting, through its audio source and selected track, to the output that goes to the recording or stream. Compare that path with a source that already works. If a known-good source is on a track that reaches the output and the alert is on a different track, the mismatch is worth correcting and testing.
Do not assume that a track choice affects every destination identically. A track may be included in a recording but not the live output, or vice versa, depending on the software's output configuration. Check the output settings that apply to the place where the sound is missing, and run a new test after changing the route. A visible alert on screen says nothing by itself about which audio tracks contain its sound.
Desktop audio capture is a separate case from an uploaded Alert Box sound. Streamlabs' audio guidance says Windows can capture microphone and system audio directly, while macOS does not natively allow direct desktop-audio capture and requires a virtual audio driver for that desktop-capture use. This does not mean you need such a driver merely to use an uploaded Alert Box sound; apply the operating-system guidance only if the missing sound is system or desktop audio.
If your Alert Box test still fails after format, assignment, save, mute, monitoring and routing checks, the reviewed guidance does not establish one definitive cause. Gather the file type, affected event, test result, output device and relevant routing settings, then consult Streamlabs' alert troubleshooting guide or contact Streamlabs support. If you are also choosing a separate way to keep recorded programming on air continuously, that is a different operational decision from repairing an alert; see the comparison of always-on streaming software.
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
Which audio formats does Streamlabs support for Alert Box sounds?
Streamlabs' current Alert Box guide lists MP3, OGG and WAV. A supported extension does not guarantee that a particular asset is valid or audible, so test the alert after selecting it and check its audio path if it remains silent.
Should I convert every alert sound to OGG?
No. Streamlabs recommends OGG as a workaround for a troublesome MP3, while its Alert Box guide lists MP3, OGG and WAV as supported formats. Try conversion on the affected file as a diagnostic step rather than treating it as a universal fix.
Why is the alert visible but silent?
The event may have no sound assigned, the sound may be muted, monitoring may target a different device, or the alert may not reach the relevant OBS track or output. Test the alert and check those settings in sequence before deciding that the file itself is at fault.
Does macOS need a virtual audio driver for an uploaded alert sound?
The cited Streamlabs guidance about a virtual audio driver concerns capturing desktop or system audio on macOS, not simply playing an uploaded Alert Box file. If desktop audio is missing, follow the current operating-system capture guidance; for an alert file, check its assignment and routing separately.