Re: Activation of Speech Dispatcher under squeeze
Halim Sahin, le Sun 26 Sep 2010 21:53:33 +0200, a écrit :
> 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.
That's what a common speech-dispatcher can be used for. Really, I think
we're talking about the same thing and just not putting the same words
on them. What I call a "system" speech-dispatcher is something that
_all_ applications would output to. This won't work with a multiseat
setup, where there are several audio cards for the various seats. You
need one speech dispatcher per seat, that's all.
> > 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).
That's the speech-dispatcher I'm talking about. By "main linux console",
I include the graphical mode.
Then you have the case when there are several graphical seats. There's
still one that is along the linux console and which should probably
share the same speech dispatcher.
> > > 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?
Because else it's a mess!
How can two users work independently (that's what "multiseat" means) if
they hear the actions of each other?
> one speechd instance can handle several inputs comming from y
> screenreaders.
Yes, but multiseat means you want separate output, precisely.
> > > 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.
No, we're just not understanding each other due to using different
vocabulary.
> 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.
Yes, that's what I mean by "one speech dispatcher for the linux console
seat".
> 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.
That's why I'm against pulseaudio not accepting output from root.
> I can't understand why we need several speech severs running for the
> same task (providing tts for screenreaders).
Because in multiseat setups you need independent output.
> The only thing which needs to be handled in the diffeerent seats is the
> audiooplayback of the produced speech-samples.
No, you also need to keep the feedback from screen readers separate,
because else it's a mess.
Samuel
Reply to: