FS#28397 - [audacious vs pulseaudio]
Attached to Project:
Arch Linux
Opened by Henry Pfeil (Psnarf) - Monday, 13 February 2012, 14:20 GMT
Last edited by Gaetan Bisson (vesath) - Tuesday, 14 February 2012, 15:44 GMT
Opened by Henry Pfeil (Psnarf) - Monday, 13 February 2012, 14:20 GMT
Last edited by Gaetan Bisson (vesath) - Tuesday, 14 February 2012, 15:44 GMT
|
Details
Description: xinit race condition generates
"snd_mixer_find_selem failed"
Additional info: More information for Bug I was waiting for the next version of audacious, xfce-mixer, and pulseaudio before commenting on The problem arises when audicious and xfce-mixer starts up before pulseaudio completes its start-up chores. Audacious forgets that the Output Plugin preference was set to Pulseaudio in the previous session; it starts up with that preference set to alsa. When you right-click the xfce-mixer panel plugin, the Properties Soundcard is set to alsa, as is the mixer itself. `ps -AF | grep xfce4-mixer-plugin | awk '{ print $2 }'` and `kill -HUP $1` the mixer-plugin process. Then right-click the mixer icon; Properties Soundcard is now set to pulseaudio. If I start audacious at that stage, the selem error box presents itself. Open xfce-mixer (left-click the panel plugin icon) now the pulseaudio preference is listed among the options, which is the one I choose. Back to forgetful audacious, Preferences | Output Plugin now has pulseaudio among the choices, choose it. Everything works as advertised. Methinks if there were a way to delay audacious and xfce-mixer, or start pulseaudio earlier in the xinit process, it might clear the problem. I tried an autostart script with some sleeps added, no joy. I plan to login to runlevel 3, and start pulseaudio before invoking startx, but that's a clumsy kludge. The kernel invokes alsa via modules during systart; pulseaudio is an afterthought. Perhaps if pulseaudio were loaded at the end of the alsa startup procedure? That doesn't address the reason audacious reverts to alsa when it can't find a running instance of pulseaudio. Recall this problem went away during January, but re-appeared after a recent update. Maybe a persistent udev rule? |
This task depends upon
I'll see if we can do something about pulseaudio. To be clear, how is pulseaudio started on your machine? By initscripts (rc.d), xinit, xfce, or something else?
When xdg invokes pulseaudio.desktop in its Autostart, the race condition presents itself: mixer, audacious, mixer panel plugin all have no idea that pulseaudio is running.
As for the design decision to try another Output Plugin if audacious cannot detect the preference that the user selected during the previous session, IMHO, if I may be so bold, perhaps that might be considered an error condition, and present the user with a box announcing the missing output plugin that contains decision radio buttons to select one of the output plugins that were detected, or maybe even a "retry" button? If alsa has already deferred to alsa-pulseaudio, then the mystery contition presents itself when audacious tries to open the inactive alsa plugin.
I'm going to request closure because launching pulseaudio before invoking xinit works. The issue is not an audacious problem, rather the window manager's Autostart (Kde, Gnome, Xfce4,...). Perhaps the folks at Freedesktop.org might be persuaded to consider further discussion on the Autostart Draft Specification via the xdg list? If Autostart could be configured to exec the .desktops in a distribution- or user-specified order, much like /lib/udev/rules.d and /etc/udev/rules.d, prerequisites could launch before the application that needs them. Then applications wouldn't have to consider whether or not user preferences match the system state during startup, which might simplify the startup code.
[Disclaimer: I am not a Wizard, nor do I play one on tv.]