Subject: Re: [linux-audio-dev] Linux Alsa Audio over 1394 - a Thesis
From: Martijn Sipkema (msipkema_AT_sipkema-digital.com)
Date: Wed Feb 26 2003 - 14:51:41 EET
> 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
This archive was generated by hypermail 2b28 : Wed Feb 26 2003 - 15:03:22 EET