[pulseaudio-discuss] system-wide daemon

[Colin Guthrie]

'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/]