Video Delay (Async) filter degrades recorded audio (broadband grain, +44 dB noise floor) at multi-second delays; Render Delay unaffected

Operating System Info

Windows 11

Other OS

No response

OBS Studio Version

32.2.2

OBS Studio Version (Other)

No response

OBS Studio Log URL

https://obsproject.com/logs/FWIPfsDyJOt9deZd

OBS Studio Crash Log URL

No response

Expected Behavior

Rendering a source through the Video Delay (Async) filter should not change the audio of the recording/stream. Recorded audio should stay at the baseline noise floor regardless of the configured delay.

Current Behavior

With only a media source (synthetic clip: testsrc2 video + continuous 1 kHz sine) and a Video Delay (Async) filter on it, the recorded audio acquires loud broadband grain once the delay reaches ~4000 ms. At 0 and 2000 ms the recording is at the baseline noise floor. Video is unaffected. OBS process RAM also grows ~86 MB per second of delay (approx. 2.6 GB at 20000 ms).

Noise floor of the recordings (tone band 990-1010 Hz vs 40 Hz-7.9 kHz; two runs per value, variance < 0.5 dB):

Delay (ms)	Noise floor	OBS process RAM
0	-54.1 dB	839 MB
2000	-54.5 dB	1000 MB
4000	-9.8 dB	1140 MB
6000	-10.2 dB	1312 MB
8000	-9.9 dB	1491 MB
10000	-9.8 dB	1698 MB
20000	-9.9 dB	2566 MB

The Render Delay filter (gpu_delay) at the same delays keeps audio at the baseline floor (-53 dB at 20000 ms) with flat system RAM, so the fault appears specific to the async delay filter.

Steps to Reproduce

1. Generate a synthetic clip:

   ffmpeg -f lavfi -i testsrc2=size=1920x1080:rate=30 -f lavfi -i sine=frequency=1000:sample_rate=48000 -t 900 -af volume=0.3 -c:v libx264 -preset ultrafast -crf 28 -pix_fmt yuv420p -c:a aac -b:a 192k -shortest tone_repro.mp4
   

2. New scene collection; one scene with one Media Source playing that clip (no monitoring, global audio devices disabled).
3. Add a Video Delay (Async) filter to the media source and type 10000 into Delay (the field accepts typed multi-second values).
4. Start playback, record ~60 s, listen to the recording's audio (or FFT: tone band 990-1010 Hz vs noise floor 40 Hz-7.9 kHz).
5. Compare against the same recording with the filter at 0 ms.

The log above is from a fresh session running exactly this: three 60 s recordings at 0/2000/10000 ms (written at 11:52:22 / 11:53:34 / 11:54:54).

Anything else we should know?

• First noticed with a real event recording (speech), then reduced to the minimal scene above.
• Driver and analyzer scripts, plus the manifests behind the numbers above: https://gist.github.com/simoncos/18b4abc2749c509634aad1b5d1aeb6f2
• The 60 s recordings from the logged session are available on request.
• Related: #4600, #9566, #6673, DistroAV/DistroAV#194 (4 s delay breakage).
• Workaround: the Render Delay filter (gpu_delay) at the same delays keeps audio clean (-53 dB at 20000 ms, flat RAM).

Start with the Video Delay (Async) filter entry point and compare its behavior with the Render Delay (gpu_delay) filter. Reproduce the issue using the supplied ffmpeg synthetic clip and the 0, 2000, and 10000 ms delay cases, then inspect the OBS log and linked measurement scripts. Done means delayed recordings retain the baseline audio noise floor without the reported memory growth.