gramps
47f409f0e4
Measured on the creator's recording (ty-20261112-1118-423-0000-2.mp4), which drifts out of sync over ten seconds: wall clock (pump start -> audio stop) 9.875 s video: 594 frames, uniform 1/60 9.888 s correct audio: 485,376 samples @ 48 kHz 10.112 s +2.1%, 224 ms long So it was not VFR and not wall-clock PTS: the video is CFR and matches the clock (the only PTS anomaly in the file is one 38 ms gap from two lost frames). The audio track is what was too long, and a static offset cannot fix a rate error — which is why the opening looked aligned (the 175 ms mic delay cancels the camera's constant pipeline latency) and the end did not. Cause: LiveLoopAsync wrote a fixed 480 frames per iteration and trusted that each iteration was 10 ms. Under a raised timer resolution they land near 9.8 ms — 102 ticks per second where 100 are expected, i.e. 102% of an audio second per wall second. FFmpeg stamps audio by sample count, so every second of show pushed the sound ~2% later against a correct picture. Video never had the bug because the pump paces off a stopwatch. Fix: Services/Audio/AudioClock asks the clock how many frames are owed (expected - produced, clamped to one 200 ms chunk) and the loop produces exactly that, padding on underrun. A stalled loop pays its debt over the following ticks instead of dumping one huge write. FillAndMix takes a frame count, and the master limiter/meter take spans, so a partial chunk is processed without touching stale buffer tail. 674 tests (one log-rotation flake under full-suite load while the app itself is running and writing startup.log; passes alone), 0 warnings. Ear check pending.
35 lines
1.8 KiB
C#
35 lines
1.8 KiB
C#
using System;
|
|
|
|
namespace ytLive.Services.Audio;
|
|
|
|
/// <summary>
|
|
/// How many frames the mix must produce <i>now</i>, derived from the monotonic clock rather than from a
|
|
/// tick count.
|
|
///
|
|
/// <para><b>Why this exists (2026-11-12):</b> the live loop used to write a fixed 480 frames per
|
|
/// iteration and trust that every iteration was 10 ms. It is not: `Task.Delay` plus processing lands
|
|
/// near 9.8 ms under a raised timer resolution, and 102 ticks per second where 100 are expected is
|
|
/// 102% of an audio second per wall second. FFmpeg stamps audio by sample count, so the track comes out
|
|
/// longer than the show and the sound slides later against a correct picture — measured on a 9.9 s
|
|
/// recording: video 9.888 s (right), audio 10.112 s (+2.1%, 224 ms).</para>
|
|
///
|
|
/// <para>The video side never had this bug because the pump paces off a stopwatch. This is the audio
|
|
/// equivalent: ask the clock what should exist, produce the difference, pad on underrun. Pure, so the
|
|
/// drift case is a test rather than a listening test.</para>
|
|
/// </summary>
|
|
public static class AudioClock
|
|
{
|
|
/// <summary>
|
|
/// Frames still owed at <paramref name="elapsedSeconds"/>: expected-minus-produced, clamped to
|
|
/// 0..<paramref name="maxFrames"/>. Zero means "not due yet"; the cap keeps a stalled loop from
|
|
/// dumping a huge burst in one write (the deficit stays owed and is paid off over the next ticks).
|
|
/// </summary>
|
|
public static int FramesDue(double elapsedSeconds, long framesProduced, int sampleRate, int maxFrames)
|
|
{
|
|
if (elapsedSeconds <= 0 || sampleRate <= 0 || maxFrames <= 0) return 0;
|
|
var expected = (long)Math.Round(elapsedSeconds * sampleRate);
|
|
var debt = expected - framesProduced;
|
|
return (int)Math.Clamp(debt, 0L, maxFrames);
|
|
}
|
|
}
|