'Twas brillig, and Bill Cox at 10/02/10 10:50 did gyre and gimble: > Here's what I don't understand. Why doesn't PA run in system-wide > mode, but still do all the same user-permission checks it does now, > and only authorize the current user to access the sound card? Is > there any advantage in running the whole PA daemon in user space? Why > have multiple PA processes running when there are multiple users? > Doesn't this waste memory? > > If PA were run this way, it would be trivial to allow specific root > processes or authorized users to access the sound card at the same > time as the current user. Yes the system-wide approach works fine for this, but it still doesn't address several issues. One is the fact that why should a module be loaded into a system-wide component for a specific user? e.g. user A pairs his bluetooth headset which will require that the bluetooth sink becomes available - this should only be for user A, no other users, but user A is somehow allowed to load a module into the system service for this to happen. Users loading modules into a system service is generally a security concern (which is my most system wide daemons disallow module loading). Lots of things about the sound stack are per-user (e.g. my Apple Airtunes, my Bluetooth devices etc. etc.) and pushing these into a system service does not make sense. It is possible that a system wide component could drive the local hardware and a per-user component is able to deal with all the other stuff, per-user settings and devices etc. but also communicate with the server side componenet to deal with local physical hardware. This approach is much more complex and would no doubt introduce a lot of potential problems regarding SHM security and such like but it should all be possible. That said I'm not convinced there is a compelling enough use case to go down this route anyway as I've pointed out. Also there is always going to be the argument that X is a system device in one context and a per-user device in another. e.g. this apply airtunes is in my room so it's mine, but this one is in the kitchen so it's everyone's. No matter what approach you take there are always going to be some people who want it to work another way. We've got to concentrate on the majority use cases and so fare the only awkward ones pointed out are very niche and really are getting far too much discussion time already considering the overall goal. > Also, why does zero latency by default increase CPU power? SFAIK, > zero latency (or inperceptably small) is the default in all other > sound systems, and I haven't heard of increased CPU usage as a result. http://0pointer.de/blog/projects/pulse-glitch-free.html In an ideal world you want a latency of about 2-10 seconds depending on context of the running application (e.g. a music player where you don't rewind/fast-forward too much and do not mix audio over the top too often should have a very high latency to allow the CPU to sleep as much as possible rather than wake up to service audio data. 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/]
