alsactl should ignore the pulse plugin

This is highly unlikely to be an alsa-utils issue. Rather, at least one end seems to be routed through the pulse plugin (configuration shipped by the pulseaudio binary package). I suppose we could hack the alsactl utility to also ignore pulse (i.e., what we do with amixer and alsamixer).

So, if I kill pulseaudio on the system (which was previously running), and if ssh isn't forwarding anything from my workstation, shouldn't that rule pulse out?

sauer@hotrod:/var/lib/mythtv/videos$ sudo alsactl store
Home directory /home/sauer not ours.
sauer@hotrod:/var/lib/mythtv/videos$ sudo -i alsactl store
X11 connection rejected because of wrong authentication.
XOpenDisplay() failed
sauer@hotrod:/var/lib/mythtv/videos$ sudo /etc/init.d/pulseaudio stop
 * PulseAudio configured for per-user sessions
sauer@hotrod:/var/lib/mythtv/videos$ sudo killall pulseaudio
sauer@hotrod:/var/lib/mythtv/videos$ ps ax | grep pulse
 9000 pts/1 S+ 0:00 grep pulse
sauer@hotrod:/var/lib/mythtv/videos$ sudo alsactl store
Home directory /home/sauer not ours.
sauer@hotrod:/var/lib/mythtv/videos$ sudo -i alsactl store
X11 connection rejected because of wrong authentication.
XOpenDisplay() failed
sauer@hotrod:/var/lib/mythtv/videos$ ps ax | grep pulse
 9010 pts/1 S+ 0:00 grep pulse

Why would it rule it out? The error message is very clearly from pulse: "Home directory /home/sauer not ours."

Well, if there are no processes running with "pulse" in their name, I ran "alsactl", and the error message mentions the contents of $HOME or "failure to initiate an X11 connection" - I'm not sure how that's "clearly" pulse to a normal person who's not familiar with every string in libpulsecommon.so. :)

All I've done is freshly install Lucid beta 1 using the alternate disk, update and dist-upgrade to get current, add the mythtv-frontend package, and turn on the PCM output using alsamixer. I've literally only spent a couple of hours on a fresh install on this particular machine.

I played with it a little more, and clearing the DISPLAY variable before running the command makes the error message go away. In either case - with or without DISPLAY existing - the asound.state file is actually created. I ran an strace on alsactl, and sure enough, it's loading the pulse library and attempting to connect to the machine listed in DISPLAY right before that error message (pulse and X11 libs are loaded either way).

So, I guess there's mostly a UI issue here: An error message is displayed which seems to indicate failure, even though the intended action is actually completed. I'd question why alsamixer is using pulse at all, but at this point, I'd be happy if either alsa or pulse somehow suppressed ignorable error messages.

if you look at http://git.alsa-project.org/?p=alsa-utils.git;a=blob;f=alsactl/state.c

        sprintf(name, "hw:%d", card);
        dbg("device='%s', doit=%i", name, doit);
         err = snd_ctl_open(&handle, name, 0);

it only use snd_card_next() to find out all the alsa cards and open those hw:x ctl device . it does not save any setting of the pulse device

it seem that you don't have permission to write the state file

>> Home directory /home/sauer not ours.

That's an interesting theory, Raymond, but it ignores the fact that the state file is created/modified as expected, as noted in the following quote from post #4. :)

"In either case - with or without DISPLAY existing - the asound.state file is actually created."

Specifically:
 sauer@hotrod:~$ ls -l /var/lib/alsa/asound.state
 -rw-r--r-- 1 root root 10059 2010-11-02 22:03 /var/lib/alsa/asound.state
 sauer@hotrod:~$ sudo -i alsactl store
 X11 connection rejected because of wrong authentication.
 XOpenDisplay() failed
 sauer@hotrod:~$ ls -l /var/lib/alsa/asound.state
 -rw-r--r-- 1 root root 10059 2010-11-02 22:04 /var/lib/alsa/asound.state
 sauer@hotrod:~$ unset DISPLAY
 sauer@hotrod:~$ sudo -i alsactl store
 sauer@hotrod:~$ ls -l /var/lib/alsa/asound.state
 -rw-r--r-- 1 root root 10059 2010-11-02 22:05 /var/lib/alsa/asound.state

Note that the timestamp on the files changes each time (I waited a minute or so between runs). If I couldn't write to the file, I'd instead get this message:

 alsactl: save_state:1530: Cannot open /var/lib/alsa/asound.state for writing: Permission denied

All that's really wrong is that an error is generated by pulse, but the error doesn't actually matter for anything because everything actually works just fine. Well, except for emitting of an ignorable error message; even the return code is still 0. ;)

 sauer@hotrod:~$ sudo -i alsactl store; echo $?
 X11 connection rejected because of wrong authentication.
 XOpenDisplay() failed
 0

So this is properly categorized with importance of "wishlist". IMHO.

you can use "strace alsactl store" to find out why "X11 connection rejected"