If audio in your XSplit Broadcaster stream is out of sync, first check whether the mismatch is already present or grows as the stream runs, then find out whether it affects one source or all of them. Those two checks tell you whether to inspect a source-specific offset, a global audio setting, or the wider capture and output path.
Do not begin by changing several delays at once. Compare the actual output near the start and later in the run, make one relevant adjustment, and check the result again; XSplit documents different controls for global devices and individual sources, not one setting that fixes every cause of drift.
Work out whether it is an offset or accumulating drift
A fixed offset means the sound is early or late by roughly the same amount at the beginning and later. Accumulating drift means the relationship changes as the stream continues: a word may line up with a person’s mouth at first, then become noticeably early or late later on. These are different symptoms and should not be treated as interchangeable.
Check a recording of the outgoing programme, or another reliable capture of what viewers receive, at two or more points in a run. Choose moments with a clear visual and audio cue, such as a hand clap, a spoken syllable or a drum hit. Write down whether the sound leads or lags and whether the difference appears to increase. This is a practical comparison, not a test protocol prescribed by XSplit, and no particular amount of drift is normal for every setup.
A local recording is useful evidence, but first confirm that it represents the same sources and routing as the livestream. If the recording and stream both show the same changing mismatch, the issue may be present before or during encoding. If only one output shows it, note that difference rather than assuming the viewer’s connection is responsible. Compare the beginning and later portions instead of relying on a single moment or the stage preview alone.
| What you observe | What to investigate first | What not to assume |
|---|---|---|
| Same offset from beginning to later | The affected device’s capture delay or a single source’s Offset (ms) | That a delay is necessarily the cause of a changing problem |
| Mismatch grows during the run | Device compatibility, routing, output and recording evidence, system load, and version-specific behaviour | That adding a fixed offset will stop accumulation |
| Only one audio source is affected | That source’s device, route and source-specific offset | That every audio source needs a global delay |
| Several or all audio sources are affected | Global device configuration and the shared signal path | That one global setting must be the answer |
Keep a simple note of the observation, not just “audio bad”. For example: “camera audio was behind at the first check and further behind at the later check; microphone appeared steady.” A clear direction and comparison make it easier to choose the correct control and to reverse a change if it makes matters worse.
Find out whether one source or all audio is affected
Listen to each source separately where practical. Compare microphone, System Sound and camera or capture-card audio against their corresponding visual cues. If speech from a microphone is steady but the camera audio slips, a global delay applied to every device could damage the source that was already in sync. If all sources show the same relationship change, inspect what they share before editing each source independently.
XSplit’s Audio Device documentation describes an Offset (ms) control for correcting sync between camera sources and that particular audio device. The Camera/Capture Card documentation documents a separate offset for sync between that source’s camera video and audio. These separate controls matter: choose by the affected signal path, not by the fact that all of it eventually reaches the same broadcast.
Write down whether a source is routed as Stream Only or System Sound if those options appear in its properties, and record its current offset before changing it. Source and device names can be easy to confuse in a long-running scene. A label such as “desk microphone” or “camera HDMI audio” is more useful than “device 2” when you come back to investigate after an overnight run.
For a playlist channel, a mismatch may be inside the media or its playback path rather than a live microphone or camera. If you are building a continuous XSplit playlist, the separate guide to looping a playlist in XSplit Broadcaster can help with the playback setup; looping and audio synchronisation are still distinct problems. For a music channel, keep the source file and playback route in your notes, especially if only one track or one source behaves differently.
Inspect the selected audio device
Open XSplit’s audio settings and verify that the intended System Sound and Microphone inputs are selected. Check the connection path as well: a microphone or interface connected through a different USB port, a camera with embedded audio, and desktop audio captured from the system are not the same source. If the named device is absent, duplicated or unexpectedly changed, resolve that selection question before tuning timing.
Look at capture-delay values for the selected global devices and record what is there. A capture delay changes when XSplit takes in that device’s audio; it is not the same as delaying delivery to viewers. Avoid changing a delay just because the label sounds relevant. First establish that the device is the one affected and whether the sound leads or lags.
Check Audio Mixing Sample Rate against the device and the output or recording workflow you actually use. XSplit describes this control as useful for matching particular output sources and for legacy devices that cannot accommodate 48 kHz. That is a compatibility consideration, not evidence that choosing one rate will cure gradual drift in every setup. Do not switch it by guesswork; consult device requirements and compare the result using the same test points.
The XSplit Settings documentation describes the Audio tab as the place to choose captured devices and set audio capture delay, among other controls. It also covers settings such as preview and microphone mono mix. Keep the investigation narrow: a volume adjustment may make a source louder, but louder audio is not better synchronised audio.
Review Tools > Settings > Audio
In Broadcaster, open Tools > Settings > Audio and check the selected System Sound and Microphone, their capture-delay controls and the Audio Mixing Sample Rate. Interface details can differ by build, so if a field is not where an older guide suggests, check the documentation and release notes for your installed version instead of editing an unrelated output property.
Separate timing controls from encoding controls. Audio codec, bitrate and format affect how sound is encoded for output; they are not substitutes for a capture delay or a source offset. Likewise, audio preview is useful for monitoring what is being heard in the application, but the stage or preview is not proof that the outgoing recording and stream remain aligned throughout a long run.
Change only a setting that matches the symptom. If every captured input has the same fixed offset, a global device delay is a reasonable place to investigate. If only one input is affected, prefer its own control. If the offset grows, a static delay may shift the starting point while leaving the underlying change untouched. Keep the previous value in your notes so that you can return to it.
For a locally managed channel, record these settings alongside the machine and audio-device details you use to keep a continuous stream running. If the operational question is whether to keep a computer on for the broadcast or use a different operating approach, the comparison of a VPS and cloud streaming for a nonstop YouTube channel addresses that separate decision. It does not replace diagnosing the audio path in XSplit.
Check the source-specific offset when it applies
For an Audio Device source, open that source’s properties and inspect Offset (ms). Confirm its Audio Output route, such as Stream Only or System Sound, before changing the offset. If the audio is late relative to its paired picture, note the direction and make a small, measured adjustment in the appropriate direction; if it is early, the correction goes the other way. Do not copy a value from another source or a guide for a different device.
For a Camera/Capture Card source, inspect its own Offset (ms) and device configuration. That control addresses the relationship between the source’s camera video and audio. If the camera picture is synchronised with its embedded sound but a separate microphone is not, a camera-source adjustment is unlikely to be the right place to start. Identify which audio belongs to which picture before touching the offset.
After editing, test the source in the outgoing recording or stream, not just by looking at its property field. Repeat at an early and a later point if the original problem accumulated over time. If an offset improves the first cue but the later cue still moves, record that result: a fixed correction may have addressed an initial offset without addressing the cause of drift.
If you are troubleshooting an always-on music or devotional channel built from repeated media, do not assume every file has the same alignment. The article on making a 24/7 Gurbani live stream on YouTube covers a channel format and setup context; for this issue, test the actual source and route that XSplit sends rather than treating the channel format as a sync control.
Make one measured change and monitor the output
Before a change, save or note the existing value, which input it belongs to, and the observation that led you to it. Make one change, then repeat the same cue comparison. If you alter the global microphone delay, sample rate and camera offset together, you will not know which change helped or which one introduced a new mismatch.
For an accumulating problem, monitor beyond the opening minutes. Compare a local recording with the outgoing broadcast where possible, and note whether the difference grows, stays fixed or changes direction. No short test can establish how every 24/7 setup will behave overnight, and XSplit’s documentation does not promise a universal setting that prevents drift. The useful result is evidence from your own signal path over the period when the symptom occurs.
Also check output and system behaviour. XSplit says high CPU or GPU usage and network conditions can contribute to dropped frames or other output issues, and recommends checking system use and processing or encoding choices. A stage preview that appears uneven does not by itself establish that the livestream is uneven, because XSplit prioritises livestream or recording output over the stage preview. Dropped frames merit investigation, but they do not by themselves prove the cause of audio drift.
Record the installed XSplit version. The release notes document changes to audio-delay controls and fixes for delay-related issues in particular builds, including changes in 2024 and 2025. Those entries are reasons to check the notes matching your installation, not proof that your version caused the symptom. If the controls differ from an older tutorial, rely on current documentation for your build.
If the mismatch persists, give XSplit support a useful evidence set: the build number, audio device and connection path, audio mode, sample rate, relevant source offsets, whether a local recording shows the same issue, and a log archive. The Settings page describes system-information logging for troubleshooting. A concise record of what changes over time is more actionable than a list of settings changed without before-and-after observations.
For a 24/7 broadcast that depends on a computer staying on and an application remaining in its intended state, reducing the number of overnight tasks can address a different operational burden. StreamNeo removes the need to leave your computer running for a video-based YouTube broadcast, but it does not change XSplit source offsets or diagnose an existing XSplit capture path; resolve the sync issue in the setup that produced it.
Keep viewer delay separate from audio sync
XSplit’s Stream Delay is intended to add time before viewers receive the broadcast. It changes when the output arrives, not the timing relationship between a captured microphone, desktop sound, camera or media source. Do not use it as a substitute for a capture delay or a per-source Offset (ms) when diagnosing audio and picture alignment.
The XSplit Output Settings documentation describes output options, including Stream Delay. The delay you configure is not necessarily the exact delay each viewer experiences, because transport and transcoding also affect delivery. That is a viewer-latency question, distinct from whether a sound matches its picture in the recording or at the point XSplit captures it.
A useful separation is to ask two questions. First, does the recording itself show sound out of sync with its picture, and does that mismatch change over time? Second, are viewers receiving the whole broadcast later than expected? The first points toward capture, source, or output diagnosis; the second points toward delivery latency. Both can occur, but changing the delay for viewers does not establish or correct the cause of an input-level mismatch.
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
Should I add a global audio delay if the sound drifts over time?
Not as a first step. A global delay can address a fixed mismatch shared by the affected device, but it does not establish why a mismatch grows during a run. Compare early and later output, determine which inputs are affected, and investigate the relevant device and signal path before deciding whether a fixed adjustment is appropriate.
Which offset should I change for one camera’s audio?
If the camera and its audio are part of a Camera/Capture Card source, inspect that source’s Offset (ms) and device configuration. If the audio comes from a separate Audio Device source, inspect that source’s offset and route instead. Keep the adjustment scoped to the source whose picture and sound are mismatched.
Does Stream Delay fix lip-sync for viewers?
Stream Delay adds time before viewers receive the stream; it is not an audio-sync control. It does not correct a capture-level offset, and the configured delay is not necessarily the exact delivery delay each viewer experiences. Check the actual recording or output for A/V sync separately from viewer latency.
What should I send XSplit support if the issue continues?
Include your installed build, device and connection path, audio mode, sample rate, source offsets, and whether a local recording shows the same mismatch. Note whether the offset is present from the start or grows over time, and include a log archive if available. This evidence helps describe the behaviour without assuming a cause.