[orca-list] Pulseaudio and speech-dispatcher/gnome-speech in Ubuntu.

[Luke Yelavich]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Apr 17, 2008 at 01:27:16AM EST, Hynek Hanke wrote:
>
> Hello Luke,
>
> we have tried to analyze and test the thing and we believe
> the setup that eliminates all the problems would be as described
> here (a rationale follows):
>
> 1) Speech Dispatcher is setup to use PulseAudio under all circumstances.
>
> 2) General-use Speech Dispatcher (for use outside gnome-session)
> is being launched from /etc/init.d/speech-dispatcher with default="yes"
> under user speech_dispatcher together with its own pulse audio
> daemon running under the same user (speech_dispatcher).
>
> 3) Under gnome-session, each user is supposed to run its own
> instance of Speech Dispatcher. /usr/bin/speech-dispatcher is
> a wrapper script that if not executed by 'speech_dispatcher' or 'root'
> will check for the presence of ~/.speech-dispatcher and if it wont
> find the directory, it will create the necessary structure, copy the
> configuration from /etc/speech-dispatcher/, modifies the default
> port number from 6560 to 6561 and sets the environment
> variable SPEECHD_PORT to this value.
>
> Rationale:
> 1) There will be no conflicts between (2) and (3). There can be
> multiple Pulse Audio daemons running on a system under different
> users and they don't prevent each other from launching and speaking.
> The only thing that is not possible is to mix two simultanous streams
> between these two instances of Pulse Audio. This is not a problem.
> The assistive technologies working inside gnome-session will use
> the user instance of Speech Dispatcher (3) and assistive technologies
> outside gnome-session will use system wide Speech Dispatcher (2). Outside
> gnome-session work BrlTTY, Speakup, Yasr, GDM Login etc. The user
> either is in X or is not, so there is no need for mixing.
>
> 2) The wrapper script makes sure that the user is not forced to do
> extensive configuration before hearing the very first piece of speech
> from Speech Dispatcher after its instalation. We are now doing it
> because we were forced by Pulse Audio, but it will be a general
> simplification and I think a good improvement.
>
> 3) There is no chance that we would break something other
> than Speech Dispatcher doing these late-time changes, since all these
> changes will be made in the Speech Dispatcher package and thus only
> users installing this package will be affected by possible catastrophes :)
> And even for them, there is very little chance that it would actually
> work worse than the current solution.
>
> Please try to think about it and ask any questions you have. The only
> work that needs to be done is to
>
> 1) Modify the Speech Dispatcher init script to launch an instance of  
> PulseAudio.
> 2) Create the mentioned wrapper script.
>
> Please, would you be able to do these changes or do you need
> our help? We are really interested in making it work in Hardy.
> When there will be a testing package, we will be very happy
> to try it out and confirm there are no issues.

Thanks for the suggestions, however these break in bad ways.
1. Ubuntu's version of PulseAudio uses sockets for every instance running. So 
if PulseAudio was running as the speech-dispatcher user for the system-wide 
speech-dispatcher daemon, the user's GNOME session and speech-dispatcher 
instance would not be able to work with it, unless PulseAudio was configured to 
use TCP ports.
2. Logic would have to be put in place to make sure that the GNOME session's 
instance of pulseaudio that gets launched knows about the existing instance.
3. It is not possible to run more than one PulseAudio instance, unless you 
happen to have 2 sound cards, as PulseAudio talks to the sound hardware 
directly, as I've already explained.
4. Extra logic would have to be in place to make sure different users used 
different ports in their local configuration files. This is trivial however.

Even if this were possible, at this late stage of the release, these changes 
are way to invasive. Yes speech-dispatcher would have to be changed, but so 
would pulseaudio's default configuration, something that could then present 
further security issues.

I think the best bet at this point is to not start speech-dispatcher by 
default, and then users can enable/configure speech-dispatcher as they wish. 
Thats the best I can do right now.

Luke
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIBqOsjVefwtBjIM4RAqVlAJ9vEkjKyPID0T33+M73ubi8TsulrACgpLmj
/ICZaVU8ja0zmqX5HP999uE=
=1/MR
-----END PGP SIGNATURE-----