Re: Activation of Speech Dispatcher under squeeze
Hi,
On So, Sep 26, 2010 at 07:12:15 +0200, Samuel Thibault wrote:
> Halim Sahin, le Sun 26 Sep 2010 18:45:29 +0200, a écrit :
> > > 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.
>
> Which other tasks?
Acting as a speech-server for _all_ applications who needs to produce
speech? I mean all screenreaders including console and graphical ones.
Btw.: I also use some tts in shell/perl skripts eg. for irssi.
> Again, what you call a systemwide speech-dispatcher
> is actually just a speech-dispatcher for the main linux console.
No! In the past we all used only a single instance of speech-dispatcher
running in systemwide mode for both worlds (txt and grphical mode).
>
> > The only critical part of these problems is how audio can be played in
> > the different sessions.
>
> If you have multiple seats, yes, but then it's a matter of running one
> speech dispatcher per seat.
Why that? one speechd instance can handle several inputs comming from y
screenreaders. running the speech server in multiple sessions wouldn't be
needed if the single instance of sd could output audio.
This is the reason why the audioplayback task of speech-dispatcher
should be seperated and implemented in an audio-agent.
>
> > There is no need for mooving sd into userspace.
> > That wouldn't improove anything for the console users.
>
> Sure, for the console, there's just need for one speech dispatcher, for
> the whole linux console seat.
Maybe we are talking about different things.
Let me explain my current setup:
I have configured pulseaudio this way that it doesn't block the
audiocard and uses dmix (I am aware that this is not recommended :-( ).
I use one single speech-dispatcher with libao audio output.
Sbl starts for my textconsole and after login to gnome orca uses the
same sd as sbl.
I know this is not perfect but works stable for me here.
When I use pulseaudio with it's default setup, I wouldn't be able to use
a single sd instance for both screenreaders because sbl needs root
access, sd running in systemmode would block the audiocard.
At that point sd must be started after graphical login.
Sbl will start talking after gnome login.
.....
I can't understand why we need several speech severs running for the
same task (providing tts for screenreaders).
The only thing which needs to be handled in the diffeerent seats is the
audiooplayback of the produced speech-samples.
Regards
Halim
Reply to: