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
esd: Esound sound daemon already running or stale UNIX socket
This socket already exists indicating esd is already running.
If I click the play button play continues for a few tracks until a similar event.
Version-Release number of selected component (if applicable):
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
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
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: