This should not change anything at all within the compiled library, but it does make the header file easier to read for non-C programmers who don't expect an octal value.
The current CI doesn't work and can be fixed. To steps, use a matrix to build on various OS + allow platform specific flags.
The linux build should cover a wider case of video backends.
The clang-cl compiler defines `__llvm__` but not `__GNUC__`. The `__cpuid` intrinsic doesn't seem to exist with clang-cl, so the code won't link properly. The `__GNUC__` versions of these functions will work properly on Windows with clang-cl.
Constify the min/max period variables, use a #define for the base clock rate used in the calculations and note that changing the upper limit can have dire side effects as it's a hard limit in Pipewire.
Replace "magic numbers" with #defines, explain the requirements when using the userdata pointer in the node_object struct and a few other minor code and comment cleanups.
Use the 'R' (rear) prefixed designations for the rear audio channels instead of 'S' (surround). Surround designated channels are only used in the 8 channel configuration.
Further refactor the device enumeration code to retrieve the default sink/source node IDs from the metadata node. Use the retrieved IDs to sort the device list so that the default devices are at the beginning and thus are the first reported to SDL.
The latency of source nodes can change depending on the overall latency of the processing graph. Incoming audio must therefore always be buffered to ensure uninterrupted delivery.
The SDL_AudioStream path was removed in the input callback as the only thing it was used for was buffering audio outside of Pipewire's min/max period sizes, and that case is now handled by the omnipresent buffer.
Extend device enumeration to retrieve the channel count and default sample rate for sink and source nodes. This required a fairly significant rework of the enumeration procedure as multiple callbacks are involved now. Sink/source nodes are tracked in a separate list during the enumeration process so they can be cleaned up if a device is removed before completion. These changes also simplify any future efforts that may be needed to retrieve additional configuration information from the nodes.
In some cases, it can be useful to have the KMSDRM backend even if it cannot
be used for rendering. An app may want to use SDL for input processing while
using another rendering API (such as an MMAL overlay on Raspberry Pi) or
using its own code to render to DRM overlays that SDL doesn't support.
This also moves the check for DRM master to an earlier point where we can fail
initialization of the backend, rather than allowing the backend to initialize
then failing the creation of a window later.