[pulseaudio-discuss] Multiple users (kde) on Debian

[Colin Guthrie]

'Twas brillig, and Halim Sahin at 24/08/10 19:38 did gyre and gimble:
>> Layering one software mixing system on top of another however is a very
>> silly idea, adding slowdowns and overhead to a pipeline that tries very
>> hard to minimise locking and copying to avoid such latencies.
> 
> That's a really bad example here to mention the latency problems.
> I don't know how much you know about the used tts systems.
> It took more than two years to write a working pa driver using the
> simple pulse api.
> The first available pa driver for speech-dispatcher used the other api
> and was never usable (see the pa mailinglist archives).
> Sure you are right it wouldn't be the best software design but it would
> work, what the current approach doesn't (read below).

I'm not entirely sure what when wrong there then, but many people work
with PA's APIs and don't have such issues. Even using the alsa plugin
for PA in 99% of cases will work fine. But it's not really the point of
discussion on this thread.

>> Running two software mixers is not the solution to the architectural
>> differences of the PA model to any existing one. Our goal is to ensure
>> that only the the active user can access the sound hardware (and not
>> just sound hardware but USB ports etc. too). The people advocating PA on
> 
> You assume that all applications run in #
> the foreground but infact that's only true and allways possible.

I do not make that assumption at all: I am just describing a clear
separation of logic and output.

>> top of dmix are those users who do not like that model and don't care
>> about the consequences of what they are suggesting from an
>> implementation perspective.
> 
> NACK.
> That are the people who have no other chances to use their computers
> :-(.

That's not a reason to NAK. Just because it's the way some people have
made things work, does not mean it's the right decision. I may have a
broken window and to stop thieves getting into my house, I nail up a
board of wood across the space. That's simply because I don't have a
pane of glass to hand. Sure it's *a* solution, but it's not the *right*
solution.

> A console screenreader doesn't need gdm session or any pseudo sessions.
> It should provide acess for plain logins.
> On my machine I frequently use the plain console and switch sometimes
> into gnome for doing some tasks.
> Now your proposed design will have some unwanted effects:
> For accessing the audio hardware the tts system (speech-dispatcher) has
> tu run under the same user or in the pseudo session.
> Mooving it from the init process has the effect that the screenreader
> which is started during initprocess can't connect to it because at that
> time no gdm and no usersession is active.
> Before you answer why not mooving the screenreader in to usersession:
> The screenreader (eg. sbl) supports speech and braille output.
> For braille output it support the cursor routing function.
> A brailledisplay has eg. 80 cels. On top of each braille module you can
> find the called curosor routing key.
> Pressing that key mooves the cursor to that position in editors etc.
> To implement that feature sbl must access some device nodes and insert
> the wanted key to track the cursor to the requested position.
> I spent a lot of time to implement this in userspace but had no success.
> It will end in rewriting big parts of sbl and we won't  get any improovment after doing that by doing that.
> A big problem is that the same user has to start several instances of
> sbl on every console which is hard to implement.
> 
> 
> 
> 
>> As we discussed previously the pseudo session started for the GDM login
>> prompt is the right approach here. There is always an "active" user,
> 
> No!!!

None of what you said above causes me to doubt the approach we have all
previously discussed. The architecture is wrong. Provide a *single*
system service that does all the work. Do not run several instances of
it for each user or login shell. In the pseudo sessions or real user
sessions, run an *agent* that is the lightweight layer that connects to
the system process and does the sound output. This way you get *user
specific* settings. Users with a11y needs and users without such needs
can share the same machine and not have to worry. The sysadmin would
configure the login sessions to be a11y and thus they will run agents.
As a a11y user, Bob will have his user account configured to run agents
too. But Sally who does not need such things does not have the agents
enabled.

This model is not that complex and gives full control, configuration and
separation.

Some of the Canonical guys who were looking at this in the past can
probably describe things better than me.

Col



-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]