[pulseaudio-discuss] Change sound via acpid

[Tanu Kaskinen]

On Tue, 2015-12-22 at 21:39 -0800, John W wrote:
> Hello,
> 
> I'm trying to make the mute/unmute key on my laptop work.
> It generates acpi events, but does not generate XF86AudioMute X11
> message - In fact, I prefer it to be that way, since I don't want to
> rely upon X11 running in order to do this.
> 
> I'm trying to figure out the "right" way to do this.
> N.B.: It is my understanding that running in system mode, while it may
> work, is not the "right" way to do this. I am looking for an
> alternative to that, if possible.
> 
> My acpi script runs (as root), and I want it to toggle the mute state.
> 
> I tried "amixer set Master toggle", but that doesn't work as root.
> I can reproduce it with "sudo" - see below:
> 
>     $ sudo amixer set Master toggle
>     ALSA lib pulse.c:243:(pulse_connect) PulseAudio: Unable to
> connect: Connection refused
> 
>     amixer: Mixer attach default error: Connection refused
> 
> From reading around, I came to learn that this can be caused by a
> missing "cookie" file.
> However, even copying the /home/myuser/.config/pulse/cookie file to
> /root/.config/pulse/cookie did not solve this issue.
> 
> Question 0: Is there any way to get logging information about these
> denials, from pulseaudio? The usual advice is to run pulseaudio as a
> non-daemon, with "-vvvv" option. I can do this, but even so, none of
> these "Connection refused" incidents appear.
> Is there somewhere else I should look?
>
> Question 1:
> What other reason could there be for this "Connection refused" from
> pulse? Any ideas?
> Is there any good way for me to confirm that my copied cookie file is
> correct, to try to narrow down the problem?

"Connection refused" doesn't mean that the daemon refused the client
connection (that would be "Access denied" or something like that).
"Connection refused" means that the client didn't find the daemon. If
you meant to connect to the pulseaudio daemon of "myuser" under "root",
that will fail, because root will look for root's pulseaudio daemon
socket, not myuser's daemon socket.

> So, I abandoned that approach. Even in the best case, this would
> require re-copying the cookie every time I rebooted, or having my
> script figure out who spawned pulseaudio, then look in their user
> directory, etc. Seems hacky to me.
> 
> I learned about "system mode", but given that the developers
> themselves say it is unsupported and bad, I am not touching that. Nor
> do I trust all that pulseaudio code running as root (:

It's not true that the system mode is unsupported, and pulseaudio will
run under the user "pulse" in the system mode, not under root. That
said, using the system mode doesn't seem like the right solution in
this case.

> Next, I found out about the unix socket authentication options in
> /etc/pulse/default.pa
> I created /etc/pulse/client.conf, and added:
> 
>     default-server = unix:/tmp/pulse-access-socket
> 
> And made a corresponding change in /etc/pulse/default.pa:
> 
>     load-module module-native-protocol-unix auth-anonymous=1
> socket=/tmp/pulse-access-socket
> 
> But this does not seem to work.
> Looking at the manpages, there are some hints that maybe these options
> only apply in system mode? I am not sure...

The options aren't specific to the system mode. Without error messages,
I don't know why it didn't work. If there are multiple users running
pulseaudio, one problem would be all of them try to listen on the same
socket, which will inevitably fail.

> Question 2:
> Can anyone confirm or deny that that method is legitimate?
> 
> And really, any other suggestions of how to get this to work are welcome.

What do you want to mute? All sinks, including bluetooth etc? Or only
the internal sound card? If it's sufficient to just mute one alsa sound
card, you could use amixer to mute the hardware directly. PulseAudio
will notice that and update its internal state accordingly. This is the
command:

amixer -c0 set Master toggle

"-c0" may refer to the wrong sound card, though (and it may refer to a
different sound card after rebooting). "-cNAME" is better, where NAME
is the sound card name shown in brackets in /proc/asound/cards.

-- 
Tanu