Audio out of sync on a podcast YouTube live stream usually comes from a timing mismatch between the camera, microphone, guest feed, or playback source. First decide whether the mismatch is already present in your encoder preview, or only appears after YouTube delivers the stream.
Then identify which signal is early, apply a correction only to the affected source, and test again. Low-latency settings change the delay between your encoder and the viewer; they do not repair lip sync, and one OBS offset cannot correct every source or a problem that keeps drifting.
First separate sync error from stream latency
Stream latency is the delay between your camera or encoder capturing an event and a viewer seeing it. If you clap and the viewer sees the clap several seconds later, that may be normal delivery delay. If the viewer sees your mouth move and hears the clap at the wrong moment, that is an audio-to-video sync problem.
YouTube describes latency as the time between capture and display, and its latency options affect the conversation between broadcaster and audience. Lower latency can make audience interaction feel more immediate, but it can also increase buffering for viewers with less reliable connections. It does not move a microphone recording into alignment with a camera frame. Check YouTube's current explanation in Manage live stream settings before changing the audience latency mode.
A simple distinction helps:
| What you observe | More likely explanation | First check |
|---|---|---|
| The whole stream arrives late, but speech matches the speaker | End-to-end stream latency | YouTube's latency setting and the viewer's connection |
| The mouth moves before the voice | Audio is behind, or the picture is early | Local preview and the camera source |
| The voice is heard before the mouth moves | Audio is ahead, or the picture is late | Microphone path and OBS audio settings |
| Sync is correct at first and worsens later | Drift, clock or processing problem | Local recording, source routing and encoder health |
| Only one viewer reports the problem | Viewer device or connection may be involved | A second device and separate connection |
Do not change latency simply because a viewer says the stream is several seconds behind real time. Ask whether the voice and picture are aligned at the moment they arrive. A stream can be late but well synchronised, or relatively immediate but badly synchronised.
Find where the mismatch first appears
Start with a short, controlled test rather than changing several settings during a live programme. Speak a sentence while looking towards the camera, then make a clear movement with a corresponding sound. A hand clap is enough: the visible contact and the sharp sound give you a reference point. A slate can make the movement easier to inspect, but buying one is not a repair and is not necessary.
Watch the encoder's local preview while making the test. If your software offers a local recording or archive, save the test and inspect it as well. You are trying to answer one question: is the signal already wrong before it reaches YouTube?
If the local preview and recording are out of sync, stay with the source and encoder checks. Changing YouTube's audience latency will not normally correct an offset that was created by your camera, capture device, microphone route or scene configuration.
If the local output is aligned but the YouTube version is not, review the stream's health and errors. YouTube's live stream troubleshooting guidance recommends checking the quality of the sources routed to the encoder, encoder errors, CPU load and the archive. It also distinguishes problems visible in the encoder from problems that arise while the stream is being sent out.
Ask other viewers to check from separate connections if the report came from one person. One viewer's device or internet connection can create a misleading report. If several viewers on separate connections see the same mismatch, investigate the encoder and its sources. If several viewers use the same local network, that network remains a possible part of the problem. These are useful indications, not proof by themselves.
Decide whether audio is ahead or behind video
Use the clap test or a spoken word with a visible mouth movement. Repeat it more than once. A playback hiccup or a distracted observer can make a single test look worse than the underlying signal.
Audio is ahead of video when the sound arrives before the visible action that produced it. In a podcast, you may hear the host say a word while the lips are still closing for it. You may also see a guest's reaction after hearing the guest's own voice. The usual correction is to delay the affected audio source, not to alter the general YouTube latency mode.
Audio is behind video when the mouth or other movement is visible before the corresponding sound. The host may appear to finish a word before the word is heard. The picture can be delayed instead, but first establish whether the late audio is caused by a source path or whether the picture is genuinely early.
This distinction matters because the controls work in opposite directions. Delaying already-late audio makes the mismatch worse. Delaying an image can help when the image is early, but it may hide a problem in the camera or capture path and may affect only that image source.
For a podcast with more than one person, test the host and guest separately. One microphone may be routed through a mixer, software call, or capture device with different processing from another. Do not assume that because the host looks correct, the guest and any inserted clips use the same timing.
Check every source and the monitoring path
Make a small map of the signal path before touching an offset. Write down which device supplies the camera picture, which device supplies each microphone, where a remote guest enters, and where music or pre-recorded clips enter. Note whether any source is present in more than one place.
Duplicate audio routing is a common source of confusion. For example, a microphone might enter OBS as a dedicated microphone source while also arriving through a capture device or desktop-audio route. You can hear an echo or an apparent timing error even though each individual copy is correctly timed. Mute one route at a time during a private test and confirm that each voice exists only where you intend it to exist.
Check the monitoring path as well as the broadcast path. Headphones may be monitoring a delayed return from a call or software mixer, while the audience hears a different, direct route. A host can then describe the monitoring delay as a stream sync fault. Compare the local OBS output, the recorded file and the YouTube playback rather than relying only on what is heard in headphones.
For a guest, ask whether the guest's own local recording is aligned. That does not diagnose your complete broadcast, but it can show whether the issue enters before the guest reaches your scene. For a music bed or an inserted video, test the media source by itself. A media file can already contain an audio-video offset, so changing the microphone timing will not repair it.
Check that the intended source is active in the scene you are actually streaming. A preview scene and live scene can contain different camera or audio sources. Also check for filters, software mixers, call applications, capture devices and other processing that may add delay. The aim is not to replace equipment by default. It is to locate the first point where the timing becomes wrong.
If the stream runs continuously, source reliability matters beyond sync. A clean restart procedure can help when a radio-style broadcast disconnects, but restarting does not cure a stable audio offset. Keep that distinction in mind when reviewing guidance such as how to restart a YouTube radio stream automatically after it disconnects.
Correct a stable offset in OBS
Once you have established that the mismatch is stable and belongs to one source, adjust that source rather than applying a guessed value to the entire programme. In OBS, open the audio source's Advanced Audio Properties and use Sync Offset, measured in milliseconds, to change when that audio is presented. The OBS Project forum discusses this control in the context of forcing an audio delay; check the current OBS interface if the menu labels have changed.
If audio is ahead of the picture, a positive audio delay may bring the voice later into alignment. Start with a small change based on what you observed, record a new representative test, and compare it with the original. Do not copy an offset from a tutorial. A setting that works for one camera, interface and computer can be wrong for another.
Adjust only the source you have diagnosed. If the guest is early but the host is correct, change the guest route. If an inserted clip is early, change the clip's route or inspect the file. Applying the same offset to every source can make the correctly timed sources wrong and can create a new mismatch between speakers.
When the picture is early and audio is late, delaying the image may be appropriate. OBS documents the Render Delay filter as a way to delay an image source, including a webcam image, when it needs to line up with microphone audio. See the OBS Render Delay filter documentation for the current filter behaviour and controls.
Use the image filter carefully. It affects the image source to which it is applied, not every video source in your programme. If the camera is also used in another scene, confirm the effect there before going live. A picture delay can also make the local preview feel less responsive, so test the finished scene rather than judging only the camera window.
The correction is a timing adjustment, not a cure for an unstable source. If the required value seems to change during the programme, stop increasing the offset and move to the drift checks below. A large constant delay can conceal a source problem for a while without removing it.
Test with a recording and a private broadcast
After each meaningful change, record a short test using the same camera, microphone, guest path and playback sources planned for the live show. Include normal speaking, a visible movement, a guest response if relevant, and any audio clip that will be part of the programme. YouTube recommends testing with movement and audio similar to the intended stream, rather than testing a different simplified scene.
Review the recording from the start and near the end. A fixed offset should look roughly the same throughout. If it is aligned at the beginning and wrong near the end, treat that as drift rather than adding more Sync Offset. If the host is aligned but the guest is not, return to the guest source rather than correcting the master mix.
A private or unlisted YouTube broadcast can reveal delivery behaviour that a local recording cannot. Use the Live Control Room preview and view the result from a separate device when possible. Keep the test short and representative, and avoid asking the audience to diagnose changes while a public episode is under way.
Review stream health at the same time. YouTube's encoder settings guidance recommends testing the planned setup, while its streaming tips cover upload capacity and leaving room for the connection to operate reliably. An overloaded computer or an unstable upload can produce dropped or irregular output that is easy to mistake for a fixed sync error.
If local and private tests are clean but one viewer still hears a mismatch, compare with another viewer and another device before changing OBS again. You can damage a working source by responding to an issue that exists only in one playback path.
Investigate audio that gradually drifts
Audio that keeps drifting out of sync is a different problem from audio that is always, for example, slightly early. A constant offset moves the whole track by one amount. Drift means the relationship changes as the stream continues, so a single OBS Sync Offset cannot correct it for the entire broadcast.
First compare the beginning and end of a local recording. This tells you whether the change starts before YouTube. If the local file drifts, inspect the source clocks, capture path, software call, media source and computer load. Check whether the audio is being resampled, duplicated or passed through different applications before reaching OBS. Do not assume a new microphone or interface is the answer unless testing isolates that part of the chain.
If the local file is aligned but the YouTube result changes over time, inspect encoder warnings, CPU load, stream health and outbound connection conditions. YouTube's troubleshooting guidance points creators towards source quality, encoder errors, CPU load, the archive and stream health. It does not provide one universal drift setting, so keep the diagnosis tied to where the change first appears.
A remote guest can introduce a changing relationship if the call application, local recording and broadcast return are not using the same timing reference. Test the guest route separately from the host, and ask whether the guest's audio is the only part that changes. Likewise, a long media file may have its own audio and video timing issue even when live speech remains stable.
Avoid repeatedly changing offsets during the programme. Each change makes the result harder to interpret and can leave the next recording with a different error. Save the current scene collection or note the setting, run a controlled test, and change one variable at a time.
If the stream is intended to run unattended, also test what happens after an overnight period rather than assuming a short daytime check represents the full run. A 24/7 local video stream guide can help you think about the difference between the media file, the encoder process and YouTube delivery. The same principle applies in OBS: isolate the part that changes instead of applying a blanket offset.
Make the next live test repeatable
Keep a short test scene or test file that contains a visible clap, normal speech, a guest response and one representative playback item. Use it before a public broadcast and after changing a camera, call application, audio interface, media file or scene collection. The value is not in the prop or file itself; it is in making comparisons repeatable.
Record the date, source, observed direction and adjustment. For example, note that the guest audio was ahead in the local recording, that only the guest source was changed, and that the private test was aligned at both the beginning and end. This is more useful than remembering that an old tutorial once suggested a particular number.
Keep delivery latency as a separate decision. Choose it according to the interaction and buffering trade-off that suits the channel, then diagnose lip sync independently. If your podcast is part of a wider always-on channel, a holding screen between recorded segments may reduce confusion while you prepare a scene; the holding-screen guide for an OBS loop stream covers that separate workflow.
For a setup where the computer is the recurring source of overnight failures, StreamNeo removes the need to keep that computer running for the YouTube broadcast: upload the prepared video, add the YouTube stream key, and let the service run and restart the channel while you are away. That does not repair a badly synchronised source file, so test the audio and picture before uploading it.
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
Does lowering YouTube latency fix audio out of sync?
No. Latency controls how long the stream takes to reach viewers, while sync concerns the relative timing of audio and video. Lower-latency modes can also increase buffering, so choose them for interaction needs rather than as an audio correction.
Should I use one OBS audio sync offset for the whole podcast?
No. The correct adjustment depends on which source is early or late. Apply a change only to the diagnosed source, then record and review a representative test with the host, guest and playback audio you plan to use.
How do I know whether audio is ahead or behind video?
Make a clear visible movement with a sharp sound, such as a hand clap, and compare the contact with the sound in the local preview or recording. If the sound comes first, audio is ahead; if the picture comes first, audio is behind. Repeat the test before changing a setting.
What should I do when audio keeps drifting out of sync?
Do not keep increasing a fixed offset. Compare the beginning and end of a local recording, then check source routing, capture timing, CPU load, encoder warnings, stream health and the outbound connection to find where the change begins.