https://gitlab.synchro.net/main/sbbs/-/commit/412828ad24fe4868c84fa62e
Modified Files:
src/xpdev/xpbeep.c
Log Message:
xpbeep: init mixer_lock from xp_mixer_pull too, not just xp_audio_open
mixer_lock is initialized lazily via pthread_once(&mixer_once, ...) in xp_audio_open. The pull side (push-backend device threads, pull-
backend callbacks like the WASAPI render thread) was relying on at
least one xp_audio_open having run first to set the mutex up. That
held for ANSI-music / APC patches because those paths always open at
least one xp_audio stream before producing samples, but the OOII
enable path just calls xptone_open() with no stream, and on Win32 the
WASAPI render thread fired before the mixer once-init had ever run.
First xp_mixer_pull call locked an uninitialized mutex and the SEH
exception terminated the whole process.
POSIX is more forgiving about zero-initialized pthread_mutex_t values
so the same call path didn't crash there, but it was still
technically uninitialized. Calling the once-init from xp_mixer_pull
makes the mutex safe regardless of which side runs first.
Fixes ticket 249.
Co-Authored-By: Claude Opus 4.7 (1M context) <
noreply@anthropic.com>
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)