Re: [orca-list] sound through pulse audio running as root may soon be fixed

[Luke Yelavich <luke yelavich canonical com>]

On Mon, May 09, 2016 at 04:40:51AM AEST, Jason White wrote:
> And not just the Windows users - Mac OS X, iOS, Android and Chrome OS users
> would find the presence of these problems astonishing. To my mind, they're
> unacceptable, and they demonstrate a lack of good collaboration in the Linux
> community to design a reliable audio system that can meet the needs of all its
> users, including those who run screen readers.

A lack of collaboration yes, and I'd also argue a lack of keeping up with
the evolving Linux ecosystem as well.

> Luke Yelavich has discussed plans for addressing these concerns on previous
> occasions. Unfortunately, he seems to be the only person actively working on
> them, and his availability is limited, for good reasons (i.e., I'm sure it's a
> case of too many projects and too little time).

I could write out another explanation of what needs to be done, but I
don't think this list is the right place for it, and it will likely go
over many a head anyway, but the essential points are this:
* For a while now, the problem hasn't been PulseAudio, the problem has
been getting audio working properly in the console.
* PulseAudio runs as the logged in user for a very good reason, and in
light of more distros, and desktop environment developers looking to
sandbox applications, this is going to be even more important going forward.
* As per the above, we need to move the likes of speechd-up and brltty
away from running as root, and running them per user.
* We also need to work with upstream to develope a mechanism to allow us
to use assistive technologies like speakup + speechd-up or BrlTTY at the
console login prompt. The GUI issue is already solved, since GUI login is
done as a user already.

> We need a few more people with audio programming expertise to join him in
> solving these problems, as well as some agreement among Linux audio developers
> on the plan for doing so.

Again as I see it, its purely a permissions problem, and in the case of
the text console login, we need to run any desired assistive technologies
in a so called idle session. The most work would likely need doing to
Systemd/LoginD, and BrlTTY, since it is pretty easy to create appropriate
udev rules to ensure the speakup softsynth device node is only accessible
from a logged in user, or the idle session.

> PulseAudio also supports network-based sound transmission, which is
> potentially beneficial for people who need to run Orca on remote systems. (It
> may also be possible to provide remote access to braille displays using Brlapi
> and network sockets).

I think PulseAudio even goes so far as to work over an SSH session, although
I think it needs an X session to attach itself to. For remote sessions,
I think it would be worthwhile investigating whether BrlTTy and Speech
Dispatcher could do the same.