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 > > _______________________________________________ Gnome-accessibility-devel mailing list Gnome-accessibility-devel@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
