>>It's actually a combination of speakup, and the fact >>that speakup runs in the kernel, which means it runs as root, which >>means it's not subject to user permissions. Why that means it doesn't >>produce sound I'm not sure, but it doesn't. If pulse audio isn't >>running this just works, but otherwise ... shrug. So the problem is: pulse will not play audio as root. I'd argue that espeakup should probably be running as a separate user anyway. It only needs root perms to open /dev/softsynth. So it could drop privileges as soon as it opens the device, or ownership could be set on the device so that it is readable / writable by members of a certain group, say "speakup", of which the user account running espeakup is a member. That account would also need to be a member of the audio group so that espeakup can actually play audio. But it's not going to solve the initial problem, which is that pulse will not play nice with espeakup. The user running espeakup needs to be able to play audio all the time, not just whenever pulseaudio and whatever layers of indirection are sitting under it feel like giving it access to the sound device. As far as I can tell, in order to actually play audio with pulse audio, the user who requests access to the audio card actually needs to be physically logged in to the machine. So a pseudo user under which a system daemon is running can not play audio via the sound card. In other words, AFAIK system-wide daemons that run in a manner similar to espeakup cannot play audio on the machine's sound card using pulse. If someone knows differently, I'd be grateful to stand corrected. -- Chris _______________________________________________ Speakup mailing list Speakup@xxxxxxxxxxxxxxxxx http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup
