Internal audio xruns when JACK output is set to sub-32ms latency

[v-fox]

mpv version and platform

Custom 0.29.0 on rolling-release openSUSE Tumbleweed GNU/Linux

Reproduction steps

Set jackd latency (\/\*\) to 8-16ms values, especially when doing heavy audio post-processing (stereo_balancer+equalizer+compressor+limiter, etc.) before actual output and output set to things like 32bit/192khz.

Expected behavior

Smooth playback with default setting.

Actual behavior

Crackling in mpv once every few minutes even though neither ALSA or JACK detect xruns. With either lower jackd latency or mpv's audio-buffer it happens more often and vice versa.

Log file

https://pastebin.com/RQpRurDd

Sample files

Anything.

[haasn]

Seems like ao_jack's process() relies on ao_read_data, which will automatically fill the rest of the buffer with silence on EOF/underrun, returning the actual number of samples written.

It's possible that this function is what's hiding the underrun from JACK. Maybe we could investigate if we can report underruns to jack (e.g. by blocking in process() until the data is done or via some other mechanism). But, actually, shouldn't underruns be reported to the terminal already? (I would assume there's some system for doing this)

FWIW, jack works fine at lower latencies for me (I typically use 256 samples but mpv will also run fine at 128 samples), even when I have e.g. loudnorm in the chain (which forces 192 kHz float).

[v-fox]

It's possible that this function is what's hiding the underrun from JACK. Maybe we could investigate if we can report underruns to jack (e.g. by blocking in process() until the data is done or via some other mechanism). But, actually, shouldn't underruns be reported to the terminal already? (I would assume there's some system for doing this)

Just recently I was searching info about difference in qjackctl's two xrun counters and stumbled upon some thread where it was said that terminal counter is more of a legacy feature and is unreliable. Something like those: http://www.rncbc.org/drupal/node/336 https://sourceforge.net/p/qjackctl/mailman/message/1132253/

FWIW, jack works fine at lower latencies for me (I typically use 256 samples but mpv will also run fine at 128 samples), even when I have e.g. loudnorm in the chain (which forces 192 kHz float).

On normal playback I also can set pretty much any latency but as soon as I roll out "the big guns" (previously mentioned stereo_balancer+equalizer+compressor+limiter combination), it's no longer sustainable. For some reason in default, async, jackd's mode globally stable latencies are much higher than with --sync option: 32ms & ~41ms for XMOS/AK4490 USB PCM/DSD (with internal oversampling of PCM to 12-50Mhz, it seems) DAC in 32b/192khz mode & ALC889 HDA in 24b/48khz mode versus 8ms & 32ms. But mpv clearly doesn't like to go lower than 32ms on my system. Firefox's PA-based output (seems to use some kind of dynamically-selected >80ms internal buffer) is also finicky (but many videos on internet have recorded xruns from microphone's ADC, so playback mishaps are not always clear) but I can't yet figure out if gstreamer-based Clementine audio player with JACK output is susceptible to this on low latencies or not, it's seems fine so far with its giant buffer.

I always redirect mpv for post-processing and never allow it to dump into output ports directly because built-in audio filters really suck in comparison, especially one for setting volume over 100%. For now I've set:

audio-buffer=1.000
audio-resample-max-output-size=8
demuxer-lavf-buffersize=384000

Seems fine for now with that but xruns are hard to notice on low period size (I've set 192 frames with 8 periods), they stand out best on long, uniform or gradual sounds. In default, async, mode increase in number of periods doesn't seem to give any positive effect, unlike the sync-mode.

[v-fox]

For now I've set:

audio-buffer=1.000
audio-resample-max-output-size=8
demuxer-lavf-buffersize=384000

Ah, no, it didn't help, today I opened 1080p video from Youtube with mostly talking and dropouts are very noticeable and frequent :(

[Dudemanguy]

Really old and before the infamous audio rewrite so whatever originally happened here certainly doesn't happen anymore (doesn't mean there aren't still bugs but the underlying cause would be totally different now).