Re: [pulseaudio-discuss] Is running as user smart or dumb?
On Thu, 31.12.09 21:52, Bill Cox (waywardg...@gmail.com) wrote: Since I didn't get much response with my more polite e-mail, here's what I really think, given my current ignorance about pulseaudio... PulseAudio is cool, but I fear it's over-engineered by some Ph.D's with too much elegance in their solution, and not enough real world experience. Run as user? Really? I have no Ph.D. Just a stinky old german Diplom degree. Not sure what makes you think this is over-enginereed. Au contraire I would say, there is a lot of stuff that is way too ad-hoc, if you understand what i mean. I just need a solution. I'm frankly hoping to get more response to this more emotional e-mail than my previous polite one. Dude, if you as your questions on the ML while everyone is on christmas/new year holidays, you cannot expect immediate and comprehensive replies. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Is running as user smart or dumb?
On Mon, 04.01.10 23:05, Markus Rechberger (mrechber...@gmail.com) wrote: Please don't post FUD like this on this ML. If you want to spread FUD then I can tell you there are much better fora for that. Lennart, this is more likely your way to ignore user requests. What you need to understand that as long as you dont pay my salary its not you who decides on my priorities. And as long as you dont you need to understand that some user requests which appear sensible, useful and feasible to me are higher on my list than others. Furthermore sometimes we have to make choices and implementing one thing immediately makes it impossible implementing other things. And that also means that some user requests we cannot fulfill regardless how we priorize things. Now, we have thought about this, and in the desktop group at RH we came to the decision that audio cards are inherently a per-seat resource and should not be shared, but stay exclusively with the session that is active on it. And we then implemented that. And the vast majority of other folks agreed with our decision and all relevant distributions adopted our implementation. Furthermore all major non-Unix OSes handle things the same way. Now, there are always people who disagree with our choices. For example, you seem to disagree with ours regarding multi-user support for audio. You are entitled to that. But please, stop complaining about this, and accept that you will not get your way. We gave you good reasons why we did what we did and why we wont fulfill your requests. You seem to think they are not good. You are entitled to think that, but please accept that this does not change anything for us. So please, let it rest, and know that if you want to set the rules then you need to contribute something substantial and more than just some FUD on a mailing list. And that repeating the same over and over does NOT HELP and just annoys everyone else. Thank you for understanding this, Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Is running as user smart or dumb?
On Mon, Jan 4, 2010 at 4:38 PM, Lennart Poettering lenn...@poettering.net wrote: Dude, if you as your questions on the ML while everyone is on christmas/new year holidays, you cannot expect immediate and comprehensive replies. Well, for that I apologize. If you want to see a socially disfunctional group, look up an unmoderated engineering dominated ML. I seriously do appreciate you taking the time to catch up on the e-mail. Bill ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Is running as user smart or dumb?
On Mon, 2010-01-04 at 23:28 +0100, Lennart Poettering wrote:
On Mon, 04.01.10 23:05, Markus Rechberger (mrechber...@gmail.com) wrote:
Lennart, this is more likely your way to ignore user requests.
snip
So please, let it rest, and know that if you want to set the rules
then you need to contribute something substantial and more than just
some FUD on a mailing list. And that repeating the same over and over
does NOT HELP and just \emph{annoys everyone else}.
That is so true
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Is running as user smart or dumb?
A couple of observations and comments to the long discussion from a lurker on this list, obviously with a big IMHO disclaimer. I ended up writing too much, but the final conclusion is short ;-) Bill Cox wrote, On 01/01/2010 03:52 AM: Since I didn't get much response with my more polite e-mail, here's what I really think, given my current ignorance about pulseaudio... PulseAudio is cool, but I fear it's over-engineered by some Ph.D's with too much elegance in their solution, and not enough real world experience. Run as user? Really? Yes. I do think it makes perfect sense that the mixing of _my_ sounds and control of a hardware audio device to which _I_ have exclusive access is done by _my_ service running as _me_. PulseAudio is not perfect, but it is heading in the right direction for _that_ scenario. The use-case you point out seems to be a completely different scenario. You need sound control and mixing before the user logs in, and you need sound from a system daemon to be played no matter what else the user is playing. It really seems like you need system-level sound mixing, not user-level sound mixing. That is not in PulseAudios scope, just like textual consoles and pre-X boot messages isn't the X servers business. PA do not create an architecture where screen readers fits in. But PA can be a part of an architecture where the screen reader problems can be solved. Once the users session and PA is up and running then the users PA should be able to handle speech from the users applications (through orca?). The question is if you want PA to handle that kind of speech or not? If you don't want PA at all then PA obviously can't help you ... perhaps except by making you change your mind ;-) If you want PA for some purposes then all other audio applications (such as system/console screen readers, speakup?) must play by PAs rules and use CK to take and release the exclusive access to the physical devices properly. If you want PA but don't want the the user has exclusive access to the sound hardware concept then there _must_ be some system-level sound mixing that exposes virtual audio devices to which PA and the screen reader software can get exclusive access. Markus pretty much summarized these options, but I think play by CKs rules is missing from the list. Dmix (or PA) as a system-level mixer do however also seem like something that should be investigated. If you think you've got a good reason to do this, is it more important than sacraficing accessibility for the blind? The worst disaster for accessibility for the blind and visually impaired has been adoption of PulseAduio by the major distros. I'm personally spending insane hours trying to fix this mess, and frankly I could use some direction. We've got Orca mostly working now, but the other essential app - speakup - is still in limbo. It seems to me like the old architecture with alsa and screen readers was pretty much hacks. It evolved that way for good historical reasons and worked and solved an important problem, but still it was hacks, and hacks often either prevents further development from happen or breaks when development happens anyway. PulseAudio is different from ALSA, and thus it requires different hacks. Some hacks (or PhD-engineered elegant solutions) might be needed in PA, but probably even more in other applications which the PA developers don't, can't and shouldn't consider their responsibility. Thanks for looking into this! Pointing out that there are problems the developers perhaps wasn't aware of is fine, but insinuating that they are discriminating and sacrificing accessibility for the blind just because something breaks isn't fair. Now the blind community has no pull. We can't tell Ubuntu to run PulseAudio as a normal deamon. As a result, our computers come up talking but then can't talk once the user logs into gnome. This is because speakup launches a process that starts pulseaudio as the gdm user, and since that process continues forever, the gdm copy of pulseaudio never dies, and the user's gnome session gets no access to the sound card, and Orca wont talk. I just need a solution. I'm frankly hoping to get more response to this more emotional e-mail than my previous polite one. I promise to be nice once I'm convinced we're not actually letting a bunch of inexperienced coders undermine the Linux sound system, which is likely to happen once I'm no longer ignorant of what the heck this user-land stuff is all about, and when I learn how to write code that gives the blind speach on their Ctrl+Alt+F1 consoles from boot, as well as after they login. You know what it's like trying to help a blind user through e-mail to figure out what to do when the computer just stops talking? Ever try to explain to a user over the phone how to use a graphical application? It's much worse than that. The sound system needs to work at boot, when we log in, and in fact all
Re: [pulseaudio-discuss] Is running as user smart or dumb?
On Fri, Jan 1, 2010 at 3:52 AM, Bill Cox waywardg...@gmail.com wrote: Since I didn't get much response with my more polite e-mail, here's what I really think, given my current ignorance about pulseaudio... PulseAudio is cool, but I fear it's over-engineered by some Ph.D's with too much elegance in their solution, and not enough real world experience. Run as user? Really? it would be ok as long as it would support multiple users. The problem is that it doesn't care about /etc/group audio permissions and thus breaks backward compatibility with alsa. You have a few options * the easiest one is to remove pulseaudio and get audio work again as it was meant to be (which is also conform to all other unixsystems) * another way would be to run pulseaudio as system daemon (depreciated) * use alsa dmix, and configure pulseaudio to use alsa dmix. Best Regards, Markus If you think you've got a good reason to do this, is it more important than sacraficing accessibility for the blind? The worst disaster for accessibility for the blind and visually impaired has been adoption of PulseAduio by the major distros. I'm personally spending insane hours trying to fix this mess, and frankly I could use some direction. We've got Orca mostly working now, but the other essential app - speakup - is still in limbo. Now the blind community has no pull. We can't tell Ubuntu to run PulseAudio as a normal deamon. As a result, our computers come up talking but then can't talk once the user logs into gnome. This is because speakup launches a process that starts pulseaudio as the gdm user, and since that process continues forever, the gdm copy of pulseaudio never dies, and the user's gnome session gets no access to the sound card, and Orca wont talk. I just need a solution. I'm frankly hoping to get more response to this more emotional e-mail than my previous polite one. I promise to be nice once I'm convinced we're not actually letting a bunch of inexperienced coders undermine the Linux sound system, which is likely to happen once I'm no longer ignorant of what the heck this user-land stuff is all about, and when I learn how to write code that gives the blind speach on their Ctrl+Alt+F1 consoles from boot, as well as after they login. You know what it's like trying to help a blind user through e-mail to figure out what to do when the computer just stops talking? Ever try to explain to a user over the phone how to use a graphical application? It's much worse than that. The sound system needs to work at boot, when we log in, and in fact all the time. Is that too much to ask? That's what I require from Ubunut/Lucid. I'm willing to write the code to make it happen. Can anyone please advise me on what code needs to be written to get speakup and Orca to both work with pulseaudio, from boot, after logging into gnome, and on the console windows? Bill ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Is running as user smart or dumb?
Since I didn't get much response with my more polite e-mail, here's what I really think, given my current ignorance about pulseaudio... PulseAudio is cool, but I fear it's over-engineered by some Ph.D's with too much elegance in their solution, and not enough real world experience. Run as user? Really? If you think you've got a good reason to do this, is it more important than sacraficing accessibility for the blind? The worst disaster for accessibility for the blind and visually impaired has been adoption of PulseAduio by the major distros. I'm personally spending insane hours trying to fix this mess, and frankly I could use some direction. We've got Orca mostly working now, but the other essential app - speakup - is still in limbo. Now the blind community has no pull. We can't tell Ubuntu to run PulseAudio as a normal deamon. As a result, our computers come up talking but then can't talk once the user logs into gnome. This is because speakup launches a process that starts pulseaudio as the gdm user, and since that process continues forever, the gdm copy of pulseaudio never dies, and the user's gnome session gets no access to the sound card, and Orca wont talk. I just need a solution. I'm frankly hoping to get more response to this more emotional e-mail than my previous polite one. I promise to be nice once I'm convinced we're not actually letting a bunch of inexperienced coders undermine the Linux sound system, which is likely to happen once I'm no longer ignorant of what the heck this user-land stuff is all about, and when I learn how to write code that gives the blind speach on their Ctrl+Alt+F1 consoles from boot, as well as after they login. You know what it's like trying to help a blind user through e-mail to figure out what to do when the computer just stops talking? Ever try to explain to a user over the phone how to use a graphical application? It's much worse than that. The sound system needs to work at boot, when we log in, and in fact all the time. Is that too much to ask? That's what I require from Ubunut/Lucid. I'm willing to write the code to make it happen. Can anyone please advise me on what code needs to be written to get speakup and Orca to both work with pulseaudio, from boot, after logging into gnome, and on the console windows? Bill ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
