When lecture audio goes out of sync, first establish whether it is offset by a steady amount or whether the gap grows during the stream. Then compare what you hear at playback with the encoded output and check capture timing, timestamps, audio processing and the delivery path before changing a delay setting.
A fixed offset and gradual drift are different symptoms, not diagnoses. A single audio-delay adjustment may help with a stable offset, but it cannot be assumed to correct an error that keeps accumulating. Use repeatable observations to locate where the change begins.
First decide whether the error is fixed or growing
Choose a recognisable event in the lecture: a spoken word paired with a visible mouth movement, a hand clap, or a slide change accompanied by a spoken cue. Note the approximate relationship between sound and picture near the start, then check the same kind of event later. For example, audio that is already slightly late at the start and remains similarly late points to a different pattern from audio that begins aligned and falls further behind.
Record the time and observed offset at each check, using the same playback device and viewing conditions where possible. You do not need laboratory precision to distinguish “about the same” from “getting worse”, but avoid relying on memory. If the offset changes suddenly rather than gradually, note when the jump occurred and whether it coincided with a reconnect, a source change or a player interruption.
These patterns narrow the investigation, but none identifies a cause on its own. A stable offset can arise at more than one stage, and an increasing offset does not by itself prove the encoder is at fault. Preserve the current settings and a short record of the symptom before troubleshooting so you can tell whether a later change actually helped.
Measure at playback, not by guesswork
Use a receiver that lets you observe the stream without disturbing the public lecture if possible: a test channel, a private test broadcast, or a separate monitoring session. Check from the same kind of playback route your audience uses, because a local preview and a viewer’s player may follow different paths. Note whether the symptom is present in more than one player or on more than one device before attributing it to the broadcast.
If your workflow includes FFmpeg, ffplay can report audio/video synchronisation drift when run with its statistics display. The ffplay documentation describes its synchronisation behaviour and the clocks it can use; it also says, “The master clock is used to control audio-video synchronization.” Treat the displayed drift as an observation about that playback session, not proof of which upstream component caused it. A player can show a changing relationship without telling you whether the source, encoder, transport or receiver introduced it.
Keep a simple log: elapsed time since the stream began, player or device, what event you compared, and whether the audio was early, late or changing. If a restart is safe and appropriate, repeat the observation after restarting. A symptom that returns at a similar rate is useful evidence, but it still needs to be compared with the stream earlier in the signal path.
For the basics of routing a computer source into OBS before testing, see how to capture application audio in OBS. Confirm which audio source is actually being captured; otherwise a timing test may be measuring a different signal from the lecture audio you intend to broadcast.
Compare the encoded stream with what viewers receive
The most useful question is where the sync first changes. Compare the source or capture, an encoded recording or output if available, and the stream as received by a viewer. Keep the same identifiable event as your reference. If a local recording made from the broadcast output already shows growing drift, investigate capture and encoding before changing a receiver setting. If that output looks stable but the distributed playback does not, focus next on ingest, transport, any platform-side processing, and the player.
This is a fault-localisation method, not a guarantee that every workflow exposes all three checkpoints. Some services do not provide a convenient copy of the incoming encoded stream, and a local preview may not represent the final output. Use the closest comparable observations you can make, and be clear about which stages you could not inspect. If you can only see the public playback, you can still compare different receivers, but cannot confidently separate encoder behaviour from everything downstream.
Keep the lecture content and settings constant during a comparison. Switching audio sources, changing frame rate, replacing the file and changing transport together makes it difficult to know what altered the result. If you use a recording or test stream, label it clearly so it is not mistaken for the live lecture. Where the existing broadcast cannot be interrupted, collect evidence from a non-disruptive receiver first and schedule any test that could affect viewers.
The same careful approach helps with adjacent stream problems. For example, the RTMP bitrate checklist for a 24/7 stream in India concerns delivery settings, but bitrate changes should not be used as a substitute for checking whether audio and video timestamps remain coherent.
Check capture timing and timestamps
A capture source can feed audio and video with timing information that the encoder must preserve as it packages the output. In OBS, encoded packets expose presentation timestamps (PTS), decode timestamps (DTS) and a timebase. The OBS encoder API documentation describes these packet fields; OBS also documents output as interleaved encoded audio and video packets in monotonic timestamp order. If your tools expose packet information, inspect whether timestamps remain ordered and coherent across both tracks during the run rather than looking at a single moment only.
Check that the intended audio source is present throughout the stream and that its clock or capture path is not being interrupted. A device change, source reconnection or application pause may be relevant if it lines up with an abrupt jump. For gradual drift, look for a repeated timing mismatch over time, not merely one unusual packet or a momentary preview discrepancy. Save logs or a short capture around the problem where your software permits it, while observing any privacy or lecture-recording requirements that apply to your setting.
CPU or encoder load, dropped frames and duplicated frames are useful context, but they are not proof of audio drift. OBS describes a video queue that can duplicate a frame when the queue is full, while audio and video packet output is interleaved separately by timestamp. A dropped or duplicated visual frame may explain a local discontinuity, but do not assume it explains a steadily increasing offset unless the recorded output supports that conclusion.
If the source is a prerecorded lecture, distinguish timing already present in the file from timing introduced by the live pipeline. Play the file locally at several points and compare its sound and picture before it enters the streaming software. A clean local file followed by a drifting encoded output shifts attention downstream; a file that already contains a growing mismatch is not repaired by changing transport settings.
Inspect audio format and processing
Confirm the source audio sample rate and channel layout, OBS audio configuration, encoder output and destination requirements. Do not assume the captured audio is passed through unchanged: OBS can remix channels or resample audio when the source format differs from the configured backend. The OBS audio documentation explains its audio handling. A mismatch is a reason to inspect the path and compare output, not enough by itself to declare the cause.
Also review filters and processing applied to the lecture audio. Noise suppression, gating, monitoring or other processing may affect what you hear or when a sound becomes perceptible, but that is not the same as proving a timestamp drift. For a controlled test, record the original filter and format settings, then bypass or adjust only a relevant item and compare the encoded result over the same kind of observation period. Restore it if the measured sync does not improve or if speech quality becomes worse.
Check that the audio source is not being captured twice through two routes, such as a direct application source and a desktop mix. Duplicate or delayed audio can sound like a sync fault even where video timing is stable. Listen with headphones to distinguish echo or a second copy from a single signal that is simply early or late. The guide to improving audio quality on a live stream can help review sound processing, but quality adjustments and synchronisation diagnosis are separate jobs.
Review transport, muxing and the receiver
The streaming protocol and receiving player affect buffering and playback, so inspect the actual path rather than borrowing settings from a different protocol. OBS maintains separate guides for WHIP/WebRTC and SRT. If your route uses RTMP, FFmpeg documents it separately as multimedia streaming over TCP/IP in its RTMP protocol documentation. These documents describe different paths; a setting recommended for one should not be carried over to another without checking the ingest service’s requirements.
For SRT specifically, OBS says its latency option defaults to 120 ms and recommends setting it to at least 2.5 times the round-trip time between the encoder and ingest server. Those are SRT transport guidance values from OBS Project documentation, not universal audio-delay values and not a fix for every kind of drift. If you change SRT latency, record the original value, measure the relevant round-trip time, and retest end-to-end. A larger buffer may change the latency and resilience trade-off; it does not establish that timestamps are correct.
For WHIP/WebRTC, verify the supported OBS version, codecs and frame rate against the specific provider’s current instructions. Cloudflare’s WHIP setup guide gives an example with OBS 31.0 or later, Opus audio and 30 fps video; that is an example for that service path, not a universal configuration. For RTMP, consult the destination’s current ingest requirements and inspect the resulting stream rather than inferring a sync cause from the protocol name alone.
Finally, compare playback on another receiver if possible. If one device or player shows growing drift while another stays aligned, inspect that receiver’s buffering and playback behaviour before altering the broadcast. If multiple receivers show the same changing offset, investigate shared upstream stages first. A receiver comparison localises the likely area; it does not prove a particular vendor or component is responsible.
Choose a targeted change and verify it
Once the evidence points to a stage, change one relevant setting at a time. Keep a note of the original value, the reason for the change and the exact observation points you will repeat. If the problem is a stable offset, a delay adjustment may be a reasonable test after checking the path. If the offset grows, do not expect one fixed delay to remove the accumulating error: first address the demonstrated timing, timestamp, format, transport or receiver behaviour.
After each change, compare the same kind of event at playback and, where available, in the encoded output. Observe long enough to see whether the rate of drift has changed, not merely whether one short section looks better. A setting that improves one session is not proof of a durable 24/7 correction until it has been observed over an appropriate operating period. If the change makes the result worse, restore the prior value and note the result rather than stacking another adjustment on top.
For a continuous lecture, make disruptive tests during a planned maintenance window or with a separate test broadcast. If you need to compare operating approaches, evaluate them on whether timestamps remain coherent from encoder to receiver, whether sync stays stable for the intended run, how recovery behaves on your actual connection, codec compatibility and whether you can monitor the stream without taking the lecture offline. Those criteria are more useful than selecting a tool on the assumption that a different hosting path will fix an undiagnosed symptom.
If you are using a prerecorded lecture and the recurring task is keeping the file available without leaving a personal computer running, StreamNeo can remove that computer-running burden; it does not replace checking that the source file itself is in sync or diagnosing a changing offset in the encoded and received stream. Keep the sync test separate from any decision about how to run the channel.
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 adding an audio delay fix gradual drift?
Not necessarily. A fixed delay changes the starting relationship between sound and picture; it does not establish why the gap is increasing over time. Measure the output before and after any adjustment and investigate the stage where the drift begins.
How can I tell whether the encoder is responsible?
Compare an encoded recording or output with the received playback, using the same visible and audible event. If the encoded output already drifts, inspect capture, timestamps, audio format and encoding; if it remains stable while a distributed copy drifts, examine ingest, transport and receiver behaviour. The comparison narrows the fault area but may not identify a single cause without logs and more detail.
Should I increase buffering or transport latency?
Only when you have identified the protocol and evidence that transport buffering is relevant. OBS’s latency guidance is specific to SRT, so it should not be treated as a general delay setting for RTMP, WHIP/WebRTC or every player. Record the original setting and verify the result at the receiver after a controlled change.
What information should I collect if the drift continues?
Record the source type, streaming software and version, audio format, protocol, destination, player, approximate offset at several elapsed times, and whether a local or encoded copy also drifts. Include relevant logs or timestamp observations if your workflow exposes them. That evidence is more useful for a case-specific diagnosis than a list of settings changed without a record.