At 44/48khz, the main delay line comes out to 20k to 22k samples, which gets
rounded up to 32k as the next power of two. This leaves plenty of room for the
full 1k BUFFERSIZE without having to increase the delay line beyond what it
already is.
It still requires a proper custom decoder configuration for speakers, so that
proper distances can be specified. Ambisonic output still relies on the
nfc-ref-delay option, and HRTF uses the dataset's distance.
Specifically, the A2B and output mixing, as well as applying the band-pass with
B2A mixing (the latter of which hiding a bug that was overwriting the early
buffer storage).
Particularly, handle "holes" in the record stream and premature end-of-buffer.
Also don't bail out when capturing while disconnected (the extension says it
should provide anything it previously reported available, going to silence for
anything no longer readable).
Unfortuantely, the relevant KDE bug still seems to exist (streams are forced to
KDE's default device after opening, even when they're created with a specific
device at user request). I do not know why KDE thinks this is in any way good
behavior (the user doesn't get their desired device, nor does the stream get
the appropriate format for the device its ultimately put on), but making
streams non-movable as a workaround has been a thorn in the side of non-KDE
users for too long. C'mon KDE, it's been nearly (if not more than) 7 years now.
Certain backends don't need a buffer size to be a strict multiple of the period
count, which allows a little more flexibility. The period/update size simply
acts as the minimum request, which helps control CPU load by determining how
often parameter and other pre-mixing updates are processed.
