• src/xpdev/xpbeep.c

    From Deuc¿@VERT to Git commit to main/sbbs/master on Wednesday, February 07, 2024 12:23:42
    https://gitlab.synchro.net/main/sbbs/-/commit/574712547b2d63bf5dcab0f9
    Modified Files:
    src/xpdev/xpbeep.c
    Log Message:
    Another Windows warning about constiness.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Deuc¿@VERT to Git commit to main/sbbs/master on Saturday, February 10, 2024 21:49:16
    https://gitlab.synchro.net/main/sbbs/-/commit/2e2ab2510aa35d61fda176c1
    Modified Files:
    src/xpdev/xpbeep.c
    Log Message:
    Fix some warnings.

    We can't use const protection for the sample buffer because the Win32
    API takes non-const buffers. For standard implicit conversions,
    simply disable the warning where it occurs on purpose. It appears
    that MSVC builds use the equivilent of -Wconversion (which isn't even
    part of -Wall).

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Saturday, February 10, 2024 22:10:30
    https://gitlab.synchro.net/main/sbbs/-/commit/1c47d84c7c55b6f6cffc0e06
    Modified Files:
    src/xpdev/xpbeep.c
    Log Message:
    _MSC_VER is the macro name you're looking for there :-)

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Deuc¿@VERT to Git commit to main/sbbs/master on Saturday, February 10, 2024 22:28:17
    https://gitlab.synchro.net/main/sbbs/-/commit/abf1cd9ee46327a9d17cba0b
    Modified Files:
    src/xpdev/xpbeep.c
    Log Message:
    Actually remove the const the comment says I can't have.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Deuc¿@VERT to Git commit to main/sbbs/master on Thursday, February 22, 2024 06:50:40
    https://gitlab.synchro.net/main/sbbs/-/commit/63cec349ee714376a2649e5f
    Modified Files:
    src/xpdev/xpbeep.c
    Log Message:
    Remove need_copy variable when it won't be used.

    Fixes Coverity issue.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Deuc¿@VERT to Git commit to main/sbbs/master on Thursday, February 22, 2024 07:03:57
    https://gitlab.synchro.net/main/sbbs/-/commit/ea42fffa92392454971c1cfd
    Modified Files:
    src/xpdev/xpbeep.c
    Log Message:
    Keep pointers to dll_handle around to solence Coverity issues.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Deuc¿@VERT to Git commit to main/sbbs/master on Monday, September 30, 2024 20:15:08
    https://gitlab.synchro.net/main/sbbs/-/commit/3993af5cda237d9b760680c2
    Modified Files:
    src/xpdev/xpbeep.c
    Log Message:
    Since we can check at the menu now, we don't need this warning.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Deuc¿@VERT to Git commit to main/sbbs/master on Monday, April 20, 2026 23:27:36
    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
  • From Deuc¿@VERT to Git commit to main/sbbs/master on Tuesday, April 21, 2026 10:35:41
    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
  • From Deuc¿@VERT to Git commit to main/sbbs/master on Tuesday, April 21, 2026 11:24:52
    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
  • From Deuc¨@VERT to Git commit to main/sbbs/master on Tuesday, April 21, 2026 20:07:07
    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
  • From Deuc¿@VERT to Git commit to main/sbbs/master on Wednesday, April 22, 2026 00:11:54
    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
  • From Deuc¿@VERT to Git commit to main/sbbs/master on Wednesday, April 22, 2026 01:17:53
    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
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Wednesday, May 06, 2026 19:41:53
    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
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Wednesday, May 06, 2026 21:20:12
    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
  • From Deuc¿@VERT to Git commit to main/sbbs/master on Sunday, May 10, 2026 15:18:55
    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