On Sun, 2011-03-20 at 11:07 +0100, David Henningsson wrote: > On 2011-03-19 17:45, Philip J?genstedt wrote: > > Hi PulseAudionauts, > > > > I've been meaning to experiment a bit with low-latency voice codecs > > and naturally want to add as little latency as possible to what is > > imposed by the codec on both capture and playback. (My guess is that > > the latency added would be between min(capture_latency, > > playback_latency) and capture_latency+playback_latency, depending on > > how well capture end and playback begin are synchronized.) > > > > Q: Does it matters for latency if I program against ALSA or PulseAudio? > > Well, that kind of depends on what scale you're on. If you need > latencies under say - and this is just a qualified guess - ~ 10-20 ms, > you'll need to program against ALSA or Jack. Above that and you'll be > good with PulseAudio. > > > This is assuming a setup like on Ubuntu, where the default ALSA device > > is using a PulseAudio backend. (Portability and code complexity may > > favor one solution or the other, but that's not what I'm asking.) > > When I say program against ALSA above, I mean directly against an ALSA > sound card, i e bypassing Pulseaudio. As for if ALSA plugin -> > PulseAudio -> ALSA -> HW gives worse latency than PulseAudio -> ALSA -> > HW, I don't think that matters much. A while back I discussed in IRC with someone who wanted to have low latency with Pulseaudio. According to his experiments, it seemed like libpulse enforces for some reason a minimum client-side buffering of 100 ms or so, unless pa_stream_begin_write() is used when writing data. The alsa plugin doesn't use that function (I don't know why, maybe it just can't use it for some reason), so I would guess that it's impossible to get lower than 100 ms latencies through the alsa plugin. You can of course try, and results of such experiment would be interesting regardless of the outcome. -- Tanu
