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

Re: Activation of Speech Dispatcher under squeeze



Klaus Knopper, le Sun 26 Sep 2010 23:14:42 +0200, a écrit :
> 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".

Yes, that's what I mean, it's just a matter of how you call them :)

> > > > 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.

Sure, in my words I include that into "linux console".

> Why should orca use a different instance of speech dispatcher than the
> textual consoles do? Sounds inefficient to me.

I'm not suggesting that. I'm saying for another seat you'll need another
speech dispatcher.

> > 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.

Sure, I do agree.

> > > > > 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.

Again, we appear to crazily agree, but not manage to agree that we
agree.  I'm _not_ saying what people have been doing in the past
(logging in several VTs on the linux console) is a mess. What I'm saying
is that several people working on the same computer using several seats
(i.e. several keyboards and screens) should have separate soundboards to
be able to work independently.

> > 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.

?!?!?!?!?!?!?!?

What I'm describing above is PRECISELY what multiseat is.
Just to make sure: when I say "user" above, I mean real users, not Unix
users. If you have several real users working at the same time on a
machine, you have multiseat.

> 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.

Sure, that's what I mean too.  It should just not really be called
"system-wide", since it's just for the standard linux console + graphic
environment, and other seats wouldn't use it.

> > > one speechd instance can handle several inputs comming from y
> > > screenreaders.
> > 
> > Yes, but multiseat means you want separate output, precisely.
> 
> Not necessarily,

?! Well, yes, because else it's a mess.

> but I got your point.

I'm not sure you really do, because you seem to understand what I'm
trying to explain not the same way I understand it.

> 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.

And used by different _real_ users? (not unix users)

> > > 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.

Sure, that's what I mean.

> > > 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".

Again, what do you call a "seat"?  It seems to me we're not giving it
the same meaning.

> > > 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).

Really, we're definitely not calling "seat" the same thing.  Please
check on the Internet: multiseat means different *real* users.

Actually these users could even be using the same unix user account. But
really, they need different speech-dispatcher instances to get different
sound output because else they won't be able to work independently.

Samuel


Reply to: