26 Feb
2003
26 Feb
'03
8:59 a.m.
On Wed, Feb 26, 2003 at 12:38:38 +0100, Martijn
Sipkema wrote:
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
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.