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@xxxxxxxxxxxxxxx> wrote: > > > 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. 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 _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
