mirror of
https://github.com/mpv-player/mpv.git
synced 2024-09-20 03:52:22 +02:00
39f7f83351
[motivation] Seeking on MacOS appears to be lagged when users connect to wireless audio output (airpods for example). This commit attempts to fix mpv-player/mpv#10270 [observation] 1. When using other media player (VLC to be exact) simultaneously, the lagging on seek disappear. We could guess that the AudioDevice is on some sort of "warm-up" state. See mpv-player/mpv#9243 for detailed description. 2. `AudioOutputUnitStart` takes significant longer time after each seek or pause/play when using wireless output devices compares to wired devices. [rationale] After investigate codes in ao_coreaudio.c, it appears that the the `stop` function was used as `ao_driver.reset` function. Therefore every seek and pause would call `AudioOutputUnitStop`. It turns out that `ao_driver.reset` function is used in `ao_reset`. And `ao_reset` function is used to clean up the state of current `ao` so I think `AudioUnitReset` is more proper than `AudioOutputUnitStop` under this semantics. Since ao_coreaudio use pull base mechanism, audio playback behaviors upon pause/seek could be handled by callback function (streaming silence when paused) so there is no need to stop AudioUnit when resetting. Therefore using `AudioUnitReset` as `ao_driver.reset` looks proper. Additionally, after using proper reset, the AudioUnit that represents hardware I/O devices doesn't need to be restart everytime seek/pause actions happen. Restarting wireless devices simply takes longer in MacOS which is the root cause of lagging observed by users when they seek or pause/play media. [method] Use `AudioUnitReset` for ao_driver.reset. |
||
|---|---|---|
| .. | ||
| decode | ||
| filter | ||
| out | ||
| aframe.c | ||
| aframe.h | ||
| chmap_avchannel.c | ||
| chmap_avchannel.h | ||
| chmap_sel.c | ||
| chmap_sel.h | ||
| chmap.c | ||
| chmap.h | ||
| fmt-conversion.c | ||
| fmt-conversion.h | ||
| format.c | ||
| format.h | ||