Windows: EBU R128 filter lag when capturing from sound card

[chrisdoernen]

Summary of the bug:

When capturing from a sound card on windows, the EBU R128 filter does not print it's metadata continuously as it is calculated (every 100ms) but rather in "chunks" every 500ms or so. This does not happen when specifying a mp3 file with the realtime flag (-re). Please see the corresponding commands below.

On Ubuntu, both variations (capturing from sound card and file) produce the same continuous output. Also, live streaming the mp3 encoded audio works fine (the commands below are shortened for the purpose of demonstration). So I think it is not a problem with my sound card/sound system.

How to reproduce:

Compare the output over time of this command

ffmpeg.exe -re -i test.mp3 -filter_complex ebur128=metadata=1,ametadata=print:key=lavfi.r128.M:file=-:direct=1 -f null -

with the output over time of the following command (adapting the input parameter)

ffmpeg.exe -y -f dshow -i audio="Mikrofonarray (Realtek High Definition Audio)" -filter_complex ebur128=metadata=1,ametadata=print:key=lavfi.r128.M:file=-:direct=1 -f null -

Observe that the output of the first command is printed smootly, one frame at a time, the output of the second command gives multiple frames at once.

Ffmpeg version:

20200306-cfd9a65 (Windows Build from Zeranoe, Static linked, 64bit)

Background info about the use case:
I am building an audio streaming application where I want to display the momentary loudness in real time as a volume meter.

[Carl Eugen Hoyos]

Please provide at least the command line(s) you tested together with the complete, uncut console output to make this a valid ticket but note that I understand your description as if you agree that there is nothing about this issue that can be fixed within FFmpeg.

[chrisdoernen]

Hi cehoyos,

thanks for replying.

I attached the console outputs of both commands. Command1.log refers to the first command with the input being a mp3 file. Command2.log refers to the second command with the input being the sound device. Please note that the actual problem can not be seen in the plain log files as one has to run the commands in order to see the difference - namely the output of the second command being printed not continuously.

I do believe that most probably there is an issue that can be fixed with ffmpeg (or the corresponding component that contains the EBU R128 filter) because I don't see the behavior described with the Linux build: Running the second command on Ubuntu (replacing dshow with alsa) gives a continuous output like the first command - and I'd expect with the second command on Windows.

I'd appreciate somebody to run these commands on their machine to prove respectively disprove that the observed behavior is related to my machine.

Best
Chris

[Gyan]

Add -audio_buffer_size 10 after -f dshow and check.

[chrisdoernen]

Hi Gyan,

with the additional argument, I see the expected, fluent output, thanks a lot!

Can you give a little background to the argument, e.g. does it make sense to have this audio buffer size as default in FFmpeg?
Right now I have to add additional logic to inject this parameter into the FFmpeg command on Windows which is not as convenient as to have the same command across all platforms (on Linux, the command seems to be unknown).

Best
Chris

[Gyan]

-audio_buffer_size is specific to the dshow input device. The default appears to be too high.