On Sat, 2009-12-26 at 08:31 +0100, Halim Sahin wrote: > Hi, > On Do, Dez 24, 2009 at 06:27:25 +0100, Lennart Poettering wrote: > > On Fri, 25.12.09 00:47, Ng Oon-Ee (ngoonee at gmail.com) wrote: > > > > > > Running PA doesn't mean ALSA is out of the game. PA builds on ALSA and > > > > as such everything you could do with ALSA before stays available with > > > > PA too. > > > > > > > > However input output deamons should definitely be part of the user > > > > session. That is true for PA itself AND any kind of speech daemon and suchlike. > > > > > > > > Lennart > > > > > > > I believe in his particular use-case he's concerned about the > > > screenreader prior to the DE starting up (boot messages and the like?). > > > > We actually cover that inside of gdm, where you can get access to the > > boot messages. > > Ok what about consolescreenreaders like sbl brltty or speakup? > They need a working audiosystem to provide > usefull stuff before login or to read the login pprompt. > With pulseaudio I need to login without feedback, start the speech server and > then restart the screenreader. > > sorry folks I seems that you can't sink of usecases other than yours. > Facts are: > You have developed a new audio system which brings more flexibility and > features to us. > Unfortunately you expect that all projects should rewrite their audio > stuff to work with your system. > By design mac and windows are not comparable with linux > because they are not a multi user OS. > > For german users: > http://www.stud.uni-hannover.de/stud/unix-ag-bhb/node27.html > > changing the unix behaviour is the main problem here. > Maybe you don't need this but others do. > > It should be possible to use the audiosystem the (old way). > > Just my 2 cents. > Halim > I've been following these discussions with some (layman-level, I don't dev for pulse) interest, and I'm wondering whether a simple solution would be to use alsa-output prior to login and pulseaudio after login. A bit of configuration required instead of re-writing apps. Something would have to be done to get the screen reader to not hog the hw when the user is logged in, that shouldn't be too difficult though. I must admit its good to hear of an actual use-case where such behaviour is useful, instead of some of the random complaining that comes here seasonally.
