On 25.03.2013 17:30, Tanu Kaskinen wrote: > On Mon, 2013-03-25 at 16:46 +0100, Helmar Sch?tz wrote: >> On 25.03.2013 09:30, Tanu Kaskinen wrote: >> >>> On Thu, 2013-03-21 at 15:00 +0100, Helmar Sch??tz wrote: >>>> Hi, >>>> >>>> my Pulseaudio randomly resets when I play music in wine emulated >>>> foobar2000 or in Linux VLC player. I see the icon disappear for a bit >>>> and audio completely stops until I restart said applications. I tried >>>> running pulseaudio verbosely from command line but other than a "kill" >>>> when it happened, there didn't seem to be anything out of the ordinary. >>> What do you mean by "a kill"? Is there a line saying "Killed"? If that's >>> the case, then the problem is probably that PulseAudio is consuming more >>> CPU time in its realtime threads than it's allowed to, hence it gets >>> killed. >> Yeah, that line appeared in the terminal. >>> Do you possibly use module-combine-sink? It had a bug that could cause >>> the CPU limit to be exceeded. It's fixed in 3.0, which is not available >>> in Wheezy. >>> >> I downloaded pulseaudio 3 from debian experimental. The problem still >> persists and it appears in every kind of audio application. It seems >> to me that OOM is wine-related, so I guess it is not related to my >> problem. >> >> I'm not sure how to figure out whether I'm using module-combine-sink. >> I can't find it in /etc/pulse/default.pa . I use a Lenovo T61 Thinkpad >> that only has an analogue audio output so my guess is using >> module-combine-sink wouldn't even make much sense? > "pactl list modules short" will show all loaded modules. But if this is > reproducible with 3.0, it's not the bug that I suspected. > >> This is what I got last time it crashed with pulseaudio 3 installed: >> >> I: [pulseaudio] sink-input.c: Freeing input 8 "ALSA Playback" >> I: [pulseaudio] module-stream-restore.c: Restoring device for stream >> sink-input-by-application-name:ALSA plug-in [wine-preloader]. >> I: [pulseaudio] module-stream-restore.c: Restoring volume for sink >> input sink-input-by-application-name:ALSA plug-in [wine-preloader]. >> I: [pulseaudio] module-stream-restore.c: Restoring mute state for sink >> input sink-input-by-application-name:ALSA plug-in [wine-preloader]. >> I: [pulseaudio] sink-input.c: Created input 9 "ALSA Playback" on >> alsa_output.pci-0000_00_1b.0.analog-stereo with sample spec s16le 2ch >> 44100Hz and channel map front-left,front-right >> I: [pulseaudio] sink-input.c: media.name = "ALSA Playback" >> I: [pulseaudio] sink-input.c: application.name = "ALSA plug-in >> [wine-preloader]" >> I: [pulseaudio] sink-input.c: native-protocol.peer = "UNIX socket >> client" >> I: [pulseaudio] sink-input.c: native-protocol.version = "27" >> I: [pulseaudio] sink-input.c: application.process.id = "8037" >> I: [pulseaudio] sink-input.c: application.process.user = "helmar" >> I: [pulseaudio] sink-input.c: application.process.host = >> "wheezynut" >> I: [pulseaudio] sink-input.c: application.process.binary = >> "wine-preloader" >> I: [pulseaudio] sink-input.c: application.language = "en_US.utf8" >> I: [pulseaudio] sink-input.c: window.x11.display = ":0.0" >> I: [pulseaudio] sink-input.c: application.process.machine_id = >> "3ea01861093a01db55367d2d50857e5c" >> I: [pulseaudio] sink-input.c: module-stream-restore.id = >> "sink-input-by-application-name:ALSA plug-in [wine-preloader]" >> I: [pulseaudio] protocol-native.c: Requested tlength=40.00 ms, >> minreq=10.00 ms >> I: [pulseaudio] protocol-native.c: Final latency 50.00 ms = 20.00 ms + >> 2*10.00 ms + 10.00 ms >> >> 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? Anyways I made three -vvvv logs and if you should be interested in looking through those, I'd be glad to upload them. Is there any downside to having realtime-scheduling turned off? Thank you so much for the help you have been providing so far!
