Source: Performance review for v0.2.0.
`src-tauri/src/audio/capture.rs` — every cpal input callback allocates a fresh `Vec` (via `chunks(...).collect()` or `data.to_vec()`) and pushes it through an unbounded `mpsc::channel`. At 48 kHz / 256-frame buffers that's ~187 allocations/sec on the realtime audio thread; a single malloc stall causes glitches/dropouts. The unbounded channel also means a writer-thread stall (disk hiccup, slow encoder lock) lets the queues grow indefinitely (~384 KB/s/channel) on long meetings.
Recommendation:
- Switch to a buffer pool (e.g. `crossbeam_queue::ArrayQueue<Vec>`) recycled by the writer thread, or send refcounted slabs.
- Use a bounded `sync_channel`/`crossbeam-channel` and drop+log on full so the audio thread never blocks.
Touched files: `src-tauri/src/audio/capture.rs`
Source: Performance review for v0.2.0.
`src-tauri/src/audio/capture.rs` — every cpal input callback allocates a fresh `Vec` (via `chunks(...).collect()` or `data.to_vec()`) and pushes it through an unbounded `mpsc::channel`. At 48 kHz / 256-frame buffers that's ~187 allocations/sec on the realtime audio thread; a single malloc stall causes glitches/dropouts. The unbounded channel also means a writer-thread stall (disk hiccup, slow encoder lock) lets the queues grow indefinitely (~384 KB/s/channel) on long meetings.
Recommendation:
Touched files: `src-tauri/src/audio/capture.rs`