Red Hat Bugzilla – Bug 64069
while playing mp3s or ogg files the player will stop and report could not open audio
Last modified: 2016-06-07 18:44:56 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020409 Description of problem: Xmms while running in KDE or gnome will stop while changing to a new track (playing either mp3s or oggs) and report could not open audio. It is often on the same tracks. When opening xmms from the console window I get the following reported at the console: esd: Esound sound daemon already running or stale UNIX socket /tmp/.esd/socket This socket already exists indicating esd is already running. Exiting... If I click the play button play continues for a few tracks until a similar event. Version-Release number of selected component (if applicable): How reproducible: Sometimes Steps to Reproduce: 1.Play a series of mp3s or oggs either at random or in sequence 2.A dialog window will appear to advise that Xmms could not open audio. 3.click play to continue Actual Results: As described Expected Results: Play should continue through the list Additional info:
When you are in KDE, set xmms to use aRts for sound output. When in Gnome, you should set it for esd sound output. Does the problem exist in both cases with these settings?
I'm seeing the same thing. xmms is using esd and I'm running blackbox as my WM. I get no message in the console. I saw this with 1.2.7 rawhide under RH7.2 and now RH7.3.
I cannot test Xmms using aRts in Linux as there is a separate bug which causes Xmms to crash instantly. (this is already listed on Bugzilla) I also get this error on RedHat 7.2
If you erase the file(s) in ~/.xmms are you able to run XMMS?
I nuked ~/.xmms and still see the same problem.
*** Bug 79372 has been marked as a duplicate of this bug. ***
still see this with latest phoebe beta
*** Bug 53123 has been marked as a duplicate of this bug. ***
I see this with only certain kernels on my laptop. I am guessing that xmms is releasing control of the audio device momentarily between songs, and during that instant the device is ungrabbable. This only happens rarely and only during times of medium/high CPU usage. xmms I am hearing might be removed from Core in a future release because it is being replaced by newer software like rhythmbox. RH is unlikely to have the resources to look at this problem that seems to be dependent on audio driver behavior/response time or a xmms problem itself. If you want this fix it would be best to talk to xmms upstream developers.
This is very different from the behaviour that I see. May be I should have been more clear. The average load on the system is 0 The halt happens on a song change, when xmms moves from one ogg to another. It decides it does not like this ogg and stops. This is an ogg that other versions of xmms and ogg123 will happily play.
Can you narrow this down to particular files?
Colin: it has nothing to do with the files. at high system load, xmms tries to get ahold of esd and it takes too long and tries again (or esd thinks it's not active and starts up, or something -- I figured it out at one point) and then it discovers too late that it's already active and fails. The problem doesn't happen with the alsa driver. esd itself switched to using alsa (with FC2) and the problem has not been so bad since then, although it does still occur.
Looks like this bug: http://bugs.xmms.org/show_bug.cgi?id=1673