clownacy/clownaudio

Sound engine that is suitable for video games and other multimedia applications.

clownaudio's Issues

Format negotiation

clownaudio should negotiate with the decoder and playback backends over what formats and sample rates to use. For example, SDL2 allows you to fetch a 'preferred' output sample rate, but right now clownaudio just forces a default of 48000Hz. Likewise, the libxmp-lite and PxTone decoder backends are also locked to 48000Hz, when they can just be set to whatever the mixer is using.

Stop using mutexes

Apparently using mutexes in an audio callback is a stupid idea, because of stuff like priority-inversion. I never liked using them anyway, since the ones in clownaudio are locked to Windows and POSIX.

Supposedly I should look into lock-free buffers or something. Maybe I can set up a kind of communication system where the main thread only gives commands to the audio callback, instead of modifying shared data - that way, the audio callback is solely-responsible for modifying its private data, avoiding conflicts.

If sound data is unloaded, all sounds using it should be stopped

If you load sound data, create a sound from it, play the sound, and then free the sound data while it's playing, the sound will continue trying to play and cause a crash.

Add backend-specific functions for checking if a file is in its format

Right now clownaudio just uses the backend's 'Create' function to see if the loaded file is in that backend's format, but that's a whole lot of overhead.

Certain libraries (I think libVorbis is one of them) have specific functions for testing if the provided buffer contains valid data. Using those would be nice.

Backends whose libraries don't provide such a feature can still rely on the old 'just try opening the file' trick.

Stop using file paths for audio data input

clownaudio shouldn't assume all audio data will be sent through file I/O - instead, it should support data being passed as memory buffers.

This will completely-break the file-type auto-detection, which relied on reading the file extension. It didn't work that great anyway: for example, '.ogg' specifies the Ogg container, but not what encoding format is used (Vorbis and FLAC are just two possibilities), so I'm not too upset about that. Maybe the user should specify the file format instead.

Add sequencer features

Supporting panning and sample-rate-overriding would make clownaudio suitable for sequenced file formats, like Organya.

Add ability to disable dynamic resampling

Maybe make it so you can explicitly define whether a sound can be dynamically-resampled or not, so that the resampler can be configured appropriately, potentially-reducing overhead.

Also, this would allow the synthesised backends to use the native sample rate, instead of a hardcoded one, in the event that they're not dynamically-resampled.

Use a memory pool for sound objects?

Using free in the middle of the mixer isn't a great idea: there's no guarantee free isn't super slow and won't stall the audio thread. Rather, it might be worth looking into allocating sound objects from a memory pool. The size of this memory pool can be specified by the user during initialisation.

However, there is the issue of multiple threads accessing the pool at once, so mutexes might be needed. But as I went over in #1, mutexes are bad. I'll have to come up with a mutex-less solution.