A 24/7 kirtan stream can sound out of sync because of a stable audio offset, a mismatch that grows over time, or playback that is delayed but still aligned. Check which pattern you have before changing OBS: a measured Sync Offset can correct a stable mismatch, but it is not a guaranteed fix for drift.
Test the stream output, not just the OBS preview. Use the same clear sound and visible event near the start and later in a representative run, then compare a local recording with YouTube playback if you can. That gives you evidence about where the problem starts and whether it changes.
Identify the kind of sync problem
Pick a repeatable cue: for example, clap in view of the camera, strike a small bell once, or show a planned visual marker at the same moment as a distinct audio cue. In a kirtan setting, a hand clap or a visible strike on a percussion instrument can work, provided the sound is sharp enough to identify in playback. Avoid judging sync from a sustained harmonium note or a singer's mouth movement alone; both can be difficult to time precisely by eye and ear.
Record the cue in OBS and, if practical, run a private or unlisted YouTube test. Check the recording or playback near the beginning and again later. Note whether the sound leads or trails the matching movement, whether the gap appears constant, and whether the local and YouTube versions differ. YouTube Help advises testing with audio and movement similar to the actual stream and monitoring stream health; see its live encoder settings and testing guidance.
Classify what you hear before touching a setting:
| What you observe | What it suggests | First action |
|---|---|---|
| The sound leads or trails by about the same amount at both checks | A stable offset is plausible | Measure the difference and adjust the affected source in OBS |
| The cue is close at first but separates more later | Timing drift is plausible | Compare sources, clocks, timestamps and stream health |
| A local recording is aligned but YouTube playback is not | The issue may be later in the delivery path | Repeat the same test and inspect the platform output |
| Picture and sound both arrive late, but match each other | Playback latency, not an A/V sync mismatch | Decide whether the delay matters for your audience |
These are clues, not diagnoses. A single cue can be misread, and a preview can differ from the finished broadcast. Keep a short note of the test conditions: platform, OBS version, sample rate, audio route, video source, and when the mismatch appears. That is more useful than relying on memory after several changes.
Check whether the mismatch changes over time
An always-on channel needs a longer test than a short preview. Check the same cue near the beginning and later in a run that resembles the real broadcast. For a channel expected to run overnight, that means sampling across the run rather than only watching the first few minutes. You do not need to keep a person watching continuously: save a local recording or schedule a visible and audible marker that you can find at both points.
Write down the observed relationship in plain terms: “the bell is heard just before the strike at both checks” or “it matches at first, then the bell is clearly ahead later”. If you can estimate a difference from the recording, note the estimate and how you measured it. Do not turn an uncertain impression into a precise millisecond setting. A repeatable measurement is the basis for an adjustment; a guessed number can hide the symptom at one moment and worsen it at another.
Compare both ends of the chain. If the local recording and YouTube playback show the same growing separation, investigate the source and encoding path. If the local recording stays aligned but the platform result does not, preserve both examples and check the delivered stream and its health information before assuming OBS preview is representative. YouTube's stream health guidance can help you inspect the live output, though it does not by itself identify every sync fault.
For a test stream, making it private is useful when you want to inspect the output without putting the test in front of viewers. Follow the steps in how to make a private YouTube live stream, and keep the test similar to the production audio and video route. A test using a different microphone, computer, or playback method may not reproduce the fault you are trying to find.
Adjust OBS Sync Offset for a stable mismatch
If the offset is stable, adjust the audio source that is actually reaching the stream. In OBS, open Advanced Audio Properties and find Sync Offset for that source. OBS's audio and video synchronization guidance explains the source offset and the video Render Delay filter. The direction matters: a positive audio Sync Offset delays the audio; a negative value moves it forward.
Use the cue to decide the direction. If the sound happens before its matching picture, delaying the audio with a positive value may bring them together. If the sound happens after the picture, moving audio forward may be appropriate if that source and configuration allow it; alternatively, delaying the video can be the more suitable correction. OBS's Render Delay filter delays a video source, so use it only when the measured output and your source arrangement call for that approach.
Measure rather than copying a generic value. Locate the sound and corresponding visual event in the recording or playback. Estimate their separation using the player timeline or frame-by-frame inspection where available, then make a small, deliberate adjustment in the relevant direction. Keep the previous setting written down. Change one control at a time, repeat the cue, and compare the result. If you cannot tell whether the sound is early or late, gather another test rather than trying both directions at random.
Confirm the selected source is the one that reaches the live mix. A scene may contain a microphone, media file, desktop audio, and a mixer or capture input; changing the wrong source can have no effect or make a different route worse. If an obvious test change produces no audible difference, inspect the active scene and audio routing before increasing the offset. Also check whether the same audio is entering twice through separate sources, since a duplicated route can sound like an echo rather than a simple fixed offset.
Do not treat the offset value as a permanent diagnosis. Record the setting and the conditions in which it worked, then test again after a longer run. A fixed correction that improves the first cue but leaves a later cue increasingly separated is evidence to move to drift investigation, not to keep adding more delay.
Verify the result in the finished stream
A successful preview adjustment is not enough. Make another recording and check the finished output at the start and later in the test. If possible, compare a local file with the YouTube playback using the same cue. Confirm that the audio and movement match in both places and that an adjustment has not corrected one source while shifting another.
Listen on the kind of device your audience is likely to use as well as monitoring the source audio. A phone speaker or Bluetooth playback can introduce its own delay, so it is not a reliable reference for deciding whether the encoded stream itself is aligned. Keep the test setup consistent: compare like with like, and do not judge one version on headphones and the other through a wireless speaker.
For a repeatable record, note the time of each cue, the source you adjusted, the former and new setting, and the observed result. If the channel is a prerecorded loop, include a recognisable visual event and sound from the actual file, not just an OBS test tone. Guidance on streaming a video file to YouTube Live with FFmpeg is relevant if that is your workflow, but OBS offset controls and FFmpeg timing options are not interchangeable. Keep the test tied to the encoder and route you actually use.
When you return the channel to public operation, monitor its health and check another cue after a longer interval. A change that appears fixed in a short test may not stay fixed through an overnight run. If viewers report a mismatch, ask when they noticed it and whether both sound and picture were late, rather than treating every report of “delay” as the same fault.
Investigate clocks, timestamps and sources if it drifts
When the mismatch grows over time, look for a timing instability rather than applying another static offset. Audio and video can follow different clocks or timing paths. A microphone connected through an interface, a mixer, a capture device, or a network source may behave differently from video captured by a camera or played from a file. Reconnects or changes in encoder behaviour can also coincide with a change. These are investigation paths, not proof that any one device is at fault.
Check the source configuration first. Confirm the sample rate and channel format expected by the platform, and make sure the audio route is consistent from source through encoder. YouTube's current live encoder guidance lists 44.1 kHz for stereo audio and 48 kHz for 5.1 surround sound; verify the official YouTube encoder requirements before changing a setting. Do not copy another platform's format limits or offset advice into a YouTube setup.
If the source is a prerecorded file, compare the local file's playback and the stream output. If it is live audio from a separate device, test that route independently where possible. Check whether the problem begins after a reconnect, a scene switch, a source restart, or an encoder warning. Keep the original recording and a later sample; they can show whether the timing difference is gradual or starts suddenly.
FFmpeg-based setups may have tools for handling a source whose timing differs from the encoder, but their behaviour depends on the actual command, version, and source. Do not paste a command-line flag from a 24/7 radio guide into an OBS workflow without understanding what it changes. If you are running a file-based stream, a 24/7 ambient music FFmpeg workflow is a relevant reference for that separate setup, not a general prescription for a kirtan stream.
Consider hardware changes only after you have isolated the route. If the fault follows a USB audio interface, mixer, or capture path, test that existing equipment and its connections before buying anything. A different interface may be useful in a confirmed case, but replacing hardware without locating the timing change can add another source and another clock to diagnose.
Distinguish playback delay from desynchronization
Live latency describes how long the combined picture-and-sound programme takes to reach a viewer. Audio-video sync describes whether the picture and sound match each other. A stream can arrive later than a broadcast elsewhere and still be properly synchronized; conversely, a low-latency stream can have sound that visibly leads or trails.
This distinction matters for a devotional channel. A viewer watching a continuous bhajan or kirtan recording may not need to interact in real time, so a shared delay may be acceptable. A viewer joining a live call-and-response or following an event as it happens may care more about the total delay. Neither case means you should use an audio Sync Offset to correct ordinary platform latency. That setting changes the relationship between sources, not the time the whole programme takes to reach the viewer.
If you are comparing your own output with another device, remember that the viewer's network, player, and device can affect when playback begins. Ask whether the audio and image are out of step with each other on the same device, or whether the whole stream is simply late. That question prevents a delay complaint from leading to an unnecessary change in source timing.
Plan a dependable test for an always-on channel
Before the next long run, choose a repeatable cue and make a short private test using the actual stream file, audio route, and video source. Save the local recording, then inspect YouTube playback. Write down the beginning result and a later result, plus any change made in OBS. This gives you a baseline to compare when the issue returns, rather than a collection of unconnected guesses.
For ongoing diagnosis, keep a simple log: date, encoder and software version, source route, relevant sample rate, whether a reconnect occurred, and what the cue showed. Do not overcomplicate it. The useful question is whether the same cue remained aligned, stayed at the same offset, or separated further. If the stream is a prerecorded loop that runs continuously, use a point in the file that is easy to find again, and make sure the file itself has not changed between tests.
If maintaining a computer and OBS for a continuous prerecorded channel is itself the source of overnight interruptions, StreamNeo can remove the need to keep your own computer running for that file-based YouTube broadcast. It does not replace the need to verify the programme's audio and picture, and you should still test the output before relying on it for a long run.
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
Will one OBS Sync Offset value fix every audio sync problem?
No. A measured offset can correct a stable difference between a source's audio and video, but it does not establish why a mismatch grows over time. Test at the beginning and later in a representative run, then investigate timing stability if the gap changes.
Should I delay audio or video in OBS?
Choose based on the observed direction and the source you need to correct. A positive audio Sync Offset delays audio; a video Render Delay filter delays video. Measure the finished output, change one control at a time, and retest rather than applying a generic value.
Is YouTube live delay the same as audio being out of sync?
No. Live delay is how late the combined programme reaches the viewer, while sync is whether picture and sound match each other. If both arrive late together, changing the audio offset is not the right response.
Do I need to buy an audio interface to fix a kirtan stream?
Not as a first step. Compare the local recording and platform playback, identify whether the fault follows a particular audio route, and test existing equipment before considering a replacement. A new device is relevant only if the source path has been isolated as part of the problem.