<quote who="Peter Rundle"> > I also never managed to solve the sound lock out problem. My system is > running esd, and in theory esd sould manage/mix multiple audio out > requests, but when the first user logs in and esd gets started, the esd > process is owned by that user. Something also sets the permissions on the > audio device to be u+rw only for that user, i.e no group prviledges. If as > root you overrode the audio device to be g+rw, then the second user could > play sound, but as soon as the first user logged out, esd died and the > permissions of the audio device went back to root ownership. A better > solution would obviously be for esd to be a system process started in > /etc/init.d with a config somewhere that allowed the admin to define which > users had access.
Is this on a Red Hat like system? There are two problems involved here, and I think it's subtly different to the problem explained above. The first is that if your hardware doesn't support multiple writers, the second esd won't be able to open the device anyway. However, I don't think that's the problem you're seeing; I have a suspicion it might be related to consolehelper stuff in Red Hat like systems, which set special permissions for users who have logged in "locally" (at the console). I can't say for sure, but your problem is either a) you can't have a second writer with your hardware or audio driver, whether it's esd or not or b) consolehelper gives the first user exclusive access, blocking out the second. > I never found out which bit of code was setting the privledges but it > smacks of "we know better" something we all critise Microsoft of Whoa there... Now you're attributing systemic silliness to malice... And comparing it to Microsoft! Yowza. Let's stand back for a minute. The issue here is *caused by* either a) crappy modern audio hardware or b) sensible security policy defined by your distribution (which can be administered by you!). > and an attitude that is detectable in Jeff's postings on this subject. I > think jeff should take a few humility pills, and perhaps maybe accept that > even if he does know better, as end users, that's not what we want. Dude, I don't make crappy modern audio hardware that doesn't do hardware mixing, nor do I define security policies for your distribution. Nowt to do with me, sorry to say (though it's nice to have a scapegoat). > I've actually given up using Gnome because I just don't like the direction > the development is going. This is of course a personal thing and others > may love it but for me Gnome has just become annoying. Luckily, this issue is unrelated to GNOME, but regardless, I would love to hear more from you about what has turned you off about it. > Whilst some of his arguments about dynamically running processes etc are > somewhat valid, but we also know that when processes aren't in active use, > the magic linux kernel tends to swap them out and recover the memory, > which is so cheap and plentiful these days anyway that the whole argument > is just "so last centuary" Providing a user interface that normal human beings can use is "so last century"? I think you may have misread my point... > Also his just argued that we should get rid of the ctrl-alt-f1 etc to drop > to a shell and include it into Gnome, because it's just another user > session, and those mingettys man they must be chewing up CPU and memory! > ;-) Ah, no, I did not say that at all. We were talking about different methods of providing multiple local X logins via GDM, which *does* provide a nicely dynamic way of doing it instead of having to configure it first (much like Windows XP and OS X). - Jeff -- GUADEC 2005: Stuttgart, Germany http://2005.guadec.org/ "You gotta know when to hold 'em, know when to fold 'em, know when to walk away, and know when to run." - Kenny Rogers, The Gambler -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
