Hi, On Di, Aug 24, 2010 at 09:39:17 +0100, Colin Guthrie wrote: > 'Twas brillig, and Jeremy Nickurak at 23/08/10 15:40 did gyre and gimble: > > No, that's not the right approach. This has been discussed many times on > > this list. Just look at the archives, I'm not wasting hours of my life > > reiterating what has already been discussed. > > > > A quick look around with google didn't indicate anything, except > > instructions on how to enable dmix instead of/in-addition-to pulseaudio. > > > > Dmix seems to be the solution that alot of the pulseaudio critics > > suggest as the silver bullet to audio problems... maybe the argument > > about dmix can be iterated once more in a wiki page, so there's a more > > permanent reference for that information? > > DMIX is very clever in itself, and in the absence of PA on a given > system, I'd very much recommend it's usage. +1 > 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). > 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. > 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 :-(. 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!!! Gru? Halim
