Feedback-detection dialog's generic wording can misdiagnose non-feedback audio bugs (found via #3834)

[mcfnord]

MY LLM WROTE:

While investigating #3834 (Input Boost integer overflow), we found that the "audio feedback" warning dialog is a plausible reason that bug went unreported for years, and that the same mechanism could hide unrelated audio bugs in the future.

What the check does today

CClientDlg::OnTimerSigMet (clientdlg.cpp:1094-1123) checks only the input level meter:

if ( bDetectFeedback &&
     ( pClient->GetLevelForMeterdBLeft() > NUM_STEPS_LED_BAR - 0.5 || pClient->GetLevelForMeterdBRight() > NUM_STEPS_LED_BAR - 0.5 ) )
{
    // mute locally and mute channel
    ...
    msgbox.setText ( tr ( "Audio feedback or loud signal detected.\n\n"
                          "We muted your channel and activated 'Mute Myself'. Please solve "
                          "the feedback issue first and unmute yourself afterwards." ) );
    ...
}

This fires whenever either input meter pegs to its top LED, for any reason. It does not check for oscillation, repetition, or anything else that would distinguish real acoustic feedback from a single loud but otherwise clean signal. The message text still tells the user to "solve the feedback issue" — pointing them at their room or mic setup, not at the app.

Why this matters beyond #3834

During #3834 we measured that Input Boost (client.cpp:1432-1433) integer-overflows and wraps polarity on boosted peaks, well below clipping level — at 10x boost, effectively every normal peak wraps. A user who hits this sees exactly the meter-pegging condition above, followed by "audio feedback ... please solve the feedback issue first." That is a plausible-sounding, wrong diagnosis: there is nothing to solve in their room, the app corrupted the signal. We think this is a reasonable explanation for why a bug from a 2021 feature (#1222) went unreported until now. Full detail and the end-to-end proof rig: #3834 (comment)

The same failure mode is not specific to Input Boost. Any future or existing send-path bug that pushes the input level meter to full scale — a mixer gain bug, a driver quirk, a bad default — would trigger the identical "audio feedback" message and the same wrong diagnosis, so it would never get reported as what it actually is.

Not proposing a specific fix — flagging this as a design/UX gap in the feedback-detection heuristic, open to how you'd want to handle it. Two directions that might be worth discussing:

• Word the dialog around what was actually detected ("input level exceeded X"), rather than asserting a cause ("audio feedback"), so users search for the right kind of problem.
• If a precise feedback detector is worth keeping, add a distinguishing signal (e.g. repeated or growing peaks over a short window) instead of a single-sample threshold, and use the level-only trigger for a differently worded warning.

Related: #3834