With this commit, custom backends can now be implemented as
self-contained modules that can easily be plugged in and mixed and
matched depending on a programs requirements. The order in which
custom backends are specified in the context config determine their
priority.
This commit updates the custom_backend example by moving the SDL
code out into its own file in "extras/backends/sdl". The example will
now just include the SDL code files like normal. This represents a more
realistic scenario.
Custom backends must now use the `ma_device_backend_vtable` object to
define their callbacks. All of these functions are largely the same,
except they all now take a `void*` as their first parameter which
represents the user data pointer.
The ma_backend_callbacks parameter has been removed from onContextInit
which means you must now statically define your callbacks in the
ma_device_backend_vtable object that you pass into the context config.
The `custom` member of the context config has been replaced with a new
set of members to support the ability to plug in multiple vtables.
This includes changes to callbacks used by custom backends. It adds a
`pConfig` parameter to both onContextInit and onDeviceInit. This allows
custom backends to specify custom config properties.
This commit includes a few changes required for better supporting this:
* Extra members have been added to ma_device_info which are going to
eventually replace the min and max channels and sample rates. The
new system is going to provide a list of supported data formats,
groups by format/channels/rate and some flags. The only flag used
at the moment is whether or not the format is usable in exclusive
mode. The custom backend is the only backend currently using these
new device info properties, and a backwards-compatibility layer has
been implemented to fill out the old properties. Built-in backends
will be migrated over to the new system in time.
* A new set of backend callbacks have been implemented. Only the
custom backend is using these at the moment. Built-in backends will
be migrated over to these new backends soon.
* A new public API called ma_device_get_state() has been added which
returns the current state of the device (whether or not it's
started or stopped). This is necessary for some custom backends.
* A new public API called ma_device_handle_backend_data_callback()
has been added. This is required for custom backends who use the
callback paradigm for data delivery.
* A new type of ring buffer has been created called ma_duplex_rb.
This is used as an intermediary buffer for duplex devices running
on backends that use the callback paradigm. It's used internally by
ma_device_handle_backend_data_callback(). In the future it's
planned to expand ma_duplex_rb to handle desyncs by dynamically
resampling to get both sides back in sync. This is not implemented
as of this commit.
Future work will involve converting existing built-in backends to be
consistent with the new ideas introduced with custom backend support.
David Reid