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

[Hynek Hanke]

Hello Luke,

I think we still misunderstand each other and the solution we are 
proposing is actually simpler than you think.
> 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.
>   
I didn't suggest that the user's GNOME session application should be 
talking to PulseAudio running under the speech-dispatcher user. Please 
read my post carefully again.
> 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.
>   
What kind of logic? On my Ubuntu Gutsy + Pulse from Hardy, I just launch 
these two instances and it works as I described.
> 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.
>   
No, this is wrong. I have a single channel soundcard. I can start an 
instance of PulseAudio under the user 'speech-dispatcher' and another 
one under 'hanke'. I can paplay a sound from both users using both Pulse 
Audios as long as I do not attempt to play these two sounds at once. In 
such a case, the later paplay fails and the according Pulse Audio will 
complain about not being able to access soundcard.
> 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.
>   
I hope so. Even if there is no extra logic, and the system wide 
speech-dispatcher runs on 6560 and the
user speech-dispatcher allways runs on 6561 (irrelevant of the current 
user), this covers most situations
(switching of users won't work without additional configuration etc., 
but this is a far minor problem than
the former one where nothing works :)
> Even if this were possible, at this late stage of the release, these changes 
> are way to invasive.
I don't believe so. It is only changes in the package speech-dispatcher, 
so very little harm to non-accessibility users can be done.
>  Yes speech-dispatcher would have to be changed, but so would pulseaudio's 
> default configuration, something that could then present further security 
> issues.
>   
I understand we can't change pulse audio configuration, but I didn't ask 
for this. We do not need it, luckily.
> 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.
>   
With regards,
Hynek Hanke