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
