On Mon, May 11, 2009 at 4:35 AM, Jens M Andreasen <[email protected]> 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. _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
