◉ COOLJAPAN
← All posts
June 22, 2026 • 7 min read

OxiSound 0.2.0 — Pure-Rust Audio Device I/O for Playback and Capture

OxiSound is the COOLJAPAN Pure-Rust audio device I/O layer — cross-platform playback and capture over ALSA, CoreAudio, and WASAPI, plus MIDI, SMF, and OSC. A NoFFI replacement for cpal/PortAudio and raw ALSA/CoreAudio/WASAPI bindings, part of the sovereign Rust stack.

release oxisound pure-rust cooljapan noffi audio device-io playback capture

Getting sound out of a speaker — or into a microphone — should not require a C toolchain.

Today we’re releasing OxiSound 0.2.0 — the COOLJAPAN Pure-Rust audio device I/O layer: a cross-platform API for opening output and input streams over whatever the operating system happens to be running, with playback, capture, duplex, low-latency callbacks, MIDI, SMF, and OSC all in one place.

No PortAudio. No hand-rolled -sys glue against ALSA, CoreAudio, and WASAPI in three different #[cfg] arms. No build-time native dependency in your way. OxiSound speaks to the OS audio stack through a single, memory-safe Rust surface, and on every platform the right backend is selected for you.

Why OxiSound

Audio device I/O is the part of the audio stack that has resisted Rust the longest. Codecs and DSP can live happily in pure Rust, but the moment you want to actually hear something, you cross the operating-system boundary — and historically that meant linking against a native library: PortAudio, or the platform sound servers directly through ALSA on Linux, CoreAudio on macOS, and WASAPI on Windows. Each one has its own threading model, its own buffer semantics, its own ideas about sample formats, and its own way of going wrong.

That FFI boundary is exactly where memory-safety guarantees evaporate and where cross-compilation gets painful. OxiSound draws a clean line there. The OS-touching backends are isolated and auto-selected by target, the surface you program against is plain safe Rust, and the rest of your application never has to know which sound server is underneath.

OxiSound is the device I/O half of the COOLJAPAN audio story. Its sibling oxiaudio handles audio processing, DSP, and codecs; OxiSound handles getting the samples to and from the hardware. Keeping those concerns separate keeps both crates small and focused — you pull in only the layer you actually need.

What we built

OxiSound is a small workspace of focused crates, each one a clean layer:

  1. oxisound-core — the foundational traits and types: AudioDevice, OutputStream, InputStream, StreamConfig, SampleFormat, and OxiSoundError. It is no_std-capable, so the core abstractions compile in constrained environments.
  2. oxisound-cpal — the OS-backed implementation. It rides on cpal (itself pure Rust at the OS boundary) and auto-selects ALSA on Linux, CoreAudio on macOS, and WASAPI on Windows via cfg(target_os). There are no per-platform feature flags to set — the correct backend simply comes up.
  3. oxisound-midi — MIDI input and output, backed by CoreMIDI, WinMM, and the ALSA sequencer depending on the platform.
  4. oxisound-smf — a Standard MIDI File parser, writer, and playback iterator, with tempo-map handling so you can step through timed events.
  5. oxisound-osc — Open Sound Control encode/decode plus a UDP transport for talking to synths and other audio tools over the network.
  6. oxisound-session — iOS/macOS audio session management (AVAudioSession), opt-in and stubbed on non-Apple platforms.
  7. oxisound-jack — the dedicated quarantine crate for the native JACK (libjack2) C-FFI, kept entirely out of the default facade.
  8. oxisound — the public facade that ties it together, defaulting to the pure cpal backend.

The OS-backend crates sit behind COOLJAPAN’s OS-boundary governance exemption: ALSA, CoreAudio, and WASAPI are reached through cpal and selected automatically, with no feature flags exposed for them. Native JACK and PipeWire are opt-in and isolated, so the default build stays clean and self-contained.

Getting Started

Add OxiSound to your project — the default feature set is the pure cpal backend, so you get cross-platform playback and capture out of the box:

cargo add oxisound

[dependencies]
oxisound = "0.2.0"

Open the default output device and play two seconds through it:

// Play 2 seconds of silence through the default output device
let stream = oxisound::open_output(oxisound::StreamConfig::stereo_48k())?;
std::thread::sleep(std::time::Duration::from_secs(2));
stream.stop()?;

Want to actually feed samples in? The blocking write path is just as direct:

let config = oxisound::preferred_output_config(&oxisound::default_output()?)?;
let mut stream = oxisound::open_output(config)?;
stream.write(&samples)?;
stream.stop()?;

And if you need the lowest latency, the callback API hands you the buffer to fill in realtime:

oxisound::play_callback(config, |buf: &mut [f32]| {
    // fill buf in realtime — no allocations
})?;

What’s inside

Tips

Part of the COOLJAPAN ecosystem

OxiSound is part of NoFFI — the COOLJAPAN initiative to replace every C/C++/Fortran/-sys FFI dependency in the Rust ecosystem with a clean, memory-safe, 100% Pure Rust implementation. OxiSound retires PortAudio and the raw ALSA / CoreAudio / WASAPI bindings for device I/O; its sibling oxiaudio covers codecs and DSP. Together they let you build a complete audio application — from microphone to processing to speaker — without a single native audio library in the build graph. Default features are 100% Pure Rust at the OS boundary: a self-contained binary, no system audio libraries to install, nothing for a C toolchain to compile.

Repository: https://github.com/cool-japan/oxisound

Star the repo if you believe getting audio in and out of a machine should be safe, portable, and toolchain-free. 🔊

Pure Rust audio device I/O — sovereign, safe, and FFI-free.

— KitaSan at COOLJAPAN OÜ June 22, 2026

↑ Back to all posts