Re: Activation of Speech Dispatcher under squeeze
Hi,
On Sun, Sep 26, 2010 at 10:27:32PM +0200, Samuel Thibault wrote:
> 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.
Actually, it would work with a multiseat setup if you can have simultaneously
- the system-wide speech-dispatcher for everything but remote "seats", as you call it,
- per-user speech-dispatchers with different output devices for remote "seats".
Default should IMHO be one system-wide speech-dispatcher that can be
started before login by an init script, with the option for individual
processes to fork their own user-session-specific copy/setup.
> > > 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.
There is not only the local "main linux console", but also the local X
display(s) for a machine used by a single user, which is a very common case.
Why should orca use a different instance of speech dispatcher than the
textual consoles do? Sounds inefficient to me. Speech support should be
a system service by default, not by exception. Therefore, I support
Halims recommendation.
> 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.
Except for shared computers with thin client displays, different seats
at different places is rather the exception than the most common setup.
> > > > 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!
I don't think that the way we have used speech-dispatcher in the past,
and some of us wish to continue using it in the future, was (or is) a
mess. It's nice to have session-able instances as a new feature. But it
should not replace or obsolete the system-wide variant that has been
working pretty well for a long time.
> How can two users work independently (that's what "multiseat" means) if
> they hear the actions of each other?
Halim has explained his usage scenario, which is independent from the
multiseat setup. His view does not conflict with yours.
My usage scenario is having a system-wide speech-dispatcher running on
each host system (or "seat") where a user works using a textual as well
as graphical screenreader, and can switch between graphical and textual
console, without having to use different instances of speech-dispatcher.
Also, chat programs like irssi or ysm, should queue their messages in
speech-dispatcher in a way so that different instances don't interfere
with each other. I think that is much easier with a system-wide
speech-dispatcher for a single-user-setup, rather than concurrent
instances or speech-dispatcher for "seats" that are actually all
occupied by the same user.
Actually, I'm now running a fork of speech-dispatcher 0.7 (with Halims
libao patch) set on hold since I'm afraid that the system-wide version
will break when being updated from Debian/squeeze by the user, and to
avoid the bad surprise of his/her computer stop talking after an update.
> > one speechd instance can handle several inputs comming from y
> > screenreaders.
>
> Yes, but multiseat means you want separate output, precisely.
Not necessarily, but I got your point.
In my setup, even multiseat means I want one single instance of
speech-dispatcherm used by different local screenreaders and individual
applications, some of them system-wide services, some of them user-launched.
> > 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".
...and all the locally used X- and VNC-Servers, and possibly other
displays used at the same place by the same user, but maybe in different
sessions. It should be possible to rely on having just one.
> > 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 use libao and alsa, but this is an independent topic.
> > 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.
Again, this is not always true. I want to have the option to use
one speech-dispatcher for serving different "seats".
> > 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.
It's not a mess in my example, which is a very common case (one
computer, different parallel seats, all for the same user).
Regards
-Klaus
Reply to: