On Mon, May 11, 2009 at 1:35 AM, Jens M Andreasen
<jens.andreasen(a)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(a)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.