[pulseaudio-discuss] system-wide daemon

[Bill Cox]

Ok, the new "glitchless" code sounds cool.  Reducing the interrupts
seems close to pointless from a power savings view, unless we're in an
embedded environment where we slow down the CPU and lower it's power
on sub-second intervals.  Otherwise, copying the data the data to the
sound buffer will heavily dominate power.

I like that in theory, it provides "zero latency" (quotes theirs).  In
practice, for speech-dispatcher, it's good enough.  I'll take a closer
look next time someone complains about an old game with too much
latency.

As for concerns about running system-wide... Ubuntu already disallows
user loaded modules, and I'm not hearing a lot of complaints.  When
running in system-wide mode, pretty much everyone seems happy.  The
complaints I'm hearing are the usual ones... how do I get my second
USB sound card working and such.  However, when run in user-mode, I
hear all sorts of bug complaints.  For example, speech-dispatcher
doesn't reliably go away when you log out fast enough for gdm's copy
to get access to the sound card.  The result is that today, in Ubuntu
Lucid, if you log out, gdm randomly wont let gdm's copy of Orca read
the login screen.  Users offer work-arounds like putting 'killall
speech-dispatcher' in .bash_logout.

If security issues were handled by a system-wide daemon, I suspect PA
could run more reliably.   In addition, a system-wide rights manager
could easily handle sound from root devices like speech-synthesizers,
or alarms.  A flaw that people will continue to complain about in PA
is it's inability to deal with multi-user sound.

Bill

On Wed, Feb 10, 2010 at 6:32 AM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
> '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/]
>
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>