Most efficient way to replay sounds?

[willdieh]

Thanks for this marvelous library!

I'm working on a game engine (isn't everyone?) and was wondering if you had any tips on the best approach to take to repeatedly replay a sound, like a bullet sound for example?

At the moment, I'm caching a single ma_decoder for each audio file, creating "Sound" objects that have a pointer to a decoder, a currentFrame counter, and use ma_decoder_seek_to_pcm_frame() to jump to their respective point in the audio file.

This lets me fire off the same sound repeatedly, with each instance played at different frame indexes within the same decoder but unfortunately, I'm guessing due to format conversion overhead between the device and audio file format (mp3), large numbers of calls to ma_decoder_seek (eg, when my machine gun is firing) causes some really bad sound performance.

I've tried loading the mp3 files into buffers and then creating a new ma_decoder (memory based) for each sound event to avoid the need to seek, and this works great, but uses more memory to hold the hundreds of ma_decoder objects (and just seems inefficient to me).

I considered using an ma_converter to pre-convert the sound file format to match the playback format and store it in a buffer but am not sure if ma_decoder (from file) already does this.

I know you're working on an audio engine API that's more geared toward gaming but its complexity with the resource manager and jobs make it hard to figure out what approach you're using there. Any tips would really be appreciated.

Thanks again, very much, for making such a fantastic tool!

[mackron]

If you're making a game engine, I've started recommending jumping in and using the engine stuff directly. It's starting to stabilize now, though there could still be some API changes here and there (no major changes or anything).

I can give you some basic details on what I do with the engine API. Basically for short sounds, I decode the file and store the decoded samples directly in memory. That memory buffer is then plugged into a ma_audio_buffer object which is significantly lighter weight than a ma_decoder. Do a search for "ma_audio_buffer;" in miniaudio.h to see it's API. You can use the ma_audio_buffer_*() functions directly for reading and seeking, or you can plug your ma_audio_buffer object straight into the ma_data_source_*() functions. I recommend the latter because that's a more general approach, and if you decide later to change your underlying data source to something other than ma_audio_buffer, you can do it without having to change all your function calls. The ma_decoder object is also a data source, which means that can also be plugged into any ma_data_source_*() API.

With the ma_audio_buffer approach, you can have a single heap-allocated buffer containing the raw decoded audio data, and then plug that into multiple ma_audio_buffer objects - you'll just have to make sure you memory manage your heap allocated buffer yourself.

Just with your comment about using a single decoder, and then implementing multiple instances by seeking everywhere - that's bad. :) You either want separate ma_decoder objects like you're doing, or something like the ma_audio_buffer solution like I mentioned.

Let me know if you have any more questions.

[willdieh]

Awesome, thanks!

[mackron]

I should clarify actually - I don't just do that decode-into-memory thing for short sounds. I do that based on a flag that the caller specifies. It's just that you would typically only use that flag for short sounds. The engine also supports streaming for longer sounds (again, controlled by a flag).

[willdieh]

Yes, I saw the streaming functionality in your engine code and assumed it used a threshold or flag of some sort. Totally awesome.