Here's what is going on here.
1) if pulseaudio is started as a given user then only that user will be able to access the audio device. 2) by default if an application tries to use pulse and it's not running, then pulse will start as that user. 3) If something starts speech-dispatcher at system startup--say either its init script or the speech-dispatcher speakup interface--then the default ordering will cause it to start pulse in user mode. So only whatever user system speech-dispatcher runs as can access the sound card using pulse. 4) These days (perhaps forever), pulse opens alsa hardware directly. It doesn't use the dmix device. This means that only pulseaudio gains access to the sound hardware and anyone else trying to use it will fail. As a result, no other user can start their own pulseaudio nor can they use the sound card directly. If speech-dispatcher opens alsa directly without pulse, things will be reasonably OK for non-pulse applications. However, pulse applications will be unable to play sound because pulse will be unable to get access to the sound card because it wants it exclusively. In general, if speech-dispatcher is going to run at a system level, pulse either needs to not be used on the system or to be started in system mode before speech-dispatcher. --Sam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
