Re: Activation of Speech Dispatcher under squeeze
Hi,
On Fr, Sep 24, 2010 at 02:11:27 +0200, Samuel Thibault wrote:
> Cc-ing brltty as it really matters there.
>
> Hynek Hanke, le Thu 23 Sep 2010 14:39:42 +0200, a écrit :
> > If you are using ALSA and have a multi
> > channel soundcard or DMIX set up, it will speak.
>
> DMIX is set up by default nowadays.
>
> > However, Pulse Audio will refuse to play sounds originating from
> > the root user to ordinary users. And I think for very good
> > reasons.
>
> This seems reverted logic to me actually. Root can output text to
> ordinary users at will, nothing bars him from doing that either on the
> linux console, or X11, etc. Why should audio be different? If an
> administrator erroneously says a password loud in the user's speakers
> that's the dumb administrator's concern (he can as well just write them
> in world-readable files), and it shouldn't bar normal administrators
> from doing proper outputs as they consider appropriate.
+9999999999999
I am frequently writing similar thing in many lists (speechd, orca,
pulseaudio, etc).
It seems that the great new audiosystem of pulseaudio doesn't care and
the people from brailcom ignored my rfc about seperating audio part of
speech-dispatcher and implementing it as a audio agent, which decides
which audiosystem to use when switching consoles etc.
If pulse developers wants to help in this area, they should sijmply
offer
dmix fallback for pulseaudio instead opening the hardware directly.
> The contrary is however true: a normal user shouldn't be able to output
> sound if he's not in front of the machine. Only root should be able to.
Yes.
> > I think BrlTTY needs to have a better notion of users and sessions
> > and then it will interconnect well with Pulse Audio, DBUS and the
> > other desktop technologies.
>
> How do you log in? Which user is supposed to provide the audio
> feedback?
I am sure the architects will answer with (use the idle user session of
consolekit).
BTW. I hope ck is part of debian's installer??
> > Speech Dispatcher is just an intermediate who can't do much about it.
>
> Well, the issue is that we're here mixing unix users with physical
> users. What we really want is to identify the real user, while
> pulseaudio/dbus/brltty can only deal with unix users. And another issue
> of course is that to actually be able to read the linux console you
> need to be root. Or open the vcsa device first and then change uid. But
> then when logging out the kernel would need to revoke access to the
> already-opened vcsa device. This is becoming really hairy, we really
> need to have a good reason to do it that way.
You made my day. These are my concerns!! as well.
But maybe you have more success to explain the problem to others.
Regards
Halim
Reply to: