Re: [g-a-devel] Speech-dispatcher/orca integration specification, first draft.

[Eitan Isaacson <eitan ascender com>]

Hi,

(note: practical suggestions follow philosophical contemplations)

Screen reader sound support seems to be regressing on Linux, this is
bad. With that said, I think that in the long run PulseAudio will have
been the right choice, the main benefactors will be people who depend on
auditory displays, and this is good. PulseAudio will ultimately allow us
to take full advantage of our audio devices, with multiple streams,
network transparency, and other great tricks.

We are right now in an in-between state, and that is unfortunate.

The entire Linux desktop has slowly been moving services from the system
into the session, for example volume mounting, network settings, even
display configuration. One of the motivations is security: The current
user should have control over the hardware. This is especially prevalent
in a system with "fast user switching", where more than one session is
active in parallel. Further, an equally privileged, non-root user who
logs on remotely to a machine you are physically sitting at should not
be allowed to eject the CD drive, play scary sounds, listen in on the
microphone, reconfigure the network or reboot the computer.

I think this debate goes beyond accessibility requirements and into the
"old" and "new" way of doing stuff. I miss having absolute control over
the network with ifconfig, but NetworkManager is very appealing to users
who never considered Linux before, not to mention it saves a lot of
hassle in a wifi world.

I believe the best solution to the current cacophony is to think how we
fit in to this new world of system/session separation. One wild proposal
might be to have a system-wide speech service that is only used in
console mode (and only the current console user would have privilege to
use it), and would not hog the sound device when not speaking. When the
user is in-session, the speech service Orca would use would be a session
service that would take advantage of the session's PulseAudio instance.
I didn't put much thought into that, I am just trying to think of the
console/desktop paradigm, and how we could make the auditory output work
with the same paradigm that the visual output does.

Cheers,
   Eitan.

On Tue, 2009-03-24 at 09:57 -0400, Janina Sajka wrote:
> Luke Yelavich writes:
> > On Fri, Mar 13, 2009 at 11:58:26PM EST, Halim Sahin wrote:
> > Also don't forget that PulseAudio's primary developer doesn't recommend running PulseAudio system wide, except for special circumstances like embedded devices wishing to offer PulseAudio's audio networking features. In any case, Ubuntu will be configured to run speech-dispatcher and pulseaudio in the user's session, however you will be free to change this should you wish to do so.
> > 
> 
> 
> I engaged him on this point on one of the Fedora lists. Turns out the
> rationale for this point his highly specious. 
> 
> He claims there's a security concern in that a shared display
> enviornment might otherwise allow the other user to gain control of the
> microphone and listen in on a conversation sureptitiously.
> 
> As I said, it's specious. Listen in on a shared display? How common is
> the shared display? And, when would it not be in the same room? Probably
> five feet away?
> 
> I warrant their was little, or at best highly inadequate use case
> gathering before pulseaudio went into development.
> 
> There are also serious issues with pulseaudio on the console that make
> it simply inappropriate for use as things stand today. Start to play
> some wav file, then switch consoles. Your audio playing stops until you
> return to the console where you launched the play command--at which time
> it resumes precisely where it was when you left that console. This is
> also inappropriate behavior and further evidence of insufficient use
> cases before development.
> 
> I'm not convinced we can rely exclusively on pulseaudio. For one thing,
> it wouldn't also support non Linux environments like Solaris that still
> use oss.
> 
> Janina
> 
> > Luke
> 
> 
> 
> > _______________________________________________
> > Gnome-accessibility-devel mailing list
> > Gnome-accessibility-devel gnome org
> > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
> 
>