[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Activation of Speech Dispatcher under squeeze



Hi,
On So, Sep 26, 2010 at 06:13:00 +0200, Samuel Thibault wrote:
> Halim Sahin, le Sat 25 Sep 2010 09:28:23 +0200, a écrit :
> > On Fr, Sep 24, 2010 at 11:42:47 +0200, Hynek Hanke wrote:
> > > This is not so easy as just writing audio to roots default
> > > soundcard. The root would need to know which is the
> > > proper audio device for the target user, and that is being
> > > assigned dynamically in Pulse Audio, AFAIK.
> > > 
> > > I don't think it is Speech Dispatcher's task to, for every
> > > user, query their current audio device setup, listen for
> > > fallbacks on sink changes in PA etc. This sounds difficult!
> > 
> > Colin Guthrie from Pulseaudio project wrote this about the prefered
> > design how things can work nicely togehter:
> > --
> > speech-dispatcher itself can do all the necessary work in a system-wide
> > process but only the speech-dispatcher-agent will actually cause any
> > audio to be output. The agent runs as the same user as the PA process
> > (whether this be the pseudo session's "user" or the real user).
> 
> That looks actually weird to me.  

Why?

> If you have multi seats, you do _not_
> want a system-wide process, just one per seat.

Right and this part does only playback the audiosamples and was called
speech-dispatcher-audio-agent.-
All other tasks can be handled from a systemwide Speech-dispatcher which
would be available in early boot proccess for console screenreaders and
after login for orca etc.

The only critical part of these problems is how audio can be played in
the different sessions.
There is no need for mooving sd into userspace.
That wouldn't improove anything for the console users. 
Implementing a small audio agent which watches ck on session changes,
redrive the samples and play them back.



Reply to: