horuse/splitwave

1. Overall shape

Splitwave is a desktop audio router built as a Svelte frontend + Tauri shell + Rust audio engine. The UI lets users assemble an audio graph, while the Rust side owns all real audio I/O, DSP, recording, and OS-specific integration.

2. Frontend boundary

The src/ tree is the presentation layer: SvelteKit routes for the main editor, pipeline detail pages, preview, and virtual-device management. The UI is organized by feature modules such as flow, audio, pipeline, overlay, updater, and error, with shared components and icons underneath src/lib/components.

3. Graph editor and state

The flow module is the visual node editor. It renders inputs, effects, and outputs as nodes, supports undo/redo and snapshot history, and drives the user-facing model of the audio pipeline. The pipeline module holds the typed state model and the generated Rust-backed TypeScript types used by the editor.

4. Frontend-to-backend contract

The app uses Tauri commands as the bridge between UI and engine. Shared pipeline types are generated from Rust (ts-rs-style generated files in src/lib/modules/pipeline/generated), so the frontend and backend agree on node kinds, effect parameters, and recording formats.

5. Rust application core

src-tauri/src/ is the runtime backend. main.rs and lib.rs boot the Tauri app, commands.rs exposes callable operations to the frontend, state.rs stores application state, and error.rs centralizes error propagation back to the UI.

6. Audio engine pipeline

The heart of the system is src-tauri/src/audio/pipeline/ and engine.rs. Audio flows through a DAG-based pipeline where sources are normalized, resampled, processed by effects, and delivered to outputs. Supporting modules handle timing/clocking, worker execution, meters, signal representation, and file reading.

7. Inputs and capture sources

Input acquisition is split by source type and platform:

- capture/ handles system and per-app capture

- device/ handles microphone and speaker device enumeration

- system_audio/ and virtual_device/ manage OS-specific capture/loopback sources

- input_bridge.rs and playback.rs connect captured audio into the processing graph

The backend supports microphones, system audio, per-app capture, file input, and virtual-device loopback as first-class sources.

8. Effects and metering

Effects live in audio/effects/ and are implemented in Rust as DSP modules: gain, mute, balance, EQ, compressor, delay, limiter, noise gate/suppressor, reverb, saturator, LUFS/level metering, and waveform analysis. These are applied inside the pipeline, not in the UI, so the editor only configures them.

9. Outputs and encoders

The output side supports speaker/device playback, virtual-device output, and file recording. audio/encoders/ contains format-specific writers for WAV, FLAC, AIFF, MP3, Opus, and AAC; these are fed by the processed stream when the graph terminates in a recording node.

10. Platform-specific audio boundaries

The backend is heavily OS-conditioned:

- macOS: CoreAudio/HAL for device enumeration, ScreenCaptureKit for system/app capture, cpal for device I/O, and a custom AudioServerPlugin virtual driver.

- Linux: PipeWire for device I/O, capture, playback, and null-sink virtual devices.

- Windows: WASAPI via cpal, plus Windows APIs for loopback/process capture and endpoint volume. Virtual devices are not available.

11. Native macOS support code

src-tauri/native/ contains Swift and C++ support code used only on macOS. Swift is used for ScreenCaptureKit bridging and AAC encoding support, while virtual_driver/ implements the AudioServerPlugin driver that makes virtual devices appear system-wide.

12. Packaging and build-time integration

The repository is packaged as a Tauri desktop app across macOS, Linux, and Windows. build.rs coordinates native build steps, including the macOS Swift/static-library pieces. The CI/release workflows and Tauri config files split the app into platform-specific installers and capabilities.

13. Important data flow for diagrams

The main runtime path is: OS audio sources or file input → backend capture/device layer → pipeline DAG → effects/meters → output device / virtual device / recorder encoder. The UI only configures and monitors this path; it does not process audio itself.

14. Cross-cutting concerns

A few modules cut across the whole app: audio/volume controls device volume, audio/permission handles platform permission checks, audio/resample and audio/clock keep streams aligned, and the error/updater/app_info modules provide app-wide UX support. These are secondary to the audio graph but important for completeness.