[Support] status of our new images and a request (fwd)

[Chris Brannon]

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