[LAD] jackd buffersize

[Paul Davis]

On Mon, May 11, 2009 at 4:35 AM, Jens M Andreasen
<jens.andreasen at comhem.se> wrote:
> What is the rationale for jackd requiring buffers to have number of
> frames set to a power of 2? Could this be relaxed to perhaps a multiple
> of 16, 32 or somesuch?
>
> I have a few reasons for wanting to do so
>
> a) Neither 128 nor 64 matches a samplerate of 96K and 1ms between USB
> midi messages. 96 would.

Even though USB devices are common, they are hardly the arbiter of
good hardware design for an audio interface.
The sample rate makes no difference to how often USB delivers audio
data - it always happens on the 1msec clock cycle whether the rate is
32kHz, 192kHz or anything else. Since 1msec doesn't translate to any
useful integer number at the most common SR's, its really not worth
paying that much attention to. 96kHz is not a very useful SR with most
USB interfaces (at present). If and when USB2 becomes more common, we
could revisit the issue. USB2, at least on linux, has a number of
other major hurdles to surmount before it becomes common for audio
devices.

However, notice that far more important from a performance perspective
is that power-of-2 buffer sizes permit buffers to be cache line
aligned, which as far as we know (its never been carefully measured)
greatly outweighs the kinds of concerns you are mentioning.

> b) CUDA (Nvidias gpgpu language) appears to have some magic regarding
> 192 threads that seems to work most fluently. This also happens to be a
> multiple of 96 opening up for some programming efficiency advantages
> when threadID equals [a multiple of] frame index.

this has absolutely nothing to do with JACK.