> On Wed, Feb 26, 2003 at 12:38:38 +0100, Martijn Sipkema wrote: > > Still there is no guarantee that 10 packets always have exactly the same > > number of samples. You say the mLAN spec says you need a buffer of > > around ~250us. Note that is doesn't say a buffer of a number of frames. > > The bottom line is these packets are sent at regular time intervals, not > > at a fixed number of frames and thus JACK should support this by > > allowing non-const (frames) callbacks IMHO. > > Why? Surely its much easier to wait until you have n samples and then send > them round. The extra 250us of latency is hardly punishing. > > You must do that where you have a soundcard<->mLAN bridge in any case, in > order to sync the graphs. > > IMHO if jack makes things hard for app developers by forcing them to deal > with odd sized data blocks then its not doing its job. As we have > discussed on the jack list there are a number of situations where you cant > reliably or efficiently handle variable block sizes.
Well, I'll shut up about it. I still think it is a mistake. I haven't heard any convincing (to me) arguments why an application should not handle variable sized callbacks. VST process() is variable size I think as are EASI xfer callbacks, but clearly JACK needs constant callbacks and there is nothing I can do about that... --ms
