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

https://gitlab.synchro.net/main/sbbs/-/commit/830596d741d6f092be3e7aab
Modified Files:
src/xpdev/xpbeep.c
Log Message:
xpbeep: cap pathological ALSA buffer latency

Open ALSA once with the existing minimal parameter negotiation so
user and .asoundrc defaults remain authoritative when they produce
a reasonable buffer.

If the negotiated ALSA buffer exceeds 300 ms, reopen and retry with
a CoreAudio-like 3 x 1024-frame target. If the capped retry fails,
fall back to the original uncapped configuration rather than dropping
ALSA entirely.

This should kick in for whatever weird-assed distro DigitalMan uses
where the mixer latency with the default ALSA device is allegedly
around 30s.

Co-Authored-By: OpenAI Codex <codex@openai.com>

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

https://gitlab.synchro.net/main/sbbs/-/commit/0f56014594e1d842c3a3fed0
Modified Files:
src/xpdev/xpbeep.c
Log Message:
xpbeep: gaplessly hand off when a mixer buffer ends mid-pull

xp_mixer_pull() mixed only the head buffer per pull (plus a crossfade
partner). When a queued buffer was exhausted partway through a pull, the
rest of that pull was left silent and the next buffer did not start until
the following pull.

For one-shot sounds that is inaudible, but a channel fed a continuous
stream cut into back-to-back chunks -- a game door streaming Opus/PCM
through SyncTERM's A;Queue FIFO -- crosses a buffer boundary mid-pull
about four times a second at 250 ms chunks over a ~23 ms (1024-frame)
device callback. Each boundary dropped up to a full callback of silence,
heard as constant clicking/popping over the whole stream. It was masked
on backends with a very small callback (Win32 WASAPI) and obvious on the 1024-frame Linux backends (PulseAudio, PortAudio, SDL).

Fix: drain successive FIFO buffers into the same pull until it is filled
or the queue empties, so a buffer that ends mid-pull hands off to its
successor with no gap. The crossfade-overlay path (head and next mixed concurrently, one pair per pull) is preserved unchanged; a plain buffer
that drains into a crossfade pair now fills what it used to leave silent.

Verified with a hardware-free mixer harness: gapless draining across two/three/N buffers, drain-to-empty, exact buffer/pull alignment, and
consumed state carried across pulls, plus the crossfade behavior, all
clean under AddressSanitizer/UBSan/LSan.

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

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