[pulseaudio-discuss] RFC: An official system for enabling/disabling PA+ALSA

[Colin Guthrie]

Hello,

As Sjoerd prompted recently there have been a number of efforts over the
years to get some degree of automatic ALSA configuration working when PA
is in use.

The latest attempt at this is:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623002

although for background there is an existing system, which I believe is
used in Debian and Ubuntu, which checks to see if the PA daemon is
running as part of the alsa config. This is done dynamically thanks to
an alsa module and happens every time the alsa config is parsed.

IMO, these system have several draw backs.
 * With the alsa conf module, the system does not handle chases where PA
is running remotely and also does not check to see if the sink that will
be used (after it's routed) is suspended or not. This actively causes
problems with some software that tries to be too clever (case in point
being MythTV which can cause deadlocks due to suspending PA when using
pcm.default even though it's directed at the alsa-pulse plugin).

 * The approach linked above is gnome-specific and thus breaks
alsa-based auto-spawning from console logins and does not address the
issue for anything other than gnome which is not a very good idea IMO.


For years I've offered a system in Mandriva (and now Mageia) that has
worked very well for me but does not offer per-user flexibility.

Ultimately I used the update-alternatives system to define a system-wide
"sound profile". At present I have "alsa" and "pulse" as the available
profiles, but there could easily be a "jack" or similar profiles created
in the future.

Ultimately this system controls whether or not to start PA at login. I
hack the two start-pulseaudio-* scripts to check to see that the correct
sound profile is in use before starting anything. I think other distros
do similar things (IIRC Debian/Ubuntu hack out the "pulseaudio --start"
call and rely on autospawning to start PA when pactl is called).

This takes care of "start at graphical login" cases but autospawning
still needs to be dealt with, so we have to switch that on/off in
/etc/pulse/client.conf via our drakconf system which is a little more ugly.



Anyway, in the interests of trying to standardise approaches, I'm
looking for suggestions on how to disable PA in a neat way (i.e. doesn't
require editing files if possible) and can work both system wide (i.e.
for all users) or on a per-user basis.


I would then like to have an alsa config module that uses this config to
know whether or not PA should or should not take over the "default" device.

All of this should be deterministic (i.e. is should not rely on
autospawning or connecting to a running daemon). It should be a
preference set by the user.


I would propose one of two approaches:
 1. Define a new env var PULSE_DISABLE. If this is 1, then PA is
disabled, otherwise it's enabled this can then be added to a users
profile via /etc/profile.d/ and update-alternatives.

or

 2. Define a new config file that is honoured by both daemon and client
e.g. global.conf: enabled=true. Or is perhaps just a new key in
daemon.conf enough, even if the client tries to autospawn, if the daemon
is disabled, it will fail as it should. I guess the client code could
parse the daemon.conf too to check before autospawning just to save the
work?


Either way it would be nice to have a simple way to disable PA and write
a simple ALSA module to be able to check for that configuration. This
would be something that could be adopted cross distro and reduce the
fragmentation and in-place file editing.

What do people think?

Col




-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]