Fill out the JACK playback backend

A few notes about it:

The OpenAL device's requested buffer metrics are ignored, and instead the
device will keep one JACK-sized buffer's worth of audio prepared for JACK's
next process request.

Output is restricted to 32-bit float stereo. Part of this is because JACK
requires a buffer size that's a power of 2 (measured in samples), and the
ringbuffer requires a buffer size that's a power of 2 (measured in bytes). A
channel count of 6 (5.1) or 7 (6.1) will not work without causing a sample to
split over the edge of the ringbuffer. Additioanlly, JACK doesn't provide
information about what channel configuration a device or set of ports has, so
there's no way to know what ports 3 and up map to (even the first two ports are
unknown, but assuming stereo seems to work well enough).

There is no device latency measurement (for AL_SOFT_source_latency) due to the
non-atomicity between the ringbuffer's read size and port latency. A method is
needed to ensure the ringbuffer's read size and port latency can both be
measured between the end of a JACK update cycle (when the port latency has been
updated with the newly-retrieved audio) and the following ringbuffer read
update.

0 files changed, 0 insertions, 0 deletions