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/]
