Repository navigation
[Bug]: Simultaneous thread completion sounds become extremely loud and distorted #17439
Description
Area
Thread completion notification sounds.
Observed behavior
When four threads come back at the same time, the notification sound becomes extremely loud and distorted. This is a user report; I have not independently reproduced or recorded it.
Assumption: “come back” means the threads finish their turns and trigger completion sounds at nearly the same time.
Steps to reproduce
- Enable thread completion notification sounds.
- Run four threads in parallel.
- Have all four finish at the same time, or close enough that their notification sounds overlap.
- Listen to the combined notification sound and compare it with one thread finishing by itself.
These steps describe the reported trigger; the exact timing window has not been measured.
Expected behavior
Concurrent thread completions should produce a clear sound at a controlled volume, without a large increase in loudness or distortion. The app could coalesce simultaneous sounds or otherwise control overlapping playback while preserving each thread's completion state.
Actual behavior
The combined sound becomes extremely loud and distorted when four threads return together.
Small research: likely cause and fix
Source inspection of main on 2026-10-09 (revision 43f8a8de17a7ac1baa7a3cf36d681856de2d8add):
ThreadNotificationCoordinator.tsxloops over changed threads and callsplayNotificationSoundfor each completion. Each environment has its own coordinator, so bursts can also cross environments.threadNotifications.tsshares anAudioContextand decoded-buffer cache, but each call creates a newAudioBufferSourceNode, connects it directly tocontext.destination, and callsstart(). There is no overlap guard, gain control, or limiter.- Concurrent sources mix additively. Four synchronized copies of the same sound can produce roughly four times the amplitude (about +12 dB), which can exhaust output headroom and cause clipping. Actual peaks and clipping were not measured.
Suggested smallest fix: coalesce completion sounds in the shared audio helper across threads and environments. Track when a completion sound is scheduled to end, and skip another completion sound while that sound is active. Use context.currentTime and the decoded buffer's duration. Check and reserve the playback slot after await buffer, immediately before starting the source; checking only before the await lets concurrent calls pass the guard together. Keep per-thread toasts, desktop notifications, and completion state unchanged. Decide explicitly how input/approval alerts should behave during completion playback so urgent alerts remain audible.
If overlapping alerts must be preserved, an alternative is to route them through a shared gain/compressor stage with adequate headroom. A lower fixed volume alone does not bound loudness as the number of simultaneous sources grows. Coalescing is the simpler first fix for completion bursts.
Verification to add with a fix: trigger four simultaneous completions, including across environments and before the audio buffer finishes loading; verify one completion sound plays while all four thread notifications remain. Check that a later completion plays after the first sound ends, disabling sound during decoding prevents playback, and input/approval alerts still work. Compare single-thread and burst output levels to confirm the loudness and distortion are resolved.
This is source research and a proposed fix, not an implemented or tested repair.
Version and environment
Reported on 2026-10-09. The affected app version, operating system, sound settings, and audio output device were not supplied.
Related issue
#13625 concerns completion sounds firing before work has finished. This report concerns loudness and distortion when multiple threads return together, even if their completion events are valid. Searches of open and closed issues for sound, audio, notification sound, loud sound, and overlap found no matching report.
Evidence
No audio recording or relevant screenshot is available. No reproduction test was run.
Filed with GPT-6.1-sol via Codex in T3 Code.
Activity
juliusmarminge commentedon Oct 9, 2026
Note
Grok responding on behalf of Julius.
Report: when several threads finish close together with completion sounds on, the overlapping playback gets very loud and distorted.
Likely cause on main: each completion starts its own Web Audio buffer source at full level, with no coalesce, throttle, or gain limit.
playNotificationSounddecodes a shared buffer, thencreateBufferSource()→connect(context.destination)→start()for every call. There is no gain node and no “already playing” / cooldown guard.ThreadNotificationCoordinatorcalls that helper once per thread that newly completes (or needs input). Four threads finishing in one pass can mean four overlapping sources.silent: true, so the loudness path is the in-app Web Audio playback, not an extra system chime. Sound support landed in #11481.Overlapping full-level sources summing and clipping is a plausible explanation for the loud, distorted result; I have not measured peak levels here.
Possible fixes (hedged):
GainNode/ soft limiter so stacked sources stay under 0 dBFS.Related (not duplicates):
No open PR looks aimed at overlapping completion audio.
Ask: platform (desktop vs browser, OS), app version, and roughly how close the four finishes were (same second vs a few seconds apart).