The number of threads spawned by ma_engine_init(NULL, &engine);

[lukasz-szczur]

Hello. I load bytes of an OGG file on my own and use the following code:

if (MA_SUCCESS != ma_engine_init(NULL, &engine))
    throw std::runtime_error{"ma_engine_init failed in Audio"};

ma_decoder_config decoderConfig{};
decoderConfig.encodingFormat = ma_encoding_format_vorbis;
if (MA_SUCCESS != ma_decoder_init_memory(oggFileBytes.data(), oggFileBytes.size(), &decoderConfig, &decoder))
    throw std::runtime_error{"ma_decoder_init_memory failed in Audio"};

int const SOUND_FLAGS = MA_SOUND_FLAG_NO_SPATIALIZATION | MA_SOUND_FLAG_NO_PITCH;
if (MA_SUCCESS != ma_sound_init_from_data_source(engine, &decoder, SOUND_FLAGS, nullptr, &sound)) {
    ma_decoder_uninit(&decoder);
    throw std::runtime_error{"ma_sound_init_from_data_source failed in Audio"};
}

Will miniaudio by default create 2 threads in ma_engine_init(...)? One thread for a device and one for a resource manager?

The above code is relatively fast. I have also used stb_vorbis_decode_memory(...) to create ma_audio_buffer and decode an OGG file, but it took a lot longer to finish loading. Does the above code decode an OGG file on a device thread?

Is it possible (and OK) to entirely disable a resource manager in the code above? How to do it?

Are the following functions safe to call on a new thread that I create (no other threads execute in parallel):

• ma_engine_set_volume, ma_engine_get_volume,
• ma_sound_start, ma_sound_seek_to_pcm_frame, ma_sound_stop, ma_sound_set_looping, ma_sound_is_looping, ma_sound_set_volume, ma_sound_get_volume, ma_sound_at_end

[mackron]

If you're playing multiple sounds, it's best to have a single ma_engine object for the life of your entire program.

It creates 1 thread for the resource manager, and at least 1 thread for the internal device backend, but it could be more depending on what the backend is doing behind the scenes (miniaudio has no control over any of that). You can disable the resource manager at compile time with the MA_NO_RESOURCE_MANAGER define. It cannot be disabled at runtime.

The functions you mentioned are thread safe.

Since you're using ma_decoder as the data source, it'll be decoded dynamically on the audio thread.

[lukasz-szczur]

Thank you. I use the default configuration by calling ma_engine_init(NULL, &engine). On Android, I invoke the same ma_engine_init(...) on another variable while the first engine is still running. The first engine will be uninitialized soon after the second one starts. Is that OK? Is there any interference under the hood between two engines?

[mackron]

That should work, but it's something I would consider bad practice. The typical way to do it is have one ma_engine that you initialize once at application start up, and then uninitialize once at shutdown. Then for every sound you want to play, just initialize and uninitialize a ma_sound object. It should be one ma_engine to many ma_sounds.

Every time you initialize a ma_engine there's a lot of things going on like initializing a connection to the backend for playback, allocation of memory, starting threads, all that stuff. It's just unnecessary overhead.