https://gitlab.synchro.net/main/sbbs/-/commit/a13b771308ba74307480165b
Modified Files:
src/xpdev/xpbeep.c
Log Message:
Add missing re-lock in xptone_open_locked()

While we're here, add debug assertions to the pthread stuff.

---
ï¿­ Synchronet ï¿­ Vertrauen ï¿­ Home of Synchronet ï¿­ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/c4d40f8df8bfe47e5962a1e6
Modified Files:
src/xpdev/xpbeep.c
Log Message:
And, of course, fix the Borland build.

---
ï¿­ Synchronet ï¿­ Vertrauen ï¿­ Home of Synchronet ï¿­ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/695158804810f59a019739fa
Modified Files:
src/xpdev/xpbeep.c
Log Message:
Add some "idiomatic" idiocy for Windows.

---
ï¿­ Synchronet ï¿­ Vertrauen ï¿­ Home of Synchronet ï¿­ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/d0f1673364b87c2e9d70ce00
Modified Files:
src/xpdev/xpbeep.c
Log Message:
Fix warning.

---
ï¿­ Synchronet ï¿­ Vertrauen ï¿­ Home of Synchronet ï¿­ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/4f8d820161535a3e4ff10518
Modified Files:
src/xpdev/xpbeep.c
Log Message:
xpbeep: fix non-MT build broken by xptone rewrite

The node-FIFO mixer commit (897325cdb8) rewrote xptone() to open its
own xp_audio stream via pthread_once + assert_pthread_mutex_lock + xp_audio_open — all MT-only symbols — but xptone() sits outside the XPDEV_THREAD_SAFE guard in xpbeep.c, so non-MT builds (single-threaded
xpdev consumed by the Borland SBBS build) no longer compiled.

Split xptone() into two variants under #ifdef XPDEV_THREAD_SAFE / #else:
- MT keeps the new single-stream xp_audio_open + chunk-append path with
the stream opened at -12 dB for headroom.
- Non-MT restores the pre-rewrite per-chunk xp_play_sample16s flow and
bakes the -12 dB attenuation into the wave buffer with an inline
0.251 scale, since the non-MT path has no stream/mixer volume to
carry it.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

---
ï¿­ Synchronet ï¿­ Vertrauen ï¿­ Home of Synchronet ï¿­ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/ee221af10158c7b559e3071c
Modified Files:
src/xpdev/xpbeep.c
Log Message:
Switch to an equal-power cross-fade.

The old dB-linear cross-fade was terrible... the two samples crossed
at -30dB from the channel level (normally -12), which while perceptible
isn't exactly what people imagine when they think of a cross-fade.

The equal-power curve actually seems reasonable for all fades.

---
ï¿­ Synchronet ï¿­ Vertrauen ï¿­ Home of Synchronet ï¿­ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/77c1c5218b8d4a29a086831d
Modified Files:
src/xpdev/xpbeep.c
Log Message:
Use equal-power ramp for Volume command too.

This effectively let's you pan channels around as they play.

---
ï¿­ Synchronet ï¿­ Vertrauen ï¿­ Home of Synchronet ï¿­ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/bb2f365233ea170ef1506d92
Modified Files:
src/xpdev/xpbeep.c
Log Message:
xpbeep: hold r->mutex when reading auto_close/done in reaper (CIDs 645736, 645739)

xp_audio_open's stream-reaper loop read r->auto_close and r->done while
holding only mixer_lock, but those flags are written elsewhere
(xp_audio_stop, the auto_close setter) under r->mutex only — not
mixer_lock. Coverity flagged the inconsistent locking; in practice it
could let the reaper see stale flag values and either skip a reapable
stream (benign — gets reaped on the next open) or, if a future writer
ever clears done while close-pending, cause a missed reap.

Take r->mutex briefly to read the flags, then release it before free_stream_locked() (which destroys the mutex). Lock order
mixer_lock -> r->mutex matches xp_mixer_pull and xp_audio_close, so no
deadlock risk introduced.

This does NOT address the broader stream_from_handle()-returns-pointer
lifetime issue; that's an architectural concern for a separate change.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

---
ï¿­ Synchronet ï¿­ Vertrauen ï¿­ Home of Synchronet ï¿­ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/be3ca40eb04a5c95a761ff7d
Modified Files:
src/xpdev/xpbeep.c
Log Message:
Fix Borland C++ build of xp_audio_open()

Broken by Claude

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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>

---
ï¿­ Synchronet ï¿­ Vertrauen ï¿­ Home of Synchronet ï¿­ [vert/cvs/bbs].synchro.net