Skip to main content

Crate maudio

Crate maudio 

Source
Expand description

maudio is an audio library built on top of miniaudio, providing both a high-level playback-focused API and the foundation for a more flexible low-level interface.

At the high level, audio is driven through an Engine, which offers a simple and ergonomic way to play sounds without requiring manual audio processing or buffer management.

The Engine is designed primarily for playback. It does not currently support recording, loopback, or full duplex operation, and it intentionally hides much of the complexity exposed by the low-level API. A lower-level, more flexible interface is planned and under active development.

Under the hood, the engine consists of:

  • ResourceManager: It is responsible for loading sounds into memory or streaming them. It is also responsible for refence counting them to avoid loading sounds into memory multiple times. It also has a Decoder and can decode audio either before or after it is loaded into memory.
  • NodeGraph: It is a directed graph of audio processing units called Nodes. Nodes can be audio sources (such as sounds or waveforms), processing units (DSP, filters, splitters), or endpoints. Audio data flows through the graph from source nodes, through optional processing nodes, and finally into the endpoint.
  • Device: An abstraction of a physical device. Represents the audio playback device and is responsible for driving the engine. Internally, it runs a callback on a dedicated audio thread, which continuously requests (pulls) audio frames from the engine. The engine, in turn, processes the node graph to produce the requested audio data.

By default, sounds created from an Engine are automatically connected to the graph’s endpoint and played in a push-based manner. Audio generation, mixing, and playback are handled internally by the engine, so users do not need to manually pull or read audio data.

While basic playback can be achieved without interacting directly with the NodeGraph, more advanced setups allow nodes to be explicitly connected, reordered, or routed through custom processing chains.

Most types in maudio are constructed using a builder pattern, enabling additional configuration at creation time while keeping common use cases straightforward.

In addition to the high level Engine API, maudio exposes a low level interface for working directly with the core audio building blocks. While the high level API provides a ready-to-use playback system, the low level API gives you the components needed to build your own. This includes manual control over devices, audio graphs, data sources, decoding, and resource management.

The two APIs are closely related: the high level engine is built using many of the same concepts exposed by the low level API, but organizes them into a simpler, playback-focused workflow.

The low level API includes:

  • Context for initializing the audio backend and enumerating devices.
  • Device for creating playback, capture, loopback, or duplex streams with direct control over the audio callback.
  • Decoder for reading audio from encoded formats.
  • Data sources as a unified interface for producing PCM frames.
  • Audio buffers for working with decoded PCM data in memory.
  • Utility primitives such as ring buffers, fences, and notification systems for real-time and asynchronous coordination.

Use the low level API when you need full control over how audio is generated, processed, or delivered, or when building abstractions on top of maudio.

§Feature flags

This crate builds and links the vendored miniaudio C library and exposes raw FFI bindings.

§Engine

The Engine (and the high level API) is enabled by default. It can be disabled when building the crate with --no-default-features, or when importing the library using default-features = false:

maudio = { version = "...", default-features = false }

Disabling the Engine can reduce binary size and memory usage on platforms where the Engine is not needed.

When supplying your own static libraries (via the supplybin feature), this should be paired with the MA_NO_ENGINE, MA_NO_NODE_GRAPH and MA_NO_RESOURCE_MANAGER compile-time flags when compiling miniaudio.c

§vorbis

Enables Ogg/Vorbis decoding by compiling the stb_vorbis implementation into the miniaudio translation unit.

  • Vorbis .ogg files can be decoded via miniaudio’s decoding APIs.

§generate-bindings

Generates bindings at build time using bindgen.

  • Intended for maintainers when updating the vendored miniaudio version.
  • Regular users should prefer the pre-generated bindings shipped with the crate.
  • Adds a build dependency on via bindgen.

§worklet (Audioworklet - emscripten)

The worklets feature enables AudioWorklet support when building for Emscripten. AudioWorklets allow audio processing to run in a dedicated audio thread, which can provide more reliable, low-latency audio processing in the browser.

Only works for target wasm32-unknown-emscripten.

§debug-build

Enables debug logging at compile time. Unlike Log, this prints all log messages from every engine, device, and context.

This feature does not work when using prebuilt static libraries. They would need to be compiled with the MA_DEBUG_OUTPUT flag.

Use Log instead.

§use-global-allocator

Enables using Rust’s global allocator for allocations performed by miniaudio.

When enabled, miniaudio receives allocation callbacks that forward allocations to Rust’s GlobalAlloc interface. If the application does not define a custom global allocator, Rust’s default global allocator is used.

This feature does not install or replace the application’s global allocator. To use a custom allocator, define it in the application with #[global_allocator].

§Using the allocator API

The optional allocator_api feature enables support for selecting a specific allocator through Rust’s allocator API. This feature depends on Rust’s unstable allocator_api feature and may therefore require a nightly compiler.

Enabling allocator_api allows the global allocator used by this crate to be configured with an allocator other than the default global allocator. The selected allocator must remain valid for as long as miniaudio may use it.

Modules§

audio
Audio-related types and utilities
backend
Audio backends supported by miniaudio.
context
Audio backend context and device discovery.
data_source
Interface for reading from a data source
device
Audio device abstraction and control.
encoder
Audio file encoding.
engine
High level audio engine.
logging
Logging support for miniaudio objects.
pcm_frames
PCM format abstraction and utilities.
sound
Sound playback primitives.
util

Structs§

MaudioError
Error type returned by the maudio crate.

Enums§

ErrorKinds
Wrapper-level error kinds.

Type Aliases§

MaResult