ao/coreaudio Audio underflow

[minusf]

mpv version and platform

macOS 10.14.6 mpv 0.30 from brew

Reproduction steps

Playing various format music files.

Expected behavior

No underrun.

Actual behavior

The music randomly stalls sometimes. At these times this is logged on the console. It is quite jarring, so i am fairly sure i would have noticed if 0.29 did it as well, but i have no such recollection.

AO: [coreaudio] 44100Hz stereo 2ch floatp
A: 00:00:26 / 00:05:43 (7%)
[ao/coreaudio] Audio underflow by 1420 samples.
A: 00:02:26 / 00:05:43 (42%)
[ao/coreaudio] Audio underflow by 1420 samples.
A: 00:05:43 / 00:05:43 (99%)

Listened to the same file again couple of times, no uderrun. Not really sure about reproduction steps, but probably load specific? when switching between apps? cpu spikes? just speculating.

for now i put in mpv.conf:

audio-buffer=1

but it's too early to say if it stops underflows. however the documentation was very explicit about contacting the devs if changed long term, so that's another reason why i am posting this issue.

[ghost]

Yeah, this shouldn't happen. Can you try again and confirm that it doesn't happen with 0.29 (even without the audio-buffer option), to confirm that it's not a change in your system?

[minusf]

right. let me just find a 0.29 somewhere, brew ditched versioning AFAIK

actually the brew formula came back just recently with 0.30, they switched to cask some time ago.

[Akemi]

i just looked through my terminal history and i started getting the same warnings starting on the 27th of october. i didn't hear any audio glitches. can't say wich commit i was on at that time though, but it's definitely something after 0.29.

[minusf]

lightly tested, no underflow messages so far. 0.29.1

[minusf]

i have been listening exclusively through mpv 0.29.1 for a while now and there are underruns here as well... no log message, and by far not that often, but it happens enough times to notice, maybe once an hour kind of frequency... (i listen mostly to q6-9 ogg files and flacs from local disk or usb). is there a way i could crank up the logging to catch them?

[ghost]

The messages logged by mpv are for its own ringbuffer. Maybe coreaudio has underrun within its own chain.

[cc978]

same problem frequently, with Mac Air, macOS 10.13 high sierra, mpv 0.32. and also log more :

[ ][w][cplayer] Audio/Video desynchronisation detected! Possible reasons include too slow
[ ][w][cplayer] hardware, temporary CPU spikes, broken drivers, and broken files. Audio
[ ][w][cplayer] position will not match to the video (see A-V status field).

[bpsib]

Same problem on the Android Termux app. I frequently get [ao/opensles] Audio underflow by 5512 samples. with mpv 0.32.0 which I never got in mpv 0.29.1.

It happens constantly with stalling and buffering if listening to an audio file at really high speed. I had no such stalling in 0.29.1.

(+) Audio --aid=1 (pcm_s16le 1ch 22050Hz)
AO: [opensles] 22050Hz stereo 2ch s16

Speed: 8.00
(Buffering) A: 00:00:00 / 00:48:39 (0%) x8.00
[ao/opensles] Audio underflow by 5512 samples.
Speed: 8.00
(Buffering) A: 00:00:06 / 00:48:39 (0%) x8.00
[ao/opensles] Audio underflow by 5512 samples.

A: 00:00:16 / 00:48:39 (0%) x8.00

[abbec]

I also get these when using --profile=low-latency which works fine on Linux but not on macOS.

[yuar]

Still persists with latest brew on OSX (/usr/local/Cellar/mpv/0.32.0_3 (30 files, 10.8MB))

This is easy to reproduce with ffmpeg test sequences into mpv:

# Trial feeding MPV with ffmpeg

#Input parameters
FRAME_RATE=30000/1001
GOP_LENGTH=60
V_BITRATE=1000k
A_BITRATE=32k
OUTSIZE=1280x720

# Video and Audio Encoder settings
x264enc="libx264 -pix_fmt yuv420p -tune zerolatency -profile:v high -preset fast -bf 0"
AAC="aac -ac 2 -ar 44100"

# FFMPEG Synthetic Input and Encode string forming
VIDEO_INPUT="-f lavfi -i testsrc=size=$OUTSIZE:rate=$FRAME_RATE"
AUDIO_INPUT="-f lavfi -i anullsrc=channel_layout=stereo:sample_rate=44100"
VIDEO_ENCODE="-c:v $x264enc -b:v $V_BITRATE"
AUDIO_ENCODE="-c:a $AAC -b:a $A_BITRATE"

# Launch FFMPEG, pipe into MPV
ffmpeg \
$VIDEO_INPUT \
$AUDIO_INPUT \
$VIDEO_ENCODE \
$AUDIO_ENCODE \
-f mpegts - | mpv - --profile=low-latency

[Akemi]

the whole thing doesn't play back for me. removing --profile=low-latency it works normally.

[oakkitten]

on windows, i can reproduce audio underflow (and generally stuttering playback) by simply stressing the cpu. $ stress -c 4 is all it takes to make mpv unusable. if it's focused and under stress, it stutters only a bit, but as long as i switch to another app it just stops for several seconds. this is a simple 720p avi file i'm running.

for comparison, firefox playing youtube seems to be able to survive almost any system stress.

[ghost]

No shit. low-latency may select a too small buffer size so playback can't be sustained. It's your responsibility to set a higher buffer size. If it hurts, maybe stop stabbing yourself.

[Akemi]

i can also observe this on macOS, eg high CPU usage might cause audio underflows.

so i tested this down to version 0.25 (no underflow messages since that message was added way later) and just --audio-buffer=0 (any file) always makes mpv stuck completely. adding --no-audio obviously makes it work again. i guess it is a bit unexpected that it stalls the whole playback in the case of --audio-buffer=0.

[rgaufman]

I'm experiencing the "Audio device underrun detected." on the Macbook M3 Max, especially when altering the playback speed, but CPU load is <60% so it shouldn't be CPU related?

I'm trying with --audio-buffer=1 and so far it seems to be working correctly.