Audio stuttering on macOS since v0.37.0

[NextFire]

Possibly related issues/PRs:
#13676
#12643 (comment)
#13348

Important Information

Provide following Information:

• mpv version: v0.37.0-775-g9030e6a7ad
• macOS Version: 14.4.1 (23E224)
• Source of the mpv binary or bundle: binary, compiled from source
• If known which version of mpv introduced the problem: v0.37.0
• Possible screenshot or video of visual glitches: N/A

Reproduction steps

mpv <any file> --no-config

Expected behavior

No audio stuttering.

Actual behavior

Audio stutters every 20 to 60 seconds when playing any file.

I also get these kinds of errors in the macOS console:

• Healer Girl 05 (CR)

• Aqours - LIVE - Mattete Ai no Uta (VIDEO Love Live! Sunshine!! Aqours 4th LoveLive! ～Sailing to the Sunshine～ Day 2).mp4

Log file

mpv.log

(There were stutters at 0:30 and 0:40 but nothing relevant was logged)

Sample files

N/A

[NextFire]

Sorry for the confusion, I believe 0.37 introduced the bug as I downgraded to 0.36 and am no more able reproduce the issue

[m154k1]

Can you try reverting 36d5b52 and see if that helps?

[NextFire]

I can confirm reverting this commit resolved the issue

[Dudemanguy]

Probably worth reverting before the next release. I think there are various reports of audio issues that caused on macOS. cc @Akemi.

[Akemi]

i suppose we could do that. what was the reasoning behind using/introducing ao_read_data_nonblocking?

[kasper93]

It was introduced to avoid locking audio thread. /CC @t-8ch

[m154k1]

Note: ao_read_data_nonblocking works fine for avfoundation ao. Maybe this can help:

mpv/audio/out/ao_avfoundation.m

Lines 79 to 84 in ab50451

	int real_sample_count = ao_read_data_nonblocking(ao, data, request_sample_count, end_time_av - cur_time_av + cur_time_mp + time_delta);
	if (real_sample_count == 0) {
	// avoid spinning by blocking the thread
	mp_sleep_ns(10000000);
	goto finish;
	}

[kasper93]

huh, just use ao_read_data at this point...

[Akemi]

It was introduced to avoid locking audio thread. /CC @t-8ch

so it should possibly be reinvestigated in the future?

[t-8ch]

The nonblocking variant was introduced specifically for ao_pipewire as it uses a realtime audio thread, which should not be blocked.

I extended the usage to other AOs that are capable of reporting the actually available number of samples to the audio server.

If it does not work work for those other AOs should be fine to revert it.

[t-8ch]

I would be interested however why there is only one report so far.
(There was also one similar report for ao_pipewire)

It only seems to happen for very few people.

[NextFire]

Thank you!