[pulseaudio-discuss] Uber-early glitch-free Testing Results

[Sean McNamara]

Hi, not sure if I already sent this out (if I did, it was incomplete
and poorly-behaved mail clients are to blame), but...

On Wed, Apr 16, 2008 at 3:29 PM, Steve Greenland <steveg at moregruel.net> wrote:
> On 16-Apr-08, 14:04 (CDT), Lennart Poettering <lennart at poettering.net> wrote:
>  >
>  > System instance is not a good idea since it disables SHM data
>  > transfer. I recommend against using it unless you really know what you
>  > do.
>
>  Okay, it's pretty clear you don't like system mode. But what is
>  the "right thing" for PA running on a non-desktop box like a music
>  server/player, with no real users? And yes, I want PA on that box,
>  because it's *also* the output from my desktop...
>
>  Steve
>
>  --
>  Steve Greenland
>     The irony is that Bill Gates claims to be making a stable operating
>     system and Linus Torvalds claims to be trying to take over the
>     world.       -- seen on the net
>
>
> _______________________________________________
>  pulseaudio-discuss mailing list
>  pulseaudio-discuss at mail.0pointer.de
>  https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>

Again we have an ugly contention. In Lennart's blog he made the
following very salient argument that we have a configuration problem
with buffer sizes and fragment sizes:

"It is difficult to choose the buffer and fragment sizes in an optimal
way for an application:

    * The buffer size should be as large as possible to minimize the
risk of drop-outs.
    * The buffer size should be as small as possible to guarantee
minimal latencies.
    * The fragment size should be as large as possible to minimize the
number of interrupts, and thus the required CPU time used, to maximize
the time the CPU can sleep for between interrupts and thus the battery
lifetime (i.e. the fewer interrupts are generated the lower your audio
app will show up in powertop, and that's what all is about, right?)
    * The fragment size should be as small as possible to give the
application as much time as possible to fill up the playback buffer,
to minimize drop-outs." --Lennart

I'd like to make an analogy with this on the user problem, using the
same format:

It is difficult to choose which user to run PA under in an optimal way
for an application:

    * PA should not run as root because this exposes the daemon to the
most security risks, and facilitates privilege escalation as a
consequence of otherwise minor software defects.
    * PA should run as root because this gives the daemon the most
privileges of any other user, including real-time scheduling,
high-priority, and SHM. It works without PolicyKit installed, without
modifying /etc/security/limits.conf, without creating a new user, and
without needing a logged-in session.
    * PA should run with --system when there is no logged in user,
when you want the concept of the daemon running detached from any
particular user, and when you want the benefits of not running with
the security risks of running as root.
    * PA should not run with --system (as 'pulse' user) because you
can't use SHM transfer, you have to tweak PolicyKit to allow real-time
scheduling to the 'pulse' user, and because you have to add all
desired users (of the -unix protocols) to the 'pulse-access' group.
    * PA should run as a normal user when a user is logged in and
available, when that user has been configured to have access to
realtime scheduling, and when that user is the only one on the system
who will be using PA.
    * PA should not run as a normal user when you have a multi-user
environment on the same system, or when any given user can log out
completely at any time and you still want to make sound available to
all the other users, or when you have PA clients coming in through tcp
who want access when the user logs off. Test it: start pa with
--daemonize=true and as a regular user, then log off the session.
Poof, PA gone.

So it seems the 'pulse' user needs to be *made* to be able to use shm
;-) Is there any way to feasibly do that?

Thanks,

-Sean