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
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
