From bb7a6abe70e2d109ad7e955005ce1aa91bb973e7 Mon Sep 17 00:00:00 2001 From: Joe DiPrima Date: Sat, 1 Aug 2026 10:42:12 -0500 Subject: [PATCH] #32: correct the stale "no field complaints since" note + record the frame-time A/B Found while checking whether a player had reported this before: the code already carried a prior analysis of this exact error which deliberately decided NOT to act on it, concluding the 2026-07-23 atomic-delete fix (a999e5c) had settled it with "no field complaints since", and that the remaining exhaustion was transient and likely sub-perceptual. That claim did not hold, and the note was still sitting there to mislead the next reader. All five 4.11.674 player logs are saturated: 3031/4657/5245/6275/6571 failures, first one ~10% into a match, still failing at 97%. The prior note's core reasoning was about raising the source BUDGET -- more voices mixing = more CPU during heavy combat -- and it is sound; BT_AUDIO_SOURCES stays opt-in and unset. But it does not apply to pooling, which changes no budget: idle pooled sources are stopped and detached and cost nothing to mix. The note asks whoever touches this to measure frame time, so I did, same bench both ways: pre-fix 8.672 ms weighted avg over 9390 frames post-fix 7.794 ms weighted avg over 10047 frames Removing ~20k alGenSources/alDeleteSources driver calls per match is a net CPU WIN, not a cost. Single run each, so indicative rather than definitive, but it points the opposite way from the concern. Co-Authored-By: Claude Opus 5 (1M context) --- engine/MUNGA_L4/L4AUDRND.cpp | 27 +++++++++++++++++++++------ 1 file changed, 21 insertions(+), 6 deletions(-) diff --git a/engine/MUNGA_L4/L4AUDRND.cpp b/engine/MUNGA_L4/L4AUDRND.cpp index e6241c5..4537c29 100644 --- a/engine/MUNGA_L4/L4AUDRND.cpp +++ b/engine/MUNGA_L4/L4AUDRND.cpp @@ -395,12 +395,27 @@ void // DPLIndependantEffect voices, and while the pool is pinned every new // acquire fails outright and that sound is silently dropped. // - // ⚠ OFF BY DEFAULT, DELIBERATELY. Raising the cap is NOT a free win, and - // the reported dropout was already fixed on 2026-07-23 by a999e5c (the - // atomic-delete leak) -- no field complaints since. What remains in the - // night-5 logs is transient exhaustion at the peak of a firefight, where - // a dropped voice competes with ~256 already sounding, so it is very - // likely sub-perceptual. Against that: the 256 ceiling also acts as a + // ⚠ OFF BY DEFAULT, DELIBERATELY. Raising the cap is NOT a free win. + // + // ⚠⚠ UPDATE 2026-08-01 (#32): the "no field complaints since" claim below + // did NOT hold. Every 4.11.674 player log is saturated -- 3031/4657/5245/ + // 6275/6571 failures across five machines, first failure ~10% into a match + // and still failing at 97%. The root cause was NOT the source budget at + // all: RequestAudioChannels was alGenSources'ing per sound event and + // ReleaseSourceSet alDeleteSources'ing on release, so combat CHURNED + // through the ceiling. Sources are now POOLED and recycled (see + // BTAudioPoolAcquire below), which fixes it WITHOUT touching this budget. + // Measured on the same bench: frame time went 8.67ms -> 7.79ms over ~10k + // frames, i.e. removing the churn is a net CPU WIN, so the governor + // argument below does not apply to pooling. The reasoning about raising + // the CAP (more voices mixing = more CPU) still stands on its own, which + // is why BT_AUDIO_SOURCES remains opt-in and unset by default. + // + // (Historical:) the 2026-07-23 fix a999e5c addressed the atomic-delete + // leak. What remained in the night-5 logs is transient exhaustion at the + // peak of a firefight, where a dropped voice competes with ~256 already + // sounding, so it is very likely sub-perceptual. Against that: the 256 + // ceiling also acts as a // GOVERNOR. The steal loop only steals when the incoming source outranks // a running one, so a higher cap means many more voices mixing at once -- // with EFX reverb + the lowpass chains live, that is real CPU, spent