Bug 380041 - Sound delayed ~1 second
Sound delayed ~1 second
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: pulseaudio (Show other bugs)
8
i386 Linux
low Severity low
: ---
: ---
Assigned To: Lennart Poettering
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-13 09:02 EST by Brian Cottingham
Modified: 2008-06-13 22:20 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-13 20:06:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Brian Cottingham 2007-11-13 09:02:51 EST
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
Comment 1 Lennart Poettering 2007-11-29 20:00:04 EST
This might have to do something with DNS timeouts.

Could you please paste the output of "pax11publish", run in a terminal, here?
Comment 2 Brian Cottingham 2007-11-29 21:34:52 EST
Server: {localhost.localdomain}unix:/tmp/pulse-brian/native
Cookie: 
c7d9d7a8d265346d58f6d30ae70fd63e7ce29d7fa47b7438c0e64e12ed5cda923f556aab817faf3501bc926c4a66ddce4eedd9cbad45820f68dc285b5caf29e18e22a59d96e198f17668977fa50b71caf833006703692e6b70e1b21b62e857d71acaf9b232b3f8579343ef56efd3d767c7ff8f274b0e63d200e57e05bfeaeaa5dc8ccf9f5b4da49c89f2d6133a7294a9af592e74fb06be930322067771008e577989486d71f15f540cc2a821f6d75df0ebfdf03300f627f5e0db48250d625c29cfdf9b3587419eaf0dc10d4a84512f65c40e3f92d1eaf8d30a302bd4562647b839e1e1fc904216816a6f82c6a293fa142ed29efca1b255f832ec6d3094183241

How would DNS affect my sound, as I'm operating off of local data?
Comment 3 Lennart Poettering 2008-06-13 20:06:52 EDT
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.
Comment 4 Kevin Kofler 2008-06-13 22:06:41 EDT
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 
too.

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 
on.
Comment 5 Kevin Kofler 2008-06-13 22:20:28 EDT
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 
here.

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 
backend.

Note You need to log in before you can comment on or make changes to this bug.