[LAD] jackd buffersize

Justin Smith noisesmith at gmail.com
Mon May 11 09:21:02 UTC 2009


On Mon, May 11, 2009 at 1: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.
>
> 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.
>
> c) Although certainly possible, 256 parallel "moog"-filters is a bit
> overdoing it, no? IMHO, once a multichannel polysynth goes beyond 96
> voices (in this case with two filters - one left, one right - per voice
> == 192 threads) the experienced return of improved quality/complexity is
> diminishing steeply, getting lost in the mix. I'd much rather spend more
> clockcycles on, say post-processing of channels - or more room for a
> simultanious video stream.
>
>
>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev at lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>

Regarding the thread count issue, you are aware that buffer size,
number of threads used, and port count are completely different
things, right? There is no threading configuration available at with
jack that I know of, and jack does not directly interact with ladspa
plugins at all. You may know these things already, and maybe I just
misunderstand your question. Regarding the power of two buffer size
limitation, iirc that has to do with the efficient ring-buffer data
exchange implementation.



More information about the Linux-audio-dev mailing list