diff --git a/docs/examples/engine_advanced.html b/docs/examples/engine_advanced.html index d0806662..95d0323f 100644 --- a/docs/examples/engine_advanced.html +++ b/docs/examples/engine_advanced.html @@ -500,6 +500,9 @@ might be a local co-op multiplayer game where each player has their own headphon ma_device_uninit(&devices[iEngine]); } + /* The context can only be uninitialized after the devices. */ + ma_context_uninit(&context); + /* Do the resource manager last. This way we can guarantee the data callbacks of each device aren't trying to access and data managed by the resource manager. diff --git a/docs/manual/index.html b/docs/manual/index.html index df36f815..774b7b51 100644 --- a/docs/manual/index.html +++ b/docs/manual/index.html @@ -821,7 +821,7 @@ Sounds should be uninitialized with ma_soun Sounds are not started by default. Start a sound with ma_sound_start() and stop it with ma_sound_stop(). When a sound is stopped, it is not rewound to the start. Use -ma_sound_seek_to_pcm_frames(&sound, 0) to seek back to the start of a sound. By default, starting +ma_sound_seek_to_pcm_frame(&sound, 0) to seek back to the start of a sound. By default, starting and stopping sounds happens immediately, but sometimes it might be convenient to schedule the sound the be started and/or stopped at a specific time. This can be done with the following functions:
@@ -1379,6 +1379,66 @@ miniaudio's data conversion and/or decoding APIs.+MA_NO_RESOURCE_MANAGER + +
++ + +
++ + +
++ + +
++ + +
++ + +
++Disables the resource manager. When using the engine this will +also disable the following functions: + +
++ma_sound_init_from_file() +ma_sound_init_from_file_w() +ma_sound_init_copy() +ma_engine_play_sound_ex() +ma_engine_play_sound() +
+The only way to initialize a ma_sound object is to initialize it +from a data source.
++MA_NO_NODE_GRAPH +
++Disables the node graph API. This will also disable the engine API +because it depends on the node graph.
++MA_NO_ENGINE
++Disables the engine API.
+MA_NO_THREADING
@@ -1399,7 +1459,7 @@ MA_NO_THREADING Disables the ma_thread, ma_mutex, ma_semaphore and ma_event APIs. This option is useful if you only need to use miniaudio for data conversion, decoding and/or encoding. Some -families of APIsrequire threading which means the following +families of APIs require threading which means the following options must also be set: @@ -2585,7 +2645,7 @@ not have any notion of a data source, anything relating to a data source is unav-Internally, sound data is loaded via the ma_decoder API which means by default in only supports +Internally, sound data is loaded via the ma_decoder API which means by default it only supports file formats that have built-in support in miniaudio. You can extend this to support any kind of file format through the use of custom decoders. To do this you'll need to use a self-managed resource manager and configure it appropriately. See the "Resource Management" section below for @@ -2610,7 +2670,7 @@ The resource manager is mainly responsible for the following:
@@ -2728,7 +2788,7 @@ config.flags = MA_RESOURCE_MANAGER_FLAG_NON_BLOCKING; ma_result result = ma_resource_manager_next_job(pMyResourceManager, &job); if (result != MA_SUCCESS) { - if (result == MA_NOT_DATA_AVAILABLE) { + if (result == MA_NO_DATA_AVAILABLE) { // No jobs are available. Keep going. Will only get this if the resource manager was initialized // with MA_RESOURCE_MANAGER_FLAG_NON_BLOCKING. continue; @@ -2772,7 +2832,7 @@ config.pVFS = &vfs; This is particularly useful in programs like games where you want to read straight from an archive rather than the normal file system. If you do not specify a custom VFS, the resource manager will -use the operating system's normal file operations. This is default. +use the operating system's normal file operations.
@@ -3230,7 +3290,7 @@ miniaudio's routing infrastructure follows a node graph paradigm. The idea i node whose outputs are attached to inputs of another node, thereby creating a graph. There are different types of nodes, with each node in the graph processing input data to produce output, which is then fed through the chain. Each node in the graph can apply their own custom effects. At -the start of the graph will usually be one or more data source nodes which have no inputs, but +the start of the graph will usually be one or more data source nodes which have no inputs and instead pull their data from a data source. At the end of the graph is an endpoint which represents the end of the chain and is where the final output is ultimately extracted from.
@@ -3261,7 +3321,7 @@ splitter node. It's at this point that the two data sources are mixed. After performs it's processing routine and produces two outputs which is simply a duplication of the input stream. One output is attached to a low pass filter, whereas the other output is attached to a echo/delay. The outputs of the the low pass filter and the echo are attached to the endpoint, and -since they're both connected to the same input but, they'll be mixed. +since they're both connected to the same input bus, they'll be mixed.@@ -3403,7 +3463,7 @@ pointer to the processing function and the number of input and output buses. Exa static ma_node_vtable my_custom_node_vtable = { - my_custom_node_process_pcm_frames, // The function that will be called process your custom node. This is where you'd implement your effect processing. + my_custom_node_process_pcm_frames, // The function that will be called to process your custom node. This is where you'd implement your effect processing. NULL, // Optional. A callback for calculating the number of input frames that are required to process a specified number of output frames. 2, // 2 input buses. 1, // 1 output bus. @@ -3636,7 +3696,7 @@ You can use it like this:
-ma_splitter_node_config splitterNodeConfig = ma_splitter_node_config_init(channelsIn, channelsOut); +ma_splitter_node_config splitterNodeConfig = ma_splitter_node_config_init(channels); ma_splitter_node splitterNode; result = ma_splitter_node_init(&nodeGraph, &splitterNodeConfig, NULL, &splitterNode); @@ -5834,7 +5894,14 @@ producer thread.15. Backends
-The following backends are supported by miniaudio. +The following backends are supported by miniaudio. These are listed in order of default priority. +When no backend is specified when initializing a context or device, miniaudio will attempt to use +each of these backends in the order listed in the table below. +
++ +Note that backends that are not usable by the build target will not be included in the build. For +example, ALSA, which is specific to Linux, will not be included in the Windows build.
@@ -5896,39 +5963,6 @@ macOS, iOS
-ALSA
--ma_backend_alsa
--Linux
--PulseAudio
--ma_backend_pulseaudio
--Cross Platform (disabled on Windows, BSD and Android)
--JACK
--ma_backend_jack
--Cross Platform (disabled on BSD and Android)
-sndio
@@ -5962,6 +5996,39 @@ FreeBSD
+PulseAudio
++ma_backend_pulseaudio
++Cross Platform (disabled on Windows, BSD and Android)
++ALSA
++ma_backend_alsa
++Linux
++JACK
++ma_backend_jack
++Cross Platform (disabled on BSD and Android)
+AAudio