RFC: #2 Separating audio output system for session integration

[Halim Sahin]

Hi,
On Fr, Aug 27, 2010 at 12:50:24 +0200, Andrei Kholodnyi wrote:
> Hi Halim,
> 
> > Now we came up with the following suggestion:
> > Seperate the whole audio output (sdaudio) from speech-dispatcher,
> > Run the speechd again in system mode and implement a small application
> > which connects to speechd gets the data for output and chooses according
> > to it's running session the right audiooutput method.
> > Colin called that application a speech-dispatcher-agent.
> 
> Could you please describe in more details why you might need speechd
> running in the system mode?
> As far as I can see most of the use cases are user specific:
> - user would like to have user specific configuration

Which ones?
In the future we should try to implement automatic module detection for
speechd.
All other settings should be handled from the screenreaders
sbl,orca,brltty etc.

> - user runs specific apps on top of speechd e.g. ORCA etc.

Right and they should control used synth, punctuation, languageselection
ratesettings etc.

> But for sure I'm missing something here.

The approach binding the speechd-server to current active session whould
increase complexity in the screenreaderstartprocesses.
Using my suggested approach will reduce these dramatically because the
only frequently changing behaviour of a sessionchange is audioaccess.
There is no need for the (core) functionality in speechd to 
alter it's session etc.
In that case seperating audiooutput would have the most advantage for all
kind of screenreaders because those could be started once in one session
(sbl and brltty) and wouldn't need pseudo sessions etc.
The speech-dispatcher-audio-agent will choose the right audio-output in
the current active session.
That agent needs to be restarted or suspend when consolekit recognizes a
sessionchange.

Hope that helps :-).
Gru?
Halim