Audio Buffer Overflow / Underflow Decklink AV1 / MP3

[sogorman]

Good afternoon. I am getting started with UltraGrid and running into an audio buffer issue. I have seen some audio issues in various threads but can't seem to get this figured out.

The test setup is using a M2 MacBook pro with a test card and 1k tone encoded with AV1 and MP3 audio. Both the audio and video have FEC.

The receiving end is a windows pc with a Decklink Mini Monitor. Both the sending and receiving side look good resource wise.

Sending command:

/Applications/uv-qt.app/Contents/MacOS/uv -t testcard:1920:1080:30:RGB -c libavcodec:codec=AV1:bitrate=1.5M:disable_intra_refresh:subsampling=422 --audio-filter controlport_stats -s testcard --audio-capture-format channels=2 --audio-codec MP3:bitrate=256k -f V:rs:200:240 -f A:mult:2 -m 1300 -P 5020 --control-port 5021 10.200.200.102 --param errors-fatal

Recieving Command: c:\UltraGrid\uv.exe -d decklink:device=0:drift_fix --audio-filter controlport_stats -r embedded -P 5020 --control-port 5021 --param errors-fatal

Here is a screenshot of the sending computer showing no errors:

Here is a screenshot of the recieving computer showing audio errors:

[alatteri]

1) what is the --audio-filter for? Doesn't seem like it actually is doing anything without adding the additional relevant parameters. 2) Are you sure the receiving CPU is not being tapped out. AV1 is a hard codec. 3) I wonder if soxr or speex are not available on Windows, so even though drift-fix is called, maybe its not actually happening? I've never run UG on Windows so I don't know its packaging.

[sogorman]

Tried removing the --audio-filter, no change.

Here is a screenshot of taskman on the receiver side, looks like the AV1 is being handed off to the GPU, system is basically idling.

I will throw a linux distro on that machine for testing and report back.

[MartinPulec]

Tried removing the --audio-filter, no change.

correct, but the source command is actually more bloated than it need to be and it actually doesn't tell clearly what you are going to achieve:

• -t testcard:1920:1080:30:RGB - will you indeed transmit RGB or rather UYVY? because default AV1 encoder libaom-av1 (neither libsvt_av1) doesn't support RGB (it gets converted to YCbCr anyways)
• -c libavcodec:codec=AV1:bitrate=1.5M:disable_intra_refresh:subsampling=422 - disable_intra_refresh shouldn't have any impact on AV1 (maybe just on NVENC)
• -m 1300 - is this really needed? If so, what are the network conditions that require that - a VPN?
• --control-port 5021 --param errors-fatal - unless needed, I'd omit that. Its presence shouldn't have an impact on the problem (and you should report a minimal (not-) working example)
• -f V:rs:200:240 -f A:mult:2 - good idea in general but it should be omitted from the report as indicated above

receiver:

• -d decklink:device=0:drift_fix - is the default behavior (without drift_fix), the same?

I wonder if soxr or speex are not available on Windows

I will throw a linux distro on that machine for testing and report back.

Not sure how it is related but speex/soxr are certainly present in Windows builds, so I wouldn't expect this issue to be platform-specific.

Are you sure the receiving CPU is not being tapped out. AV1 is a hard codec.

I agree. It may not be the root of the problem but I'd perhaps start with something less demanding like MJPEG or H.264.

Another things to try out:

• run the sender command directly on the receiver (ideally with the MJPEG/H.264, not to overwhelm the machine)

From the above most importantly – I'd be curious whether you use VPN or so. If so, UG behavior is heavily dependent upon its operation, because eg. the TCP VPN can seriously hurt frames' timing if there are retransmits and the RTT is long. If the VPN introduces jitter, let say 100 ms, it is indeed not good scenario for UG as a low latency system. I'd suggest either avoiding VPN or use at least UDP then.

[MartinPulec]

Closing for inactivity, feel free to reopen if you have updates on that.

Anyways, I'd ask you to post a minimal working/broken example demonstrating the problem - I don't believe that the whole four-liner command is necessary to reproduce the problem.