[pulseaudio-discuss] Pulseaudio randomly resets

[Tanu Kaskinen]

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.

-- 
Tanu