# Meetily's Incremental Audio Saving Mechanism with Checkpoints: Architecture and Implementation > Discover Meetily's incremental audio saving mechanism. Learn how crash-resilient checkpoints recover audio data automatically after unexpected terminations. - Repository: [Zackriya Solutions/meetily](https://github.com/Zackriya-Solutions/meetily) - Tags: architecture - Published: 2026-07-24 --- **Meetily implements a crash-resilient audio pipeline using an `IncrementalAudioSaver` struct that writes PCM chunks to rotating checkpoint files in a `.checkpoints/` directory, enabling automatic recovery by concatenating segments after unexpected terminations.** Meetily, an open-source meeting transcription tool developed by Zackriya-Solutions, handles dual audio stream recording (microphone and system audio) through a sophisticated **incremental audio saving mechanism with checkpoints**. Unlike traditional approaches that buffer entire recordings in RAM, this Rust-based implementation persists audio data incrementally to disk, ensuring no data loss occurs if the application crashes or the system loses power during a meeting. ## Core Components of the Checkpoint System The architecture centers on three primary source files that manage audio persistence, recovery, and cleanup. ### IncrementalAudioSaver Struct Located in [`frontend/src-tauri/src/audio/incremental_saver.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/audio/incremental_saver.rs), the `IncrementalAudioSaver` struct encapsulates all logic for incremental audio persistence. It maintains the meeting's target folder, audio sample rate (typically 48,000 Hz), and state for the current file handle. The struct provides the primary interface for writing chunks via `save_chunk` and creating checkpoint snapshots. ### Checkpoint Directory Structure During initialization through `IncrementalAudioSaver::new`, the saver creates a hidden `.checkpoints/` subdirectory inside the meeting folder. This directory stores partial audio fragments such as `segment_001.wav`, representing periodic snapshots of the recording. These files serve as immutable recovery points that exist independently of the final merged output. ### Recovery and Cleanup Functions The [`frontend/src-tauri/src/lib.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/lib.rs) file exposes three critical utility functions for checkpoint management (implemented around lines 620-622): - **`recover_audio_from_checkpoints`**: Scans the `.checkpoints/` directory, reads segments in chronological order, and concatenates them into a single consistent audio file. - **`cleanup_checkpoints`**: Removes the checkpoint directory and all temporary segment files after successful finalization. - **`has_audio_checkpoints`**: Checks for the existence of checkpoint data to determine if a recovery workflow is necessary on application startup. ## The Checkpoint Lifecycle The incremental saving process follows a five-stage pipeline that ensures durability without excessive memory consumption. ### Initialization When a meeting begins, the `RecordingSaver` (defined in [`frontend/src-tauri/src/audio/recording_saver.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/audio/recording_saver.rs)) instantiates an `IncrementalAudioSaver` via `IncrementalAudioSaver::new`, passing the `meeting_folder` path and `sample_rate`. This creates the `.checkpoints/` directory and prepares the working file handle for incoming PCM data. ### Real-Time Chunk Processing As audio arrives from the microphone and system sources after Voice Activity Detection filtering, each PCM chunk is forwarded to the saver through the `save_chunk` method. Rather than accumulating data in memory, the method appends bytes directly to a working buffer and underlying temporary file, maintaining a minimal RAM footprint. ### Periodic Checkpoint Creation After a configurable interval based on frame count or elapsed time, the saver flushes the current buffer to a new checkpoint file inside `.checkpoints/`. This operation creates immutable snapshots like `segment_002.wav`, ensuring that even if the process terminates immediately after, the data up to that point is safely persisted on disk. ### Crash Recovery Process If the application restarts after a crash, `recover_audio_from_checkpoints` executes automatically. The function enumerates all checkpoint files, sorts them chronologically, and streams their contents into a single final `audio.wav` file in the meeting folder. This process reconstructs the complete recording without requiring re-transcription or data re-capture. ### Finalization and Cleanup When the user stops recording, the `RecordingSaver` invokes `finalize` on the `IncrementalAudioSaver`. This method writes any remaining buffered data, closes the file handle, and calls `cleanup_checkpoints` to remove the temporary `.checkpoints/` directory, leaving only the consolidated audio file. ## Integration with the Recording Pipeline The `RecordingSaver` struct acts as a higher-level wrapper that coordinates audio flow. It holds an `Option>>` to ensure thread-safe access across async boundaries. During recording, the saver locks the mutex to call `save_chunk` for each audio frame; on stop, it acquires the lock exclusively to perform finalization and cleanup, preventing race conditions during file operations. ## Practical Implementation Example The following Rust pattern demonstrates the typical usage flow within Meetily's Tauri-based backend: ```rust use std::path::PathBuf; use std::sync::Arc; use tokio::sync::Mutex as AsyncMutex; // 1️⃣ Initialize the saver at meeting start let meeting_folder = PathBuf::from("/path/to/meeting"); let sample_rate = 48_000; let saver = Arc::new(AsyncMutex::new( IncrementalAudioSaver::new(meeting_folder, sample_rate).unwrap() )); // 2️⃣ Process incoming audio chunks during recording async fn handle_audio_chunk( chunk: Vec, saver: Arc> ) { let mut guard = saver.lock().await; guard.save_chunk(&chunk).expect("Failed to save chunk"); // Checkpoints created automatically at intervals } // 3️⃣ Finalize and cleanup when stopping async fn stop_recording(saver: Arc>) { let mut guard = saver.lock().await; guard.finalize().expect("Failed to finalize audio"); guard.cleanup_checkpoints().expect("Failed to cleanup checkpoints"); } ``` ## Benefits of Incremental Checkpointing Meetily's checkpoint-based approach provides three distinct architectural advantages: - **Crash Tolerance**: Since data is flushed to checkpoint files periodically, unexpected terminations preserve all audio up to the last checkpoint, minimizing data loss to only the most recent unflushed buffer. - **Low Memory Footprint**: The system never holds the complete recording in RAM; only small write buffers and file handles remain resident, enabling recordings of arbitrary length on resource-constrained devices. - **Fast Recovery**: Post-crash restoration requires only sequential file reads and concatenation via `recover_audio_from_checkpoints`, avoiding CPU-intensive re-processing or network re-transfers. ## Summary - Meetily's `IncrementalAudioSaver` in [`frontend/src-tauri/src/audio/incremental_saver.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/audio/incremental_saver.rs) manages incremental writes to disk via the `save_chunk` and `finalize` methods. - Checkpoint files are stored in a `.checkpoints/` subdirectory as partial WAV segments (e.g., `segment_001.wav`). - Recovery functions `recover_audio_from_checkpoints` and `cleanup_checkpoints` in [`frontend/src-tauri/src/lib.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/lib.rs) handle post-crash restoration and disk cleanup. - The `RecordingSaver` wrapper in [`frontend/src-tauri/src/audio/recording_saver.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/audio/recording_saver.rs) coordinates thread-safe access using `Arc>`. - This architecture ensures crash-resilient, memory-efficient audio recording for meetings of any duration. ## Frequently Asked Questions ### How does Meetily recover audio after a crash? When Meetily restarts, it calls `recover_audio_from_checkpoints` from [`frontend/src-tauri/src/lib.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/lib.rs). This function scans the meeting folder's `.checkpoints/` directory, reads all segment files in chronological order, concatenates them into a single PCM stream, and writes the final `audio.wav` file, effectively restoring the recording up to the last successful checkpoint. ### What is the role of the RecordingSaver in Meetily's audio pipeline? The `RecordingSaver` struct defined in [`frontend/src-tauri/src/audio/recording_saver.rs`](https://github.com/Zackriya-Solutions/meetily/blob/main/frontend/src-tauri/src/audio/recording_saver.rs) serves as the orchestration layer. It owns the `IncrementalAudioSaver` instance wrapped in an `Arc>`, forwarding each audio chunk to `save_chunk` during recording and managing the `finalize` and `cleanup_checkpoints` sequence when the meeting ends, ensuring proper resource management across async tasks. ### Where are checkpoint files stored during a Meetily recording? Checkpoint files reside in a hidden `.checkpoints/` subdirectory inside the specific meeting's folder. These files follow a naming convention like `segment_001.wav` and represent immutable snapshots of the audio stream at specific intervals, allowing the system to reconstruct the full recording even if the application terminates unexpectedly. ### How does the incremental saver minimize memory usage? The `IncrementalAudioSaver` avoids buffering entire recordings in RAM by writing PCM chunks directly to disk through the `save_chunk` method. It maintains only a small temporary buffer for the current write operation and creates periodic checkpoint files, ensuring that memory consumption remains constant regardless of recording duration, while `finalize` merges segments only at the end of the session.