[linux-audio-dev] Linux Alsa Audio over 1394 - a Thesis

[Martijn Sipkema]

>  > > According to the mLAN spec you need a buffer of around ~250us
(depending
>  > > on format) to collate the packets.
>  >
>  > 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.
>
> As was previously pointed out several times, this is not JACK's
> job.

Well, I think it is. And I've mentioned it a couple of times also.

> The driver should assemble the the data into fixed size blocks.

Why?

> This will not introduce any signifcant latency, unless the periods
> are nearly the same, in which case the latency could double.

This will always introduce a fairly large latency unless you are
willing to accept process time/sample to vary and thus be able
to do significantly less processing.

> The model you propose may be fine when you have *one* HW interface and

Which is the common case. When using more than one interface
then there needs to be buffering. When syncing audio to video there
needs to be buffering also. This should be done in the application
such as in OpenML ( http://www.khronos.org ).

> *one* application, but it does not scale without introducing  a lot
> of complexity.

Is has nothing to do with one or more applications. Non-const size
(frames) callbacks for just as well with more applications (using JACK).

I've made my point, several times. Nobody thinks I'm right, so I'll
shut up about it. I still think it is a mistake...

--ms