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.tsx loops over changed threads and calls playNotificationSound for each completion. Each environment has its own coordinator, so bursts can also cross environments.
threadNotifications.ts shares an AudioContext and decoded-buffer cache, but each call creates a new AudioBufferSourceNode, connects it directly to context.destination, and calls start(). 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.
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
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
mainon 2026-10-09 (revision43f8a8de17a7ac1baa7a3cf36d681856de2d8add):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.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.currentTimeand the decoded buffer's duration. Check and reserve the playback slot afterawait 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.