Why the donation alert is heard on stream but not in the recording

Stream and recording are two different outputs

The broadcast and the recording take audio from the same scene but route it along different paths. The stream usually gets the full mix or a single track, while the file gets whichever track you selected in the output settings. If the alert is audible on the live stream but not in the recording, the signal reaches the streaming encoder but doesn't reach the file's track. The widget itself is working: the image appears and the sound is sent to the mixer.

Below are the specific places in OBS, Streamlabs Desktop, and XSplit where this mismatch occurs.

OBS: the "Advanced" tab in output settings

Open "Settings" → "Output". Switch the output mode to "Advanced" — in simple mode you can't manage tracks. In advanced mode a "Recording" tab appears with a "Tracks" section: there's a list of tracks 1–6 with checkboxes. Tracks with checkmarks are written to the file. Below is the "Audio Track" field, where you choose which of the recorded tracks goes into the file container by default.

If only track 1 is checked and the alert's browser source is bound to track 2, the file will be silent where the alert should be. The stream, meanwhile, takes a different set — hence the mismatch.

How to bind a source to a track

1. In the "Audio Mixer", click the gear icon next to the source you need and select "Advanced Audio Properties".
2. In the window that opens, find the "Audio Mixer" section — it lists tracks 1–6 with checkboxes. Check the track where the alert sound should go.
3. Go back to "Settings" → "Output" → "Recording" and make sure that track is checked in the "Tracks" section.

The downside of track routing: with each new source you have to re-check which track it landed on. By default, new sources fall onto the first track, and that's easy to forget.

Browser source in OBS vs. a separate browser window

The capture method determines where the alert's audio goes, and this is the first thing to distinguish.

The "Browser" source inside OBS

If the alert widget is added as a "Browser" source (the "+" button in the "Sources" panel), it has its own audio setting. Open the source properties, the "Advanced" section: there are the "Disable audio when inactive" checkbox and the "Audio Device" field. If you don't need the widget's audio in the mixer, the "Disable audio" checkbox is checked. If you do need it, the source appears in the "Audio Mixer" as a separate strip, and that's the strip you bind to tracks via "Advanced Audio Properties".

Also check the "FPS control frequency" field and the "Refresh cache of current page" button in the source properties — sometimes after a widget update the audio in the source disappears until the page is reloaded.

A separate browser window plus capture

If the widget is open in a regular Chrome or Firefox window and a "Window Capture" or "Display Capture" source is added in OBS, then video and audio are taken along different paths. Window capture pulls the image, while the browser's audio goes into the system mix. In OBS it's picked up by a separate "Audio Output Capture" source (on Windows) — add it manually if it's missing. Without this source there will be no strip with the browser audio in the mixer, and there will be nothing to bind to the recording track.

The downside of this scheme: audio output capture grabs all system sound, including notifications and music players, and you can't filter out just the alert from it.

Streamlabs Desktop and XSplit: the same logic

In Streamlabs Desktop, open "Settings" → "Output", switch the mode to "Advanced", and find the "Recording Tracks" section — the checkbox mechanics are the same. Binding a source to a track is done via "Advanced Audio Properties" in the gear menu next to the source in the mixer. In XSplit, track management is under "Settings" → "Output" → "Audio", where a list of sources is set for each track.

One rule applies everywhere: the set of sources that viewers hear must also be checked for recording.

Troubleshooting: before the program or inside it

1. Start a recording and send yourself a test donation.
2. Watch the alert source's strip in the "Audio Mixer" when it fires: is the indicator moving?
3. It moves but the file is silent — the problem is in the output tracks.
4. It's silent — the audio isn't reaching the program: check the widget's output device and the source properties.
5. Open the file in another player to rule out a playback issue.

Test the audio on a real event with recording, not by the indicator in your headphones. Monitoring can be enabled separately from recording, and then you hear the alert while the file is written without it.

What else to check in the widget itself

In the donation service settings, audio is often enabled with a separate toggle, and the volume is set inside the widget. Make sure audio is enabled for real events, not just for the preview, and that the volume isn't at zero. In the OBS browser source properties, check that "Disable audio" isn't checked and the correct "Audio Device" is selected. After making changes in the widget, refresh the source's page cache — otherwise the changes won't be picked up.

The downside of the "one source for everything" approach: when you move the widget to another service or change the alert template, the track binding will have to be set up again.