[pulseaudio-discuss] [PATCH] System-wide on recent kernels

[Sean McNamara]

0.9.11 (which I'm assuming contains this change) works for me in
system mode, for a very loose definition of "works". I can create and
run streams and they play... eventually. The 2-second dropout at the
start of the stream is still a mystery to me. tsched=0 reduces this
from ~2 seconds to the duration of 1 fragment as declared in
daemon.conf. But it's still a pop at the start of each stream.

With system mode disabled and tsched=0, I get zero dropouts on all but
the most incompatible PA clients. But the need for tsched=0 is
probably no surprise to you, since my card is based on Intel HDA.

Since many of the HDA problems are bugs in ALSA, could you do a list
announce once you are reasonably confident that patches have been
applied to ALSA which allow us HDA'ers to turn on time-based
scheduling? Filtering the alsa-devel commits for relevant patches
takes hours, but I'm assuming any requisite fixes for this would
probably be initiated by you... :)

I am using a post-1.0.17 git version of
alsa-(lib|plugins|driver|utils) by the way. It has the patches you
asked Takashi to apply for _rewind() etc... so I'm guessing there are
*more* issues with HDA :(

Anyway. Sorry to hijack the system-mode thread into an HDA thread. Two
completely separate discussions there. :)

Sean

On Tue, Jul 22, 2008 at 12:24 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Tue, 22.07.08 05:12, Sean McNamara (smcnam at gmail.com) wrote:
>
>> Hello,
>>
>> I am running latest pulseaudio from git master as of this morning, and
>> had some problems with system-wide mode (running as pulse user). I
>> suspect this is due to my recent kernel, but it could also be the way
>> Ubuntu is configured.
>
> Hmm, no. It's not Ubuntu's fault, nor the kernel's. It's my fault. I
> rewrote the privilige dropping logic, so that PA supports file
> capabalities instead full suid root. And while doing that I apparently
> broke system mode.
>
> I tried to fix this now in current git. Could you please check if this
> works for you?
>
>> The observed behavior (thanks, strace!) is that the library functions
>> setgroups, setresgid, etc. all fail in main.c... this is because we
>> call pa_drop_caps() fairly early on (after setting RT_PRIO) which
>> removes our CAP_SETGID and CAP_SETUID capabilities. On my system, at
>> least, without these capabilities, the above-mentioned syscalls fail,
>> resulting in numerous errors on startup. I'm using Ubuntu Intrepid
>> Alpha2, which is a 2.6.26 kernel.
>
> Yepp, PA retries to replace CAP_SYS_NICE with a higher RLIMIT_RTPRIO
> right now. But that logic should only be there for normal users, not
> for system mode or when started for the root user.
>
> Because system mode is ... uh .. system mode I think it would be a bad
> idea to keep any higher priviliges. That's why in this case PA should
> no try to limit capabilities but instead just wait until the
> setresuid() call takes them all away anyway.
>
>> Startup time does not seem negatively affected (on a desktop, what's a
>> few syscalls? ;)) by the additional transition. Since this all seems
>> very Linux-specific, I was careful to make this entire patch invisible
>> to people who don't run Linux or whose userspace Linux headers don't
>> have the capabilities interface. This definitely deserves testing on
>> older kernels, but I don't have any available at the moment. On my
>> system, though, this patch does not generate any further bad-looking
>> warnings/infos from PA... it seems to work well now.
>
> TBH portability is not really a necessary feature for a patch you
> submit. The system I focus on is Linux. I won't make it explicitly
> difficult for porters to other operating systems, but the portability
> patches have to come from them. So, if a patch breaks Solaris support
> but is otherwise good I will merge it. OTOH if a patch breaks Linux
> support I won't.
>
>> Also, there was a slight problem which I'm just going to complain
>> about but not patch ;) It may have been related to this, not sure...
>> my first roadblock was it was trying to mkdir /var/lib/pulse and set
>> its permissions to 0700. I was making the directory as root and
>> chown-ing it to pulse:pulse, but PA got angry and unlinked it each
>> time, until I figured out (from strace) that it wants it 0700 or it
>> will delete it. ;-)
>
> hmmm, pa shouldn't unlink that directory if it didn't create it in the
> first place i guess. Could you file a bug about this, so i don't
> forget this?
>
> Thank you for the patches!
>
> Lennart
>
> --
> Lennart Poettering                        Red Hat, Inc.
> lennart [at] poettering [dot] net         ICQ# 11060553
> http://0pointer.net/lennart/           GnuPG 0x1A015CC4
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>