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 >
