On Thursday, March 28, 2013 11:51:11 PM Helmar Sch?tz wrote: > On 25.03.2013 17:30, Tanu Kaskinen wrote: > > On Mon, 2013-03-25 at 16:46 +0100, Helmar Sch?tz wrote: > >> Followed by a bunch of these: > >> > >> I: [alsa-sink] alsa-sink.c: Scheduling delay of 1.09ms, you might want > >> to investigate this to improve latency... > >> > >> And finally: > >> > >> Killed > >> > >> > >> It takes some time to actually crash which makes reproducing it > >> time-consuming. Is there a way that I can instantly test whether it's > >> the realtime thread problem you were talking about? > > > > Put "realtime-scheduling = no" in ~/.config/pulse/daemon.conf. > > > > It looks like you are running pulseaudio with one -v argument. Try > > giving it twice to get even more verbose logging. > > Turning off realtime-scheduling seems to have done the trick. You said > this issue was already fixed in pulseaudio 3. I rechecked my pulseaudio > --version and I do have 3.0 installed. Does this mean the bug still > exists in 3.0 or is it just my wheezy rt-kernel version that is actually > buggy? I said that the module-combine-sink bug, which had the same symptoms, was fixed in 3.0. Since this doesn't appear to be related to module-combine-sink, this is a different bug, and obviously is still in PulseAudio 3.0. > Anyways I made three -vvvv logs and if you should be interested > in looking through those, I'd be glad to upload them. I wouldn't mind having a glance at a log with maximum verbosity, with realtime-scheduling enabled. > Is there any downside to having realtime-scheduling turned off? You may get more underruns (audio drop-outs). Getting killed due to excessive CPU use suggests that PulseAudio enters a busy-loop. Another possibility is that PulseAudio does some heavy processing, but that shouldn't be the case with the default configuration. Have you loaded some filter modules in PulseAudio? If you disable realtime-scheduling, does pulseaudio consume a lot of CPU time? I guess you don't have rtkit installed. rtkit should be able to dynamically remove the realtime scheduling from PulseAudio in case PulseAudio doesn't behave nicely, before PulseAudio gets killed. Of course, if there's a busy- loop involved, there would still be excessive CPU load... -- Tanu
