Red Hat Bugzilla – Bug 76291
XMMS Couldn't Open Audio Error With KDE artsd vs. esd
Last modified: 2014-03-16 22:31:49 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830
Description of problem:
It appears KDE starts up artsd as default for desktop sounds and, at least on
this machine, xmms starts with the eSound output plugin selected. The problem
is, if a desktop sound is played (artsd is called), I belive artsd secures some
sort of lock on the audio. If xmms then tries to use esd to play a file while
artsd is running, esd is unable to open the audio against artsd and xmms fails
to play the file.
To test this theory, I did two things:
First, I watched the processes in top and noticed when artsd was running the
"Couldn't Open Audio" would always come up. As soon as artsd went to sleep, then
xmms would play the file and the esd process woud come to the top of the list.
Second, I set the xmms preferences to use the arts output plugin instead of the
eSound output plugin. I did not get any "Couldn't Open Audio" errors
thereafter, unless I set the output back to the eSound plugin and tried to play
a file while artsd was not sleeping.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install Red Hat Linux without Gnome packages (go for KDE desktop)
2. Start xmms
3. Check preferences, note eSounds selected by default
4. Attempt to play xmms file (.ogg, .mp3, doesn't matter)
Actual Results: Intermittently, a dialog window comes up with a "Couldn't Open
Audio" error and xmms does not begin playing the file.
Expected Results: Should just play, regardless of whether default desktop is
Gnome or KDE or the Gnome package is not installed (I am under the assumption
that Gnome does not use artsd as its default and thus this problem would not
occur in that environment, but I have not tested this hypothesis myself). Some
options are to set the xmms preferences to artsd output by default if KDE is
selected, or have xmms detect artsd is running and switch over to that output
plugin instead of trying to startup esd. I am assuming here that the sound
quality output of artsd and esd are esentially the same?
System is a Dell Inspiron 7500 with a ESS Technology ES1978 Maestro 2E sound
card using the maestro driver. Fresh install of Red Hat Bluecurve 8.0 with KDE
only (I think Gnome essentials are installed, but not the Gnome package through
the Red Hat package manager).
XMMS does not switch output plugins, depending on your environment. Moreover, I
believe the code that tries to switch to artsd on the *first* time you run it,
if artsd was active, was broken.
Thanks for the response. I am fairly certain artsd was running the first time I
ran xmms. I have always used KDE and artsd is always running once the desktop
comes up. Putting aside my sample of one, assuming xmms checks and changes the
output plugin the first time it runs, the problem will occur if the user
switches from Gnome to KDE (assuming that Gnome in the Red Hat distrobution does
not start artsd). Whether this behaaviour can change at the distribution level
or at the xmms level, it should for usability's sake. New, non-technical users
will not know how to monitor a process list and diagnose the problem as artsd
and esd fighting over the same resources.
I also had this problem due to the KDE desktop using arts. I switched to the OSS
module which resulted in me being able to play my music as soon as KDE loads. I
agree that this is an important issue to non-technical/new users of linux and
should be corrected. I am infact reasonbly new to linux and had to find this bug
report to correct the problem. Also with certain MP3's the OSS driver does not
decode at the right speed or something becuase I get very fast audio although
the eSound driver decodes it perfectly. It appears that the arts driver wont
work when I select it?
The code to automatically select arts when you first run xmms if you're in KDE
has been tweaked slightly in 1.2.8-1; it works for me; autodetection is not done
At this point, I don't think we'll change it to do autodetection on every startup.