Concord version
2.5.19
Operating system
Debian GNU/Linux 13.6 (trixie)
Terminal emulator
Not relevant
Graphics protocol
Unknown / not relevant
Install method
Prebuilt release (cargo-dist)
Steps to reproduce
- Install Concord 2.5.19.
- Join a Discord voice channel.
- Speak normally with voice activity enabled.
- Observe the local speaking highlight and ask another participant how the microphone sounds.
- Downgrade to Concord 2.5.18 and repeat with the same configuration.
Expected behavior
The speaking indicator should react immediately and transmitted microphone audio should sound normal.
Actual behavior
On 2.5.19:
- My speaking indicator does not activate until approximately two seconds after I start talking.
- Other participants describe my voice as extremely robotic.
- The issue is repeatable.
After downgrading to 2.5.18 with the same device and configuration, the microphone works normally again.
Logs
2026-09-12 05:22:01 UTC [DEBUG] voice: voice microphone capture started: host=pulseaudio sample_rate=48000 channels=1 format=F32 buffer_size=Default
2026-09-12 05:22:45 UTC [DEBUG] voice: voice UDP transmit stats: elapsed_ms=46083 sent_packets=32 rtp_timestamp=2354880 rtp_elapsed_ms=49060 stale_microphone_frames_dropped=1690 max_microphone_queue_depth=16 max_microphone_frame_age_ms=0 noise_suppressed_frames=389
max_noise_suppression_processing_us=177 overload_smoothed_frames=0 limited_samples=0 max_frame_gap_ms=12286
2026-09-12 05:22:48 UTC [DEBUG] voice: voice microphone capture stopped: chunks=139 frames=2277376 callback_frames_min=16384 callback_frames_max=16384 queued_20ms_frames=2225 dropped_20ms_frames=147 peak_sample=6073 clipped_samples=0
Additional context
This is a regression from #356. On my PipeWire/PulseAudio system, BufferSize::Default negotiates a two-second capture buffer:
node.latency = "96000/48000"
pulse.attr.fragsize = "384000"
callback_frames_min=16384
callback_frames_max=16384
Concord consequently filled its 16-frame queue and discarded 1,690 stale
20 ms microphone frames in 46 seconds. This causes the delayed speaking
indicator and robotic audio.
2.5.18's fixed 480-frame buffer works correctly on this machine.
Suggested fix: add a [voice] microphone_buffer_frames override so affected
users can select 480, or detect excessively large host-default buffers and
rebuild the stream with a bounded fixed size. Simply enlarging Concord's queue
would retain the two-second latency and would not fix the underlying problem.
Confirmations
Concord version
2.5.19
Operating system
Debian GNU/Linux 13.6 (trixie)
Terminal emulator
Not relevant
Graphics protocol
Unknown / not relevant
Install method
Prebuilt release (cargo-dist)
Steps to reproduce
Expected behavior
The speaking indicator should react immediately and transmitted microphone audio should sound normal.
Actual behavior
On 2.5.19:
After downgrading to 2.5.18 with the same device and configuration, the microphone works normally again.
Logs
Additional context
This is a regression from #356. On my PipeWire/PulseAudio system,
BufferSize::Defaultnegotiates a two-second capture buffer:node.latency = "96000/48000"
pulse.attr.fragsize = "384000"
callback_frames_min=16384
callback_frames_max=16384
Concord consequently filled its 16-frame queue and discarded 1,690 stale
20 ms microphone frames in 46 seconds. This causes the delayed speaking
indicator and robotic audio.
2.5.18's fixed 480-frame buffer works correctly on this machine.
Suggested fix: add a [voice] microphone_buffer_frames override so affected
users can select 480, or detect excessively large host-default buffers and
rebuild the stream with a bounded fixed size. Simply enlarging Concord's queue
would retain the two-second latency and would not fix the underlying problem.
Confirmations