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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
