I'm not a JACK developer so my opinion may not
really count here, but
I really think it would be a bad decision to criplle support for all
hardware that is not able to provide constant size power of two
(frames) periods.
we don't care about non-power-of-two periods, i think. however, i do
consider periods defined in units of times and not frames to be broken
hardware design. it forces inefficiencies into the software that are
totally unnecessary.
And it surely wouldn't be bad for clients not to
rely a a particular size
callback. I don't know how CoreAudio handles this. I'm sure EASI did
not have constant size callbacks and VST does not either IIRC. (ASIO
probably does, but ASIO also forces double buffering (I think)...).
until recently, JACK provided support for variable numbers of frames
in the process() callback. it was removed because no developer was in
support of it, and because JACK itself had no use for it.
i am quite open to re-examining the issue. however, i don't want
inefficient software designs to be forced on us by the stupid use of
USB to handle audio. i've had enough of bad hardware designs messing
up software, and it won't happen here. if it can be done sensibly, we
can do it.
--p