Au sujet de la latence je vais te coller sa (longue) réponse mais en résumé : oui cela augmente un peu la latence mais pas plus que les autres solutions comme dmix. A long terme, et avec l'aide du kernel, une solution du type PulseAudio sera obligatoire pour obtenir des faibles latences.
Son post sur ce sujet : yes, PA increases the latency
over direct hw access. But so does dmix, because it enforces fixed
fragment settings for all apps. What you really want to do (which
however right now is only partially implemented in PA) is allowing
per-stream fragment settings, by scheduling audio based on timer
interrupts instead of sound io interrupts (based on fixed fragment
settings). Those timer interrupts can be dynamically changed so we can
change the wakeup points dynamically during playback without too much
effort. However this needs some kind of kernel support (hrtimers,
HPET), which only has become available very recently and on x86 only
(not even amd64 yet), so until we get this fully implemented a few
months will pass. If we have that however, we basically get the same
PCM pipeline that Vista and MacOS have: a huge mixing buffer managed
by a real-time userspace sound server which allows rewriting at any
time and notifying clients dynamically, scheduled via timer
interrupts. In essence, in the long run we really *need* something
like PA, if we want to provide low latencies (i.e. short fragments ==
frequent interrupts) and low power consumption (i.e. few interrupts ==
huge fragments) at the same time and switch between them
dynamically. Yes, right now, PA increases your achievable latencies a
bit (but just a bit), but in the end we *need* a process that does the
audio scheduling based on timers -- something that PA will then do. Of
course, PA doesn't fully implement yet, which is partially PA's fault
and partially the kernel's fault that sucks when it comes to timers,
right now. We're getting there.
[^] # Re: C'est bien joli tout ça...
Posté par patrick_g (site web personnel) . En réponse au journal PulseAudio. Évalué à 3.
Tu a pris la peine de lire les liens postés par IsNotGood ?
Le long post de Lennart explique bien toutes les qualités de PulseAudio et il répond aux divers FUD : http://mail.gnome.org/archives/desktop-devel-list/2007-Octob(...)
Au sujet de la latence je vais te coller sa (longue) réponse mais en résumé : oui cela augmente un peu la latence mais pas plus que les autres solutions comme dmix. A long terme, et avec l'aide du kernel, une solution du type PulseAudio sera obligatoire pour obtenir des faibles latences.
Son post sur ce sujet :
yes, PA increases the latency
over direct hw access. But so does dmix, because it enforces fixed
fragment settings for all apps. What you really want to do (which
however right now is only partially implemented in PA) is allowing
per-stream fragment settings, by scheduling audio based on timer
interrupts instead of sound io interrupts (based on fixed fragment
settings). Those timer interrupts can be dynamically changed so we can
change the wakeup points dynamically during playback without too much
effort. However this needs some kind of kernel support (hrtimers,
HPET), which only has become available very recently and on x86 only
(not even amd64 yet), so until we get this fully implemented a few
months will pass. If we have that however, we basically get the same
PCM pipeline that Vista and MacOS have: a huge mixing buffer managed
by a real-time userspace sound server which allows rewriting at any
time and notifying clients dynamically, scheduled via timer
interrupts. In essence, in the long run we really *need* something
like PA, if we want to provide low latencies (i.e. short fragments ==
frequent interrupts) and low power consumption (i.e. few interrupts ==
huge fragments) at the same time and switch between them
dynamically. Yes, right now, PA increases your achievable latencies a
bit (but just a bit), but in the end we *need* a process that does the
audio scheduling based on timers -- something that PA will then do. Of
course, PA doesn't fully implement yet, which is partially PA's fault
and partially the kernel's fault that sucks when it comes to timers,
right now. We're getting there.