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

[simoncos]

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: Random short audio dropouts when recording or streaming #4600, GPU and Async Delay Filters do not delay audio #9566, Short (encoding) lag can destroy A/V sync for both monitoring audio and recordings in sub systems (Render Delay filter, NDI, Teleport) #6673, OBS NDI and the "Video Delay" (Async) filter 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).

[Fenrirthviti]

Please properly fill out the issue template.

This report reads like AI hallucinations.

[simoncos]

Sorry about the format - I've updated the description with the template fields.

The log URL is from a fresh session running exactly the listed steps: three 60 s recordings of the same synthetic clip at 0/2000/10000 ms on the async delay filter (noise floor -54.1/-53.9/-9.8 dB respectively). Scripts, manifests and analysis results: https://gist.github.com/simoncos/18b4abc2749c509634aad1b5d1aeb6f2 - the 60 s recordings are available if wanted.