28 Oct
2009
28 Oct
'09
2:26 p.m.
On Tue, Oct 27, 2009 at 10:29:10PM -0400, Paul Davis wrote:
On Tue, Oct 27, 2009 at 7:15 PM, Jonathan E. Brickman
<jeb(a)joshuacorps.org> wrote:
If ALSA gets its part right, the resulting latency will
just depend on how the app uses the ALSA interface, as it
does for a normal ALSA device. If the app does so in the
same way as e.g. Jack's backend, there should not be any
additional latency at all.
If ALSA can make a low-latency interface on top of an
interrupt routine or thread that runs every period and
is triggered by the soundcard, then (as a Jack client)
it should be able to provide the same low-latency
interface on top of the process callback which just
looks like a soundcard interrupt handler in user space.
There is no essential difference between the two.
Ciao,
--
FA
Well, it is clear that I have to do something
different than pure
Jack/ALSA. I'll try Pulse, although Pulse's reputation for low latency
isn't exactly stellar.
the ALSA jack plugin has poor latency too. anything that has to
intermediate between a "push" model API (where the app gets to decide
when and how much data to read/write) and a "pull" mode (where
something other than the app makes those decisions) has to have enough
buffering to deal with the app's intentional and unintentional
behaviour. it probably isn't as latency inducing as pulse's default,
but its not a replacement for using JACK directly.