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
.oggfiles 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§
- Maudio
Error - Error type returned by the maudio crate.
Enums§
- Error
Kinds - Wrapper-level error kinds.