# How Meetily's AudioMixerRingBuffer Synchronizes Asynchronous Audio Streams with VecDeque > Discover how Meetily's AudioMixerRingBuffer uses VecDeque to synchronize asynchronous audio streams for seamless mixing. Learn about buffer management and sample dropping strategies. - Repository: [Zackriya Solutions/meetily](https://github.com/Zackriya-Solutions/meetily) - Tags: internals - Published: 2026-07-12 --- **TLDR:** Meetily's `AudioMixerRingBuffer` uses two `VecDeque` buffers to independently store microphone and system audio samples, applying a fixed window size constraint (≈50ms) and maximum buffer limit (≈400ms) to align asynchronous streams for synchronous mixing while preventing memory overflow through controlled sample dropping. In the Zackriya-Solutions/meetily repository, real-time meeting transcription requires capturing both microphone input and system audio output simultaneously. Because these streams arrive independently and may experience network or system jitter, the application must synchronize them before mixing. The `AudioMixerRingBuffer` struct defined in [`frontend/src-tauri/src/audio/pipeline.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/audio/pipeline.rs) implements this synchronization using Rust's `VecDeque` collections to provide O(1) push and pop operations on both ends of the sliding audio windows. ## Core Architecture of the AudioMixerRingBuffer The ring buffer manages two distinct audio sources by maintaining separate queues for each stream type. According to the source code at lines 18-23, the struct definition includes: ```rust mic_buffer: VecDeque, system_buffer: VecDeque, window_size_samples: usize, max_buffer_size: usize, ``` ### Dual VecDeque Buffers for O(1) Operations The implementation leverages **two `VecDeque` instances**—`mic_buffer` and `system_buffer`—to store incoming audio samples separately for each source. Unlike vectors, `VecDeque` provides constant-time O(1) operations for pushing and popping elements at both ends, making it ideal for the sliding window pattern used in audio processing. This design allows the buffer to efficiently discard old samples when the maximum size is exceeded while appending new incoming frames to the back. ### Window Size and Memory Constraints The constructor (lines 26-46 in [`pipeline.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/pipeline.rs)) initializes the buffer with two critical parameters derived from the sample rate: **window_size_samples** (representing approximately 50ms of audio) and **max_buffer_size** (approximately 400ms). These constraints ensure deterministic mixing chunks while preventing unbounded memory growth. When `add_samples` detects that a buffer exceeds `max_buffer_size`, it drops the oldest samples from the front of the deque, logging a warning about the overflow condition. ## Buffer Operations and Stream Synchronization The synchronization logic centers on three core methods that manage the flow from asynchronous input to synchronous output. ### Adding Samples with Flow Control The `add_samples(device_type, samples)` method (lines 49-85) appends incoming audio chunks to the appropriate deque based on the `DeviceType` enum (Microphone or System). This method enforces the memory constraints by checking the buffer length after each push; if the deque exceeds `max_buffer_size`, the implementation drains excess samples from the front. The method logs the operation status and sample counts, providing observability into stream health and buffer utilization. ### Readiness Detection with `can_mix` Before mixing can occur, the system must ensure both streams have sufficient data. The `can_mix()` method (lines 87-90) performs a simple length check, returning `true` when **either** buffer contains at least `window_size_samples` elements. This gate prevents the pipeline from attempting to mix incomplete windows, ensuring that downstream processors receive fixed-size chunks. ### Window Extraction and Zero Padding The `extract_window()` method (lines 92-139) drains exactly `window_size_samples` from each deque to create synchronized mixing windows. When one stream lags and contains fewer samples than required, the method pads the remainder with **zeros (silence)** rather than holding the last sample. This zero-padding approach prevents audible "repetition" artifacts that would occur with sample-hold interpolation, as brief silence is typically imperceptible in meeting audio while maintaining strict window alignment. ## Integration in the Meetily Audio Pipeline The `AudioMixerRingBuffer` operates within the broader `AudioPipeline` architecture. `AudioCapture` receives raw frames from the microphone and system sources, calling `add_samples()` for each incoming chunk. The pipeline's main loop (`AudioPipeline::run`) repeatedly polls `can_mix()`; when true, it invokes `extract_window()` to obtain `mic_window` and `sys_window` pairs. These synchronized buffers pass to `ProfessionalAudioMixer::mix_window`, which produces the composite audio stream sent to transcription and recording modules. This design absorbs up to 400ms of jitter per stream while maintaining lip-sync accuracy through the fixed-window extraction strategy. ## Practical Code Example The following Rust snippet demonstrates how the ring buffer handles asynchronous stream arrival: ```rust use meetily::audio::pipeline::{AudioMixerRingBuffer, DeviceType}; // Initialize buffer for 48kHz audio let mut ring = AudioMixerRingBuffer::new(48_000); // Microphone samples arrive first let mic_chunk = vec![0.1_f32; 2400]; // 50ms @ 48kHz ring.add_samples(DeviceType::Microphone, mic_chunk); // System audio arrives 20ms later let sys_chunk = vec![0.05_f32; 2400]; ring.add_samples(DeviceType::System, sys_chunk); // Check readiness and extract synchronized windows if ring.can_mix() { let (mic_win, sys_win) = ring.extract_window().unwrap(); // mic_win and sys_win are both Vec with window_size_samples elements // Proceed to ProfessionalAudioMixer::mix_window(mic_win, sys_win)... } ``` ## Summary - `AudioMixerRingBuffer` in [`frontend/src-tauri/src/audio/pipeline.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/audio/pipeline.rs) manages two asynchronous audio streams using separate `VecDeque` instances for the microphone and system sources. - The implementation enforces a **fixed window size** (≈50ms) for deterministic mixing and a **maximum buffer size** (≈400ms) to prevent memory overflow. - **O(1) push/pop operations** on `VecDeque` enable efficient sliding window management without vector reallocation costs. - The `can_mix()` method ensures readiness before processing, while `extract_window()` pads short buffers with zeros to maintain alignment and avoid audio artifacts. - Excess samples are dropped from the front of the deque when the maximum buffer size is exceeded, ensuring stable operation during network jitter or system load spikes. ## Frequently Asked Questions ### How does AudioMixerRingBuffer prevent memory leaks when one stream stops sending data? The buffer implements a **maximum buffer size** limit (approximately 400ms) in the `add_samples` method. When incoming data would cause a `VecDeque` to exceed this limit, the method automatically drops the oldest samples from the front of the queue. This prevents unbounded growth if the microphone or system audio stream becomes unresponsive, ensuring the application remains stable while logging warnings about the data loss. ### Why does Meetily use VecDeque instead of Vec for the audio buffers? `VecDeque` provides **O(1) complexity** for push and pop operations at both the front and back of the collection, whereas `Vec` only offers O(1) at the back. Since the ring buffer must frequently discard old samples from the front when enforcing memory limits and sliding the window forward, `VecDeque` avoids the O(n) shifting costs that `Vec::remove(0)` would incur, making it optimal for real-time audio processing. ### What happens when one audio stream has less data than the window size during extraction? The `extract_window` method (lines 92-139 in [`pipeline.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/pipeline.rs)) **pads the shortfall with zeros** (silence) to maintain a fixed window length. This zero-padding strategy prevents audible glitches that would occur if the last sample were held constant (sample-and-hold), as brief silence is less perceptible in speech audio than repeated samples. The method drains available samples from the deque and appends zeros to reach exactly `window_size_samples`. ### Where does the mixed audio go after extraction from the ring buffer? After `extract_window()` returns the synchronized `mic_window` and `sys_window` vectors, the `AudioPipeline::run` loop passes these buffers to `ProfessionalAudioMixer::mix_window` for combination. The resulting mixed audio stream then flows to the VAD (Voice Activity Detection) processor in [`frontend/src-tauri/src/audio/vad.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/audio/vad.rs) and the transcription engine, while [`recording_manager.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/recording_manager.rs) handles persistence of the final audio output.