Red Hat Bugzilla – Bug 380041
Sound delayed ~1 second
Last modified: 2008-06-13 22:20:28 EDT
Description of problem: Many sounds in Fedora are delayed by about a second, I
assume because of the new Pulseaudio program. For example, if I click play/
pause in Amarok, the program plays/pauses, but it takes a second for the sound
to follow the visuals indicating the change. If I delete a file from the file
manager, the confirmation warning dialog comes about a second after clicked
"delete", by which time I've already hit OK.
How reproducible: Consistent
Additional info: KDE live CD install
This might have to do something with DNS timeouts.
Could you please paste the output of "pax11publish", run in a terminal, here?
How would DNS affect my sound, as I'm operating off of local data?
Hmm, this is KDE? Then this is probably due to arts running on top of PA. Don't
do that. Bad latency is what you get when you stack sound servers.
aRts running on top of PA is the default for KDE, and as I already tried to
explain to you in a mail, it's the only sane way to use PA at all with KDE 3.
And as hardly anything _other_ than KDE 3 can talk to aRts, we do want PA there
The good news is that system notifications don't go through aRts anymore in F9,
KDE 4's Phonon talks directly to PA, aRts is only used for KDE 3 apps from F9
And while this may be just an illusion, as far as I can tell, the latency of
aRts+PA is much higher than the sum of latency of aRts and latency of PA. I've
observed the ALSA PA plugin causing some latency, also with other apps using PA
over ALSA (for example Amarok using xine-lib set up for ALSA - which I used
before the native PA backend for xine-lib got fixed), this may be the issue
As a workaround, we could try setting up aRts for ESD again, but last I checked
this was very unreliable when using PA's ESD emulation, maybe because of PA's
ESD emulation itself, but more likely because of some bug in aRts's ESD