If Wirecast audio is out of sync with video, first check whether the gap is already there at the start or steadily grows during the broadcast. A fixed offset may be corrected with a measured source delay; accumulating drift calls for investigating timing, source stability and sustained performance instead.
There is no single documented cause for every long-broadcast sync problem. Work through the signal path and compare what you see in Wirecast’s program output with what viewers receive, changing one condition at a time so you can tell what helped.
Decide whether the gap is fixed or growing
At the start of a test, choose a visible and audible event that is easy to compare: a clap, a door closing, a spoken word with a clear mouth movement, or a beat in a music video. Note whether the sound leads or trails the image, and estimate the gap. Repeat the observation at sensible intervals during a representative broadcast. You do not need a laboratory measurement; a consistent reference point is more useful than relying on memory.
If the sound is, for example, noticeably late at the beginning and remains about as late later, you are looking at a fixed offset. If it is close at first but becomes increasingly early or late, the mismatch is accumulating. It may also jump suddenly after a source reconnect, a scene change or a load spike. Record those events, because a step change is different from a smooth, gradual drift.
A source delay control changes the relative timing by a chosen amount. It can address a stable offset, but it does not make two clocks run at the same rate and should not be treated as a cure for a gap that keeps growing. Repeatedly adding delay during a broadcast can obscure the original symptom and leave the stream wrong at the next restart.
Also establish where the mismatch first appears. Check the local program output or a recording of it, then compare with the YouTube stream using a controlled viewer setup. If the local output is already wrong, investigate the Wirecast sources and settings first. If local output looks right but the viewed stream does not, keep the encoding, upload path and viewer playback conditions in the picture. Do not infer from the title alone that YouTube is causing the drift.
For a basic way to observe a pre-recorded stream remotely, see how to monitor a pre-recorded YouTube live stream. The monitoring method is not a Wirecast fix, but the principle applies: keep a repeatable observation point and record what changes over time.
Trace the source chain
Write down where the video comes from and where the audio comes from. They may share one camera or capture device, or they may be separate: a camera plus a USB microphone, a capture card plus a mixer, a Webstream source plus local audio, or several inputs combined in a Wirecast shot. Include any device or application between the original source and Wirecast. The purpose is not to assume a device is at fault, but to make the chain visible.
When audio and video enter through different paths, they may be affected by different buffering, clocking or reconnection behaviour. Historical entries in Telestream’s Wirecast version history mention sync-related fixes involving Webstream sources, USB devices and multiple inputs. Those release notes are useful prompts for deciding what to isolate; they do not show that any of those issues is the cause in your installation.
For a controlled comparison, start with the simplest scene that reproduces the problem. If the issue occurs with one camera and its own audio, record that. Then add the separate microphone or other input and compare. If you can, test each source path on its own for long enough to reveal whether the mismatch appears. Keep the same content, output settings and observation method when comparing tests.
Note whether the sources reconnect, sleep, change resolution or switch devices while the broadcast runs. A source that disappears and returns can produce a new timing relationship even if it looked correct earlier. If your scene uses multiple inputs, record which combination is active when the offset changes. Avoid replacing hardware or buying a new device just because the symptom is described as “drift”; the available evidence does not identify a universal faulty product.
Check Webstream timestamps
If one of the inputs is a Webstream source, inspect its timestamp setting in the source properties. Telestream’s Windows guide explains that source-provided timestamps may not be accurate, which can leave audio and video out of sync. The same guide allows you to choose timestamps provided by the source or generated by Wirecast; it also warns that generated timestamps can arrive late when the system is under heavy load. Neither choice is universally correct for every source and workload.
Test the alternatives rather than changing several things at once. Keep a copy of the original setting, change the timestamp option, then run the same source and content through a controlled test. Measure the gap near the beginning and later in the run. If the result improves, repeat it to check that the change is reproducible. If it worsens or merely changes the direction of the error, return to the recorded setting and investigate the rest of the chain.
The relevant discussion is in Telestream’s Wirecast 16 Windows User Guide, under Web Stream Properties. The guide is version-specific, so menu names or controls may differ in another release. Use documentation matching your installed build where available, and do not assume a timestamp option documented for Webstream sources applies to a camera or capture input.
Keep timing observations alongside the setting tested. “Changed timestamps and it looked better” is hard to reproduce later. “With this Webstream source, setting A had a small stable gap, while setting B grew during the same test” gives you and support a useful comparison without claiming that a setting will solve every system’s problem.
Look at sustained load and frame delivery
A long stream can behave differently from a short preview because the system has to keep processing and delivering frames over time. Watch Wirecast’s performance indicators during the period when sync starts to change, and note CPU use, dropped frames, source interruptions and any encoding or network warnings. A brief peak and sustained pressure are not the same observation; write down whether load stays high or coincides with the problem.
Telestream states in its technical specifications that sustained system CPU usage greater than 60% increases the likelihood of dropped frames. Treat that as a performance risk indicator, not a diagnosis of audio drift. A stream may show dropped frames without the audio mismatch steadily worsening, and sync can be wrong even when CPU use is not high. The useful question is whether the timing change and performance symptoms occur together in your test.
Check delivery capacity as well as the local machine. If available upload capacity is being exceeded, dropped or delayed video can affect what viewers see. Telestream’s Wirecast FAQ recommends checking upload and delivery capacity and testing viewing in a controlled local environment; if capacity is exceeded, it advises lowering data rate and, where appropriate, frame rate or frame size. Change settings cautiously and compare the result, because reducing quality has a visible trade-off and may not address a source-timestamp issue.
A local playback test is helpful only if it is repeatable. Use the same device and playback method when comparing the local program recording with the YouTube stream. If a viewer’s device is struggling to decode the stream, its playback can look different from the outgoing signal. That possibility does not rule out a Wirecast problem; it helps you locate whether the mismatch is already present before delivery or appears only in a particular viewing path.
If you are also checking stream capacity, the bitrate guide explains the trade-off between data rate and delivery demands. For a 24/7 setup, the guide to looping a YouTube live stream from a VPS may help you compare a different operating arrangement, but changing platforms or infrastructure is not a substitute for finding where the sync error begins.
Compare your installed version with release history
Record the Wirecast version and operating system before changing software. Then compare the installed build with Telestream’s release history, looking for notes that match your source path and symptom rather than searching only for the word “sync”. The history records a Webstream-source audio/video issue in Wirecast 15.0.3, dated 27 June 2022, changes intended to improve sync drift between USB devices in version 14.3.2, dated 4 October 2021, and an earlier fix for reported sync issues with multiple inputs.
These are historical examples, not proof that your current installation has the same defect. Check whether the affected inputs and circumstances described in the notes resemble your setup. A version change can have consequences for other parts of a working production, so review the release information and compatibility for your system before updating. If an update is appropriate, preserve your current settings and test the change outside a critical broadcast where possible.
Keep a concise record of the test: Wirecast version, operating system, source types, timestamp setting if relevant, approximate offset at the start and later, CPU and dropped-frame observations, and whether the local program recording is already out of sync. If you contact Telestream support, provide the evidence they request and include logs or a short recording when appropriate. The official FAQ discusses support information for diagnosing software problems; it does not publish a specific log recipe for this exact long-stream symptom.
For a schedule that cannot be interrupted, do not treat an untested update or a scene redesign as a live repair. Capture the current state, arrange a controlled test window, and have a rollback plan. That gives you a fair comparison and protects the working configuration while you narrow down the source of the change.
Apply delay only to a measured fixed offset
Once you have established that the mismatch is stable, use the relevant source’s audio delay or video delay control to correct it. Telestream’s Windows guide describes delay adjustments in increments as small as 1 ms. That granularity lets you make small changes, but it is not a claim that every source can be measured or corrected with millisecond precision in practice.
Make a small adjustment based on the observed direction of the error, then check the program output again with the same reference event. Confirm whether audio leads or trails before deciding which signal to move. If the offset is on one source, adjust that source rather than applying a global change that could throw other inputs out of sync. Save or document the original value so you can restore it.
Do not use a fixed delay as a way to chase accumulating drift. A delay can make the stream look right at one moment and wrong later if the mismatch continues to grow. Return to the source chain, timestamps and sustained-load checks, and examine whether the error is a gradual rate difference, a discontinuity after reconnecting, or a delivery/playback issue. Those patterns point to different investigations, even though they do not diagnose themselves.
If the source’s audio and video relationship changes from test to test, gather more evidence before settling on a delay value. A delay that is “right” for one clip, input mode or scene may not be right after the device reconnects or the scene changes. Verify the corrected output over the same kind of long run in which the fault was first noticed.
Retest over a representative broadcast
A short preview can confirm that a setting change took effect, but it cannot show whether a long-run problem has stopped. Retest for a period and under conditions that resemble the actual broadcast: the same sources, scenes, output configuration and typical background workload. Use recognisable audio/video events near the beginning and at intervals later, and note both the size and direction of the mismatch.
Keep a simple test log rather than relying on impressions. Include the time, offset estimate, active sources, timestamp option, CPU behaviour, dropped-frame indications, reconnects and any relevant output warnings. Record whether the local program output and the viewed YouTube stream agree. This helps distinguish a stable fixed offset from a trend, a sudden jump, or a discrepancy that appears only during playback.
Change one factor for each comparison. If you change timestamp mode, bitrate and scene composition together, an improved result does not tell you which change mattered. Preserve a baseline, compare a single adjustment against it, then repeat the same test if the result is important to a scheduled channel. Reproducible observations are more valuable than a long list of settings tried at random.
If the broadcast must stay live while you investigate, avoid making an unmeasured adjustment to every source. Monitor the program output and viewers’ reports, note the time any change was made, and consider whether the current error is tolerable until a controlled test window. For a pre-recorded channel, simplifying the active inputs may be a useful diagnostic comparison, but it should not be presented as a guaranteed cure for a live production built around multiple sources.
If you would rather not keep a personal computer running a pre-recorded channel overnight, StreamNeo removes that specific operating burden by turning an uploaded video into a YouTube live stream that can continue while your computer is off. It does not diagnose or repair a Wirecast source chain, and it is YouTube-only, so first decide whether your problem is the local production workflow or the sync of a Wirecast broadcast you need to keep using.
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
Why does my live stream audio slowly go out of sync?
There is no single cause established for this symptom. Compare the source chain and timestamp behaviour, then see whether the mismatch grows alongside sustained load, dropped frames, reconnects or a particular input combination. Check whether the local program output is already wrong before concluding that delivery or viewer playback is involved.
How do I fix audio delay in Wirecast?
If the gap is stable, measure its direction and use the relevant source’s audio or video delay control in small increments, then verify against the program output. If the gap grows during the broadcast, do not keep adding static delay; investigate source timing, Webstream timestamps where applicable, load and frame delivery.
Should I use source-provided or Wirecast-generated timestamps?
Test both options for the particular Webstream source rather than assuming one is always better. Source timestamps may be inaccurate, while Wirecast-generated timestamps can arrive late under heavy system load. Compare the beginning and later portions of the same controlled run.
Does a Wirecast version update guarantee the drift will stop?
No. Telestream’s release history includes historical sync-related fixes for particular source paths and versions, but those entries do not establish the cause of a current problem. Match the note to your inputs, review compatibility, and test any update in a controlled setting.