A fixed audio delay stays roughly the same from the start of a stream to later on; drift grows as the session runs. Work out which pattern you have, then compare monitoring, OBS output, a local recording and YouTube playback before changing a sync setting.
For a lofi channel, use the same clear beat and visible animation change as a reference near the beginning and later in the session. Note when the mismatch appears and where you hear or see it. An offset can address a stable timing relationship, but it cannot by itself explain why a gap keeps growing.
Distinguish a fixed delay from growing drift
Choose a recognisable event that has both an audio and a visual cue. A strong beat aligned with a change in a waveform animation, a scene transition, or a deliberately added test marker can work. Compare that event near the start with the same event later. If the separation is much the same, you are probably investigating a fixed offset. If the separation increases, you are investigating drift.
Keep the conditions consistent: use the same content, scene, devices and playback route for each comparison. Write down when you started, when you checked, and which output you checked. “It sounds late” does not identify whether the issue is present in your headphones, OBS's programme output, the recorded file, or YouTube's playback.
A sync offset is useful when a source has a repeatable timing difference from the video in a particular output. It is not a universal correction. Copying an offset from a forum post or another channel can make your own output worse, and repeatedly adjusting it will not resolve a delay that continues to accumulate. First identify where and how the separation changes.
This distinction matters especially for lofi streams, where music may play continuously while a visual loop repeats. A transition in the image can look like a timing fault even when the audio track itself is steady. Use an event you can locate in both tracks, and compare the same occurrence in a local recording and the relevant YouTube playback rather than relying on memory.
Compare monitoring, programme output and recordings
OBS monitoring is not the same thing as the audio sent to your stream. You may listen through a selected monitoring device while OBS also mixes audio into the programme output. Those paths can behave differently. A delay heard in your headphones does not, on its own, prove that viewers hear the same delay.
Make a local recording during a session that reproduces the symptom. Compare it with what you hear in monitoring and with the stream output. If the recording and stream appear aligned but monitoring gets progressively later, investigate the monitor device and its routing. If the local recording itself drifts, look earlier in the source and OBS audio path. If the recording is in sync but YouTube playback is not, preserve both examples and investigate the platform path instead of changing a local setting blindly.
An OBS forum discussion includes a report where the monitoring device accumulated delay while the participant described the stream and recording differently. That is evidence that output paths can differ, not a guarantee about OBS or every setup. The OBS Project forum discussion may help you recognise the kind of distinction to test, but do not assume the same explanation applies to your devices.
Use a small comparison record so you do not lose track of what you observed:
| Where you check | What to note | What a difference may point towards |
|---|---|---|
| OBS monitoring | Whether the delay is fixed or grows in the monitor device | Monitoring route, device timing or buffering |
| OBS programme output | Whether the scene's audio and image match before streaming | Source timing or the OBS mix |
| Local recording | Whether the saved file starts and ends in sync | Local source, mix, recording or workload path |
| YouTube preview | Whether the live output matches the local comparison | Live output or playback path; verify with another check |
| YouTube VOD | Whether the saved stream matches the live preview and recording | A difference specific to the VOD or its playback |
These are clues, not diagnoses. Record what is different and what is the same; do not jump from a single mismatch to a cause. For a channel built around continuous music and a looped image, the guide to creating a sleep-sounds live stream on YouTube offers a useful content context: make sure the test cue is easy to recognise even when the scene is intentionally quiet and repetitive.
Check YouTube preview and VOD separately
A live preview and a saved VOD are separate checks. First compare OBS's local recording with the YouTube live output while the issue is occurring. Later, review the corresponding VOD section and compare the same event again. Note whether the mismatch is present in both, only in live playback, or only in the saved playback. Do not treat one result as a substitute for the others.
Playback conditions can complicate comparisons. Allow the stream and recording to settle at the event you want to compare, and use the same section rather than comparing a live moment with an unrelated point in a file. If you monitor YouTube on a different device, remember that device and playback path become another variable. Preserve the recording and note the time in the stream so you can repeat the check.
YouTube's upload recommendations for audio and video files discuss track duration and sample rates for uploads. That page is useful background when checking a file, but it is not a diagnosis or a live OBS repair guide. Do not read its upload guidance as proof that changing a live stream setting will cure your symptom.
If your recording is aligned and the YouTube playback differs, keep the local file and the stream/VOD example. Check whether both live preview and VOD show the same issue before changing OBS. The difference narrows the investigation to a later point in the path, but does not by itself establish whether the cause is encoding, delivery or playback. If the local file is already drifting, begin with sources, devices and OBS rather than attributing the mismatch to YouTube.
Map the timing path
List the path from each sound to the viewer. For a simple lofi setup, that may be a music player, an OBS audio source, the programme mix, a local recording, and the live stream. A microphone for introductions, capture-device audio, virtual routing, or a separate monitoring output adds more points to check. Write down which device provides each source and where you listen to it.
Pay particular attention to independent audio devices. A USB interface, a motherboard output and a monitor's audio output may not share the same timing reference. This is a reasonable area to investigate if the mismatch grows, but it is not proof that separate clocks are the cause. Confirm it by testing a simpler route or by comparing the affected outputs while keeping other conditions unchanged.
Check the OBS audio sample-rate setting against the settings for the devices involved. Inconsistent settings are a useful clue to investigate, not a guaranteed explanation. Avoid changing all rates or replacing equipment in one go: you would not know which change mattered, and might introduce a new mismatch. Note the current settings first, then test one deliberate adjustment at a time.
If you are considering simplifying several independent sources, first establish that they are part of the affected path. Consolidating sources through one audio interface may be a practical test for a setup that currently relies on separate devices, but it is not a first purchase for every case. Check compatibility with your existing devices and routing before buying anything. For more context about continuous music setups, the article on running a YouTube radio livestream without video can help you think about what the channel actually needs to send, while the sync investigation still depends on your own signal path.
Review sources and encoder behaviour
Inspect each source that contributes audio: music playback, a microphone, capture audio and any virtual device. Confirm whether a source is being captured once or routed through more than one path. A duplicated source can sound like an echo or a fixed separation; it is worth checking, but do not label it the cause of growing drift without evidence. Mute or bypass one source at a time in a controlled test and observe the same reference event.
Review OBS performance indicators and logs around the time the symptom appears. If the system is under heavy load, workload may be relevant, particularly if the problem emerges only after the session has run for a while. Check what OBS reports rather than inferring performance trouble from the audio alone. Similarly, OBS describes dropped frames as a connection instability or bitrate-capacity issue in its official connection troubleshooting guide. A dropped-frame counter points to a delivery issue to investigate; it does not establish the cause of audio drift.
Keep delivery trouble and timing trouble distinct. If the stream loses frames while a local recording stays aligned, that is a different clue from both the recording and stream gradually separating. You can investigate each issue, but do not assume that changing bitrate will correct an audio clock mismatch, or that an audio offset will fix a weak connection.
If a device or driver change becomes necessary, retest after restarting OBS so you know the application is using the intended device configuration. Keep the same scene and source list for the comparison. The checklist for YouTube Live bitrate by resolution and frame rate may help when stream delivery settings are actually in question, but bitrate is not a substitute for locating where audio timing diverges.
Make one change at a time
Before changing anything, save or note the present settings and capture a short baseline, followed by a longer reproduction if the problem takes time to appear. A useful test record includes the OBS version, operating system, audio devices, sample-rate settings, routing and monitoring choices, plus the point at which drift becomes noticeable. Without those details, a specific root cause cannot be established from the symptom alone.
Match the change to the evidence. For a repeatable fixed offset in one source and output, adjust that source's sync offset and check the same output again. Use a value established by your own comparison, not a number taken from another setup. For growing drift, investigate device timing, sample rates, routing and workload before trying offsets; an offset may shift the starting relationship while leaving the growing difference untouched.
If monitoring alone is affected, test the monitor device or route while preserving the programme mix. If a local recording drifts too, simplify the audio path and inspect the sources and device settings. If only YouTube differs, keep a copy of the aligned local recording and investigate the live or VOD path. Change one major variable, then repeat the same comparison. If several settings change together, a better result will not tell you which one helped.
A historical OBS issue describes a report from a particular Windows setup and OBS version where a sync offset appeared differently in programme view and recording/stream output until the value was re-entered after streaming began. It is a reminder to verify the intended output and software version, not evidence that current OBS versions share that behaviour. If a setting seems ineffective, confirm where it applies in your version and test the saved output rather than assuming the preview tells the whole story.
If the practical problem is keeping a long-running channel live while your own computer cannot remain available, StreamNeo removes the need to leave that computer running, but it does not diagnose a sync fault for you: establish that the uploaded file and channel are ready, then check the resulting YouTube output as you would any other path.
Verify over a long session
A brief test can reveal a fixed offset, but it may not reproduce drift that develops later. Repeat the conditions that first exposed the issue: the same content, sources, monitoring arrangement and representative scene, for long enough to check both an early and a later event. Do not declare success because the first minutes look aligned.
Review the local recording and the actual YouTube output. Check the live preview during the test, then the VOD afterwards, and note where each begins to differ. If one output remains in sync while another does not, keep that distinction in your notes. After changing a device or driver, restart OBS and repeat the comparison so the test reflects the configuration you intend to use.
Keep a short log for each trial: what changed, when you changed it, where you checked, and whether the gap stayed stable or grew. If the result is ambiguous, return to the saved baseline and test a narrower change. This is more reliable than stacking offsets, replacing devices and adjusting delivery settings without knowing which part of the chain is involved.
There is no setup-independent offset or single component that can be named as the cause from the symptom alone. To get a useful diagnosis, collect your OBS version, operating system, device and sample-rate details, routing choices, and comparisons between monitoring, a local recording, YouTube live preview and VOD. That evidence points to the next test; it does not guarantee a particular repair.
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
What is the difference between audio delay and audio drift?
A delay is a separation that stays roughly constant when you compare the same kind of event. Drift is a separation that increases as a session runs. Make that comparison before choosing an offset or investigating device timing.
Should I add a sync offset to fix drift?
Only use an offset when your comparison shows a repeatable fixed timing relationship in the relevant source and output. If the gap keeps growing, investigate the timing path, devices, sample rates and workload instead. A copied value cannot identify the cause in your setup.
Why is OBS monitoring out of sync when my recording seems fine?
Monitoring and recording can follow different output paths, so one may show a problem the other does not. Treat that as a clue to inspect the monitor device and routing, not as proof that the stream is correct. Compare the YouTube output as well.
Does a dropped-frame warning mean the audio drift is caused by my connection?
Not by itself. OBS describes dropped frames in connection troubleshooting as a network stability or bitrate-capacity issue; that is separate evidence from a growing audio gap. Check both issues on their own and use recordings and YouTube playback to locate the timing mismatch.