|author||wm4 <wm4@nowhere>||2020-06-02 20:43:32 +0200|
|committer||wm4 <wm4@nowhere>||2020-06-02 20:43:49 +0200|
It's conceivable that ao->driver->reset() will make the audio API wait for ao_read_data() (i.e. its audio callback) to return. Since we recently moved the reset() call inside the same lock that ao_read_data() acquires, this could deadlock. Whether this really happens depends on how exactly the AO behaves. For example, ao_wasapi does not have this problem. "Push" AOs are not affected either. Fix by moving it outside of the lock. Assume ao->driver->start() will not have this problem. Could affect ao_sdl, ao_coreaudio (and similar rotten fruit AOs). I'm unsure whether anyone experienced the problem in practice.
Diffstat (limited to 'player/lua.c')
0 files changed, 0 insertions, 0 deletions