I'm bundling 3 projects in one as they are all related and dependencies of each other.
maudio
maudio has had a few big improvements over the last month or so. Some things are stuff I've procrastinated about, but others are feature I've been working on for a while.
- My favorite feature, the custom decoder has been added. It allows you to use a 3rd party decoder to expand the formats supported and let you control it with from the maudio api. Implementing this almost broke me, but I've simplified the interface from C by a lot and I am pretty happy with how it looks. Examples here and here for a symponia decoder implementation.
- The cross platform compatibility has improved a lot. Android and iOS still need some testing, but I'll need some hardware for that. Until then, I think the current targets should cover almost all usage.
- Pre-gen bindings now exist for all mainstream targets and static libraries for miniaudio are also available separately on the release section on github. They are a bit too large to include in the project, but easy to add and also include instruction how to generate them yourself.
- The high level API - Engine, NodeGraph, Sound had their API re-designed to make it much more ergonomic, and almost all lifetimes removed. The first implementation was a bit restrictive, and I eventually got a better understanding of their thread safety model in C.
- The ResourceManager is now a lot more useful and thread-safe. Example. Its great at loading audio in a thread and playing it in another and managing loaded audio for multiple engines / devices.
auditorium
This project existed for almost as long as maudio, in one form or another, mostly as a local testing ground. But it developed into its own crate to abstract over maudio. Everything in auditorium lives in a control thread and is controlled with a queue. The main objective was to get maudio to a state where this can be implemented in 100% safe rust (self referential structs who?). It does a lot, but still barely touches the full capabilities of miniaudio.
Notable points:
- almost all types exposed are send, sync and clone.
- It supports most relevant targets out of the box.
- supports both capture and playback
- both device types use a nodegraph, so the same dsp chaining system and audio sources work on both capture and playback.
- all the dsp types available by maudio are available and can be applied to all sources (including the capture device itself). A bit rudimentary for now, but I have ideas how to improve it.
- supports audio (decoder backed) source, pulse, noise and wave generators.
- it comes with a built-in sympnonia decoder
- my favorite convenience, a
device.is_producing()that tells you if any audio sources produce frames (only on playback device for now).
audctl
Nothing too notable here, just a cli app. Except maybe to show how easy it was to use auditorium to handle the audio part.
I needed to build something with auditorium and this felt like something I could see muself using. A really simple, no nonsense app to play and record audio, without leaving the command like environment.
Both auditorium and audctl were made to improve maudio. Some issues in maudio only became relevant until I was implementing audctl - 2 dependents down. Hopefully, this ironed out a lot of issues so users don't have to deal with them. Maybe I'll be able to rest a bit.