[pulseaudio-discuss] Pulseaudio randomly resets

[Helmar Schütz]

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!