If the pastor’s lips move before the voice, the picture is ahead; if you hear the voice before the mouth moves, the audio is ahead. First check what viewers actually receive, then determine whether the mismatch stays about the same or grows during the service.
Do not buy equipment or change several settings at once. A fixed offset and a growing drift point to different investigations, and a local recording can help show where the problem enters the chain.
Identify which signal is out of sync
Watch a moment with clear speech and a visible mouth movement, such as a spoken introduction or a short sentence from the pulpit. Note which arrives first. “Audio ahead” and “picture ahead” are more useful notes than simply writing “out of sync”, because they tell you which direction a correction might need to take.
Do not estimate from a music bed, a wide shot, or a moment when the speaker is turned away. Look for several clear syllables and check more than one moment. A single apparent mismatch may come from the particular shot, a cut, or the way you are listening; the repeatable pattern is the useful evidence.
Write down the time, what you observed, and whether the issue affects one speaker or every audible source. For example: “At 10:14, the pastor’s picture was ahead of the voice; it looked similar at 10:20. The hymn audio seemed aligned.” This gives whoever operates the encoder or mixer a concrete symptom to reproduce.
Also distinguish a sync problem from a level or clarity problem. If the words are difficult to hear but the mouth and sound appear together, changing sync offset is unlikely to help. For a separate issue with distortion, see the practical checks in this guide to audio clipping on a continuous stream; clipping and timing are different faults.
Check the audience-facing stream on another device
The production preview is not the same as the delivered stream. Open the channel’s live output on a separate phone, tablet, or computer, ideally on a connection and playback device that are not part of the production setup. This answers the first important question: is the mismatch present for a viewer, or only in the operator’s preview?
Use headphones on the second device if possible, and avoid comparing audio from the room with the stream’s picture. Room sound reaches you at a different time from the encoded audio, so it can make a correctly synchronised feed seem wrong. If you are standing beside the pulpit, move away from the direct sound or have another person check the stream from elsewhere.
If the channel is public, be mindful that a test is visible to viewers. You can use a private or otherwise suitable test setup before a service, but confirm the current YouTube controls rather than assuming a particular visibility option is available in every workflow. For the live service, have a second person check and report the direction of the mismatch without changing settings on the operator’s say-so.
Repeat the observation after the stream has been running for a while. Note whether the mismatch is still similar or has changed. Do not infer the cause from one device alone: browser playback, buffering, device audio processing, and the viewer’s network can affect what one person experiences. If possible, compare a second viewer device before making a production change.
Compare the outgoing stream with a local recording
Make a local recording using the same production setup, with the same camera, microphone, mixer, and encoder path used for the stream. A recording made from a different source or a different mix is not a fair comparison. Use a short, ordinary speaking segment and compare it with the audience-facing stream from the same moment.
If the local recording and stream both have the same mismatch, the problem is more likely to be present before or within the production recording path. That narrows the work to inputs, source configuration, processing, or the encoder’s handling of those sources. It still does not identify one cause by itself.
If the local recording looks and sounds aligned but the delivered stream does not, keep investigating the delivery path and system load rather than applying a source offset immediately. Restream’s support guidance describes using this comparison to separate a local production issue from a problem that appears in the outgoing stream. Treat this as a diagnostic clue, not proof that the network is the cause.
For background on keeping a local computer in the stream path overnight, the Windows playlist workflow is a related operational example. The question here is narrower: what does your particular recording show when compared with the viewer feed?
Keep the recording, relevant OBS log, and a note of the test time if the issue recurs. Avoid repeatedly changing settings before preserving a useful example. A technician can often learn more from a recording that shows the fault and a clear description of when it begins than from a list of unrecorded adjustments.
Tell a fixed offset from growing drift
A fixed offset is roughly steady: if the voice seems late near the beginning, it seems late by about the same amount later. Growing drift changes over time. The speaker may look aligned at the start and increasingly out of sync as the sermon continues. These are different patterns, so record both the direction and whether it changes.
| What you observe | What it suggests | What to do next |
|---|---|---|
| Similar mismatch at several points | A fixed offset is plausible | Test one source’s sync control in a recording or controlled stream |
| The mismatch grows as the service continues | A fixed offset alone does not explain the change | Find when it begins and whether one source or the whole mix changes |
| Local recording and viewer feed both show it | The fault may be earlier in the production path | Inspect sources and processing before delivery changes |
| Local recording is aligned but viewer feed is not | The fault may be later in the path | Check the outgoing configuration and system/network evidence |
| Only one viewer device reports it | Local playback may be involved | Compare another device before changing the production setup |
This table is a way to organise evidence, not a fault-finding guarantee. A system can have more than one issue, and an observation may be affected by playback buffering or the recording method. Repeat the comparison with the same speaking moment before settling on a diagnosis.
A fixed correction cannot explain why a mismatch grows. Do not assume that restarting the encoder, changing a sample-rate setting, or inserting a particular delay will fix drift. The official material reviewed does not establish a universal repair for progressive drift. Note whether all sources move together or whether the microphone, video, or another input behaves differently, then preserve the examples and configuration for a careful investigation.
Trace likely production or delivery stages
Work through the signal path in order, without changing several parts at once. Start with the microphone and camera inputs, then any mixer or switcher, then the encoder, and finally the stream as received. At each step, ask whether the same mismatch can be heard or seen in a local recording or monitoring point. This is more useful than guessing that a particular device is responsible.
If only one microphone or one camera source appears affected, inspect that source’s connection and configuration first. If the whole programme is affected, look for a point shared by all sources. These distinctions help an operator decide what to test, but they do not prove that a cable, switcher, or computer is at fault.
For an OBS setup, identify the audio input that is actually included in the outgoing mix. OBS exposes audio properties for sources, but the right control depends on the particular source and setup. Focusrite’s official OBS setup guidance explains that a sync offset may be applied in Advanced Audio Properties when required, and that the needed value depends on the computer’s audio and video processing. Do not copy an example value as a universal setting.
If your church uses an ATEM Mini-family switcher, verify the exact model and its current documentation before using a model-specific audio-delay control. A control that exists on one model or software version should not be assumed on another. There is no reason to buy a switcher simply because sync is wrong; first establish that the existing signal path has a diagnosed limitation that the new device would address.
Dropped frames are a separate clue. OBS’s stream connection troubleshooting guide says dropped frames indicate an unstable connection to the remote server or a bitrate that exceeds what the connection can sustain. That points to connection and bitrate checks; it does not, on its own, demonstrate an audio/video timing fault. OBS also notes that dynamic bitrate may reduce dropped frames while lowering video quality and not resolving the underlying connection issue.
If the stream is a continuously repeated sermon file rather than a camera and microphone production, the diagnosis is different: inspect the source file and playback workflow as well as the output. A related guide on running a continuous stream of pre-recorded lectures discusses a different production route, but the same discipline applies: compare what is produced with what viewers receive before changing the delivery setup.
Test a measured correction before applying it live
Only test an offset after you have evidence of a reasonably steady mismatch and know which audio source is involved. Use the existing software or hardware control, change one variable, and record a short test. If audio is late, the adjustment needs to account for that direction; if audio is early, the correction must address the opposite direction. The control’s behaviour can vary, so verify the result rather than relying on the label alone.
In OBS, open the relevant audio source’s Advanced Audio Properties and use its sync-offset control if that is the appropriate control for your setup. Focusrite’s guidance specifically warns that the correct offset must be found experimentally because processing differs across computers. A number that helped another church is not a calibration for your camera, capture device, interface, or software version.
Make a small, documented change rather than jumping to a large correction. Record the original value, the test value, and what changed in the recording. Check a clear spoken phrase at more than one point in the test. If the sound becomes late when it was previously early, or the mismatch worsens, restore the previous value and review the direction and source selection before continuing.
Where a switcher is part of the chain, make sure the adjustment is being applied at the relevant stage and not duplicated in both the switcher and OBS. Double adjustments can create a new offset while appearing to fix the old one. Check the exact device manual and software controls, then test the combined output rather than treating a control screen as proof of sync.
Do not apply an untested correction during a service that cannot be interrupted. If the current stream is watchable, preserve it, take notes, and schedule a controlled test outside the service. If a correction must be attempted while live, have a second operator watch the audience-facing feed and agree on a rollback plan before touching the setting.
Recheck after the adjustment
A short test can show whether a fixed offset improved, but it cannot establish that a growing drift has been solved. Run a longer test that resembles the real sermon, including the same camera, audio sources, switching, and stream path. Watch near the start and later in the test, using the same external device or devices for comparison.
After an adjustment, check the local recording and the viewer stream again. If both have improved, note the working configuration and the date of the test. If only one has changed, do not keep turning the same control; return to the evidence and look for the stage where the two outputs diverge.
Repeat the check after a restart or a configuration update. A value may be stored per source or project, and a changed device or software configuration can make the previous test no longer representative. Keep a brief log with the start time, observed direction, whether the issue grew, source names, setting changed, and result.
For the next service, do a sound and internet check before going live, ask someone to watch the delivery endpoint, and keep an operator monitoring the inputs. If a fault returns, note when it starts instead of making multiple hurried changes. The StreamNeo option is relevant when the sermon is an uploaded video and the recurring pain is leaving a computer running overnight; it turns that file into a YouTube live stream without requiring your computer to stay on, but it is YouTube-only and does not diagnose a live camera-and-mixer chain.
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 change audio sync while the sermon is live?
Not before a controlled test, unless you have a clear reason and a rollback plan. A live adjustment can make the stream worse for everyone, and a local preview may not match what viewers receive. Have another person check the audience-facing stream if a live change is unavoidable.
What if the pastor’s lips are aligned at first but not later?
That is growing drift, not a steady offset. Record when it starts, whether it affects one source or the whole mix, and compare the local recording with the stream. A fixed delay alone does not explain why the difference changes over time.
Do dropped frames mean the audio is out of sync?
No. OBS identifies dropped frames as a connection or bitrate problem, which may affect the stream’s delivery, but dropped frames alone do not prove a timing mismatch between sound and picture. Check sync separately on the viewer feed and in a local recording.
Do I need to buy a switcher or audio interface?
Usually the first step is diagnosis with the equipment you already have. Buy hardware only if testing identifies a limitation in the existing setup and the replacement’s controls address it. Confirm the exact model’s documentation and test the change before relying on it for a service.