Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

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
Task Type Bug Report
Category Upstream Bugs
Status Closed
Assigned To Gaetan Bisson (vesath)
Jan Steffens (heftig)
Architecture x86_64
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


Description: xinit race condition generates "snd_mixer_find_selem failed"

Additional info: More information for Bug  FS#26683  as requested

I was waiting for the next version of audacious, xfce-mixer, and pulseaudio before commenting on  FS#26683 . The issue went away for a while, now it is back.
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

Closed by  Gaetan Bisson (vesath)
Tuesday, 14 February 2012, 15:44 GMT
Reason for closing:  Not a bug
Comment by Gaetan Bisson (vesath) - Monday, 13 February 2012, 23:50 GMT
Could you submit a bug report regarding audacious' "forgetfulness" upstream?

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?
Comment by Gaetan Bisson (vesath) - Monday, 13 February 2012, 23:51 GMT
Jan, any thoughts on this?
Comment by Jan Steffens (heftig) - Tuesday, 14 February 2012, 08:52 GMT
Does this problem disappear if you remove the "fallback" lines from /etc/asound.conf?
Comment by John Lindgren (jlindgren) - Tuesday, 14 February 2012, 13:21 GMT
Audacious's "forgetfulness" is by design. If PulseAudio isn't running, we can't use it, so naturally we try something else.
Comment by Henry Pfeil (Psnarf) - Tuesday, 14 February 2012, 15:27 GMT
Aha! if I boot into runlevel 3, login and `pulseaudio --start`, then startx, everything works as advertised.
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 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.]