BBS:      TELESC.NET.BR
Assunto:  src/xpdev/xpbeep.c
De:       Deuc¨
Data:     Sun, 10 May 2026 15:18:55 -0700
-----------------------------------------------------------
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) 
n
---
  mSynchronetn  hgVertrauen n hHome of Synchronet n gh[vert/cvs/bbs].synchro.net

-----------------------------------------------------------
[Voltar]