26 Feb
2003
26 Feb
'03
9:10 a.m.
> > 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. 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