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): How reproducible: Sometimes 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? Additional info: 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 later. At this point, I don't think we'll change it to do autodetection on every startup.