A fixed audio delay and progressive audio drift are different problems. A sync offset can compensate for a stable delay, but it will not correct audio that moves further out of alignment as a 4K 60fps YouTube Live stream continues.
To prevent drift, test the complete chain with the same sources you plan to use, match each capture device to its real resolution and frame rate, check audio timing in OBS, and use YouTube's stream health messages to separate configuration issues from network delivery problems.
First identify the shape of the error
Start by deciding whether the error is constant or progressive. This determines which checks are useful and prevents you from applying a fixed correction to a timing problem that is still changing.
A constant offset looks like this: someone claps, and the sound arrives late by roughly the same amount near the beginning and later in the stream. You may notice it immediately in the local preview or in the received YouTube stream. The picture and sound are separated, but the separation does not keep increasing.
Progressive drift looks different. The stream may begin acceptably, then the audio becomes increasingly early or late. A clap near the start may be close to correct while a second clap later has a visibly different separation. Viewers may describe this as audio gradually going out of sync.
A fixed sync offset changes the starting relationship between an audio source and a video source. It does not make two clocks run at the same speed. If the error grows over time, changing the offset may make one moment look better while making another worse.
Make a short record of the symptoms before changing anything. Note which source is affected, whether the local OBS preview and the received stream behave the same way, and whether the separation grows. If you use separate cameras, HDMI capture, microphones, music players, or browser sources, identify which combinations are present when the problem appears.
This distinction is also useful when troubleshooting a long-running channel. If OBS stops sending after several hours, that is a different failure mode from gradual audio drift. The causes may overlap in a complex setup, but the tests should not assume they are the same; the checks in why OBS stops streaming to YouTube after a few hours cover stream interruptions rather than proving an audio-sync cause.
Run a representative test stream
Do not test only a still image or a short local preview if the real broadcast contains movement, music, multiple scenes, and capture devices. YouTube recommends that tests include audio and movement similar to what you will use in the stream. A quiet preview can hide a timing problem that appears when your production scene is active.
Create a private or otherwise controlled test event using the intended resolution, frame rate, encoder, audio sources, and scenes. Use the same camera or HDMI source, not a substitute webcam, if the production setup depends on a capture card. Include the background music, microphone, visualiser, overlays, and transitions that will be present during the overnight stream.
Add two or more sharp audio-and-picture events. A visible hand clap is useful because the frame of contact and the sound transient are easy to compare. You can also flash a light at the same moment as a short click, provided the test recording makes both events clear. Place one event near the beginning and another later in the test.
Review the received YouTube stream rather than relying only on OBS's preview. The local preview tells you about part of the chain; it does not prove that the encoded stream, upload path, YouTube ingest, and playback path remain aligned. Watch or record the test at more than one point and compare the same type of event.
Keep a simple test note:
| Check | What to record | Why it matters |
|---|---|---|
| Start of test | Approximate audio delay at the first event | Establishes the initial relationship |
| Later point | Delay at the later event | Shows whether the error is growing |
| OBS preview | Whether the issue is already visible locally | Helps locate the first affected stage |
| YouTube playback | Whether the received stream differs from OBS | Separates local timing from delivery and playback observations |
| Stream health | Exact warnings and counters | Prevents guessing from a symptom alone |
The point is not to produce laboratory-grade measurements. It is to establish whether the same error remains stable or changes. That single observation often saves more time than repeatedly moving an offset slider.
If your channel plays a prepared video rather than a live camera feed, use the actual file and playback route. A guide such as the best video format for 24/7 live streaming can help you check the file itself, but a compatible MP4 does not by itself rule out timing problems introduced by a playback source or separate audio route.
Match every capture source to its real format
A capture source should be configured for what it actually outputs, not what you hope it outputs. Check the source device, its driver or control panel, and the OBS source properties. Pay particular attention to the difference between 60 fps and 59.94 fps.
Those rates are close, but they are not identical. Treating 59.94 as 60 without checking the device can create a mismatch in a chain that depends on continuous timing. The same applies to resolution. A source sending 1920 by 1080 should not be silently described as 3840 by 2160 merely because the canvas or output is 4K.
For an external HDMI source, check:
- The source device's actual output resolution.
- Whether it outputs 60, 59.94, 30, or 29.97 frames per second.
- Whether the capture device is set to accept that exact mode.
- Whether OBS is scaling the source or changing its frame cadence.
- Whether the source changes mode when a scene, application, or display is switched.
AVerMedia's GC553 setup guidance documents matching capture resolution and FPS to the actual source, including the distinction between common 60 and 59.94 modes. Treat that as device-specific guidance, not as proof that every capture card behaves identically.
The same principle applies when you combine a camera with a separate audio interface. A camera may provide video at one timing rate while the audio interface uses its own clock. That does not automatically mean the setup will drift, but it gives you a reason to test the complete route instead of assuming that the devices will remain aligned indefinitely.
Check the OBS base canvas and output settings as well. A 4K output does not turn a lower-resolution source into native 4K, and changing the output resolution is not a direct audio-sync fix. If reducing the workload makes the problem disappear, that is useful evidence about the system, but it does not identify the exact timing fault.
For a prepared devotional, ambience, or study channel, avoid unnecessary conversion between sources. A single file with embedded audio is easier to test than a video source combined with a separate music player and a separate microphone. If you need those separate sources, add them one at a time during testing so you know which route changes the result.
Inspect audio devices and capture timing
Next, follow the audio from its origin to OBS. List every device and application that can produce sound: microphone, USB interface, capture-card audio, desktop audio, media source, browser source, and any virtual audio cable. Then identify which of them are active in each scene.
Check the sample rate in OBS and in the operating system or device control panel. YouTube's encoder guidance documents 44.1 kHz for stereo audio and 48 kHz for 5.1 surround sound, while its live-streaming health documentation also recognises 44.1 kHz and 48 kHz as recommended rates. Use a deliberate setting that matches the audio path rather than allowing different devices to choose independently.
A sample-rate mismatch is not the only possible cause of drift, and a matching sample rate is not proof that the problem is solved. It is a basic consistency check. If YouTube reports an audio sample-rate issue, record the exact message and compare it with your OBS and device settings instead of treating every warning as an explanation for the drift.
Look for devices that sleep, reconnect, change clock mode, or switch sample rates. USB microphones and interfaces can be affected by power management, hub changes, driver behaviour, or a different application taking control of the device. A capture card may also expose audio from the HDMI source while your scene separately includes desktop audio from the same application, creating an echo or apparent timing issue.
Use one clear source during diagnosis. Temporarily remove duplicated audio routes and mute sources that are not part of the test. If the sound is present through both capture-card audio and desktop audio, do not correct one with an arbitrary delay before confirming which route the viewer is hearing.
Check whether the desynchronisation is already present before OBS encodes the stream. Record the source locally where practical, then compare it with the OBS recording and the received YouTube test. If the source recording is aligned but the OBS recording is not, focus on the OBS source and device path. If OBS is aligned but YouTube playback is not, inspect encoding, ingest health, and playback observations without jumping to a fixed offset.
Some capture-card instructions include a sync-offset control for a particular model and setup. That can be useful when the delay is stable, but it does not establish a universal correction for progressive drift. Use it only after you have measured the error and identified the affected source.
Check OBS sync settings and measure a fixed offset
OBS exposes sync controls in Advanced Audio Properties. Before changing one, write down the current value and the source it affects. Then use the representative test to estimate the offset at the beginning and later point.
If the delay is stable, adjust the affected source in small, measured increments and repeat the test. A vendor guide may show a range such as -50 to -200 ms for a particular capture-card scenario, but that range belongs to that documented setup. It is not a recommendation for all cameras, capture cards, microphones, or YouTube streams.
Do not apply the same offset to every audio source unless the evidence shows that every source shares the same delay. A microphone entering through an audio interface may need different treatment from audio embedded in an HDMI capture signal. A media source may already be synchronised internally and become wrong if you add a delay to it.
When the offset is stable in OBS but changes after YouTube delivery, compare an OBS recording with the received stream. Keep in mind that playback buffering and viewer-side conditions can affect what you observe. Use repeated identifiable events rather than judging a long music passage by ear.
If the offset grows, stop adjusting the fixed value. Recheck source frame rates, sample rates, device clocks, capture routes, and OBS logs. There is no single universal cause of progressive drift that can be inferred from the symptom alone. A growing error requires evidence from the particular signal chain.
If you are using a file-based 24/7 workflow and do not need live capture, removing unnecessary live devices can reduce the number of clocks and conversions involved. A cloud workflow such as StreamNeo is useful here when the specific problem is leaving a local computer, capture device, and overnight OBS session running; you still need to validate the source file and YouTube stream, and it does not turn an unknown source-timing problem into a guaranteed sync result.
Review YouTube settings and stream health
For a 4K 60fps stream, compare the encoder configuration with YouTube's current official guidance. YouTube's live encoder settings and bitrates guidance lists 2160p at 60 fps with 35 Mbps recommended for AV1 or H.265 and 50 Mbps recommended for H.264. It lists minimums of 10 Mbps for AV1 or H.265 and 14 Mbps for H.264.
Those are ingest recommendations, not a promise that choosing a figure prevents audio drift. Select a bitrate your connection and encoder can sustain, and verify the codec and frame rate being sent. If your connection cannot sustain the required workload, preserving 4K60 may produce a less reliable stream than reducing resolution or bitrate. That is a delivery trade-off, not evidence of a clock correction.
YouTube recommends a 2-second keyframe interval and says not to exceed 4 seconds. It documents AAC or MP3 audio, with 5.1 surround supported only for AAC over RTMP or RTMPS. For 4K, YouTube says the low-latency option is not available and that streams are optimised for quality with normal latency. Normal latency is context about delivery delay; it is not proof that normal latency causes progressive drift.
Open the live control room during the test and read the actual stream health messages. YouTube's Live Streaming API documentation includes possible health or configuration issues such as audio sample-rate errors, sample-rate mismatch between primary and backup streams, frame-rate mismatch between primary and backup streams, video ingestion starvation, and long keyframe intervals. These messages are clues about the reported condition, not automatic proof that each condition caused your sync problem.
If YouTube reports an audio sample-rate error, return to the device and OBS checks. If it reports a frame-rate mismatch, confirm the actual source mode and encoder output. If it reports ingestion starvation, inspect encoding load and delivery capacity. Keep each observation tied to the message that produced it.
Treat dropped frames as a separate network problem
OBS describes dropped frames as an indication that the connection to the remote ingest server is unstable or cannot sustain the configured bitrate. That points first to network delivery, not to proof of an audio clock problem.
Check the dropped-frame counter, upload capacity, connection stability, and selected ingest route. A connection can appear fast during a brief speed test yet fail during a long upload because of congestion, wireless interference, router behaviour, or an unstable route. Use a wired connection where practical and avoid sharing the upload path with large transfers during the test.
Reducing bitrate can help when the connection cannot sustain the current load, but it lowers video quality. Reducing resolution or frame rate is another way to reduce the workload, with a more visible effect on the 4K60 goal. Test one change at a time so you can tell whether the improvement came from network headroom, encoder load, or a timing change.
OBS also describes dynamic bitrate as a way to avoid dropping frames when conditions change. Treat it as a fallback rather than a root-cause fix. It may keep a stream moving while reducing visual quality, but it does not repair mismatched clocks, sample rates, source frame rates, or a faulty capture route.
Record two separate observations in your notes: whether the stream is dropping frames and whether audio/video separation is growing. They may happen together, but one does not establish the cause of the other. YouTube's stream health diagnostics and OBS's delivery counters describe different parts of the path.
Retest after each material change
Once you have a baseline, change one thing at a time. A useful order is source format, audio-device consistency, duplicated routes, OBS sync settings, encoder workload, and network conditions. After each change, repeat the same test with the same identifiable events.
Do not judge success from the first few seconds. Compare the initial event and a later event in the received stream. If both show the same improvement, a fixed offset may have addressed a stable delay. If the later event is progressively worse, return to timing and clock checks rather than adding more offset.
Keep the test workload close to the real broadcast. If your overnight channel uses a looping video, a visualiser, and a music source, test those together. If it uses a camera, microphone, capture card, and scene transitions, include them. A fix that works with one quiet scene may fail when the production scene introduces another source or changes the device mode.
When the stream is stable, save the working settings and note the device versions, source modes, audio sample rate, encoder configuration, bitrate, and network arrangement. This gives you a known baseline after a driver update, a Windows audio change, or a replacement cable.
For channels built around playlists or prepared videos, keep the playback path simple and documented. The workflow described in how to stream multiple videos continuously to YouTube Live is relevant when the goal is continuity, but continuity and audio synchronisation still need separate testing. If you are moving from a local OBS setup, how to stream 24/7 on YouTube without OBS explains a different operating model; compare it based on whether it removes the local timing chain you are trying to diagnose.
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
Can a sync offset fix audio that drifts over time?
Usually, a fixed offset is suited to a stable delay, not an error that keeps increasing. Measure the relationship near the beginning and later in the received stream before applying one. If the separation grows, inspect clocks, sample rates, source frame rates, capture routes, and device behaviour.
Do dropped frames cause audio drift?
Dropped frames indicate a network delivery problem when the connection cannot sustain the configured bitrate or is unstable. They can occur alongside sync problems, but they are not proof of an audio-sync cause. Check OBS delivery counters and YouTube health messages separately from your timing tests.
Should a 4K 60fps capture source be set to 60 or 59.94 fps?
Set it to the mode the source actually outputs. Check the source and capture-device settings rather than treating 60 and 59.94 as interchangeable. A mismatch can complicate timing, so record the exact mode in your test notes.
What is the quickest reliable test for progressive drift?
Run a controlled test with the real sources and scenes, then include clear audio-and-picture events near the start and later in the received YouTube stream. Compare the separation at both points. A stable difference suggests a fixed offset may be relevant, while a growing difference calls for investigation of the timing chain.