pulseaudio suddenly stops. No dmesg entries. Nothing in the syslog

[john nunnington]

this only happens when sound is through the PCI sound card. When i connect speakers to the motherboard output (I lose the 5.1 component), pulseaudio never dies.

I have switched and replaced the sound card to no effect but I never really thought that was the issue.

There seems to be no evidence of the failure unless I run it from the command line with -vvvv, when eventually I see a 'killed' message.

The pulseaudio log collects initial messages, but nothing else is echoed to the log - which could be anything from 3-20 minutes [typically].

I'm more than happy to assist in getting whatever logs are required, but nothing I've seen documented seems to help.
---
ApportVersion: 2.20.3-0ubuntu8.2
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC3: julie 30342 F.... pulseaudio
 /dev/snd/controlC1: julie 30342 F.... pulseaudio
 /dev/snd/controlC2: julie 30342 F.... pulseaudio
 /dev/snd/controlC0: julie 30342 F.... pulseaudio
DistroRelease: Ubuntu 16.10
InstallationDate: Installed on 2015-05-19 (670 days ago)
InstallationMedia: Ubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422)
Package: pulseaudio 1:9.0-2ubuntu2.1
PackageArchitecture: amd64
ProcEnviron:
 LANGUAGE=en_NZ:en
 TERM=xterm-256color
 PATH=(custom, no user)
 LANG=en_NZ.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 4.2.0-30.36-generic 4.2.8-ckt3
PulseList:
 Error: command ['pacmd', 'list'] failed with exit code 1: Home directory not accessible: Permission denied
 No PulseAudio daemon running, or not running as session daemon.
Tags: yakkety
Uname: Linux 4.2.0-30-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups:

_MarkForUpload: True
dmi.bios.date: 11/25/2014
dmi.bios.vendor: Award Software International, Inc.
dmi.bios.version: F2
dmi.board.name: GA-78LMT-USB3 6.0
dmi.board.vendor: Gigabyte Technology Co., Ltd.
dmi.board.version: x.x
dmi.chassis.type: 3
dmi.chassis.vendor: Gigabyte Technology Co., Ltd.
dmi.modalias: dmi:bvnAwardSoftwareInternational,Inc.:bvrF2:bd11/25/2014:svnGigabyteTechnologyCo.,Ltd.:pnGA-78LMT-USB36.0:pvr:rvnGigabyteTechnologyCo.,Ltd.:rnGA-78LMT-USB36.0:rvrx.x:cvnGigabyteTechnologyCo.,Ltd.:ct3:cvr:
dmi.product.name: GA-78LMT-USB3 6.0
dmi.sys.vendor: Gigabyte Technology Co., Ltd.
modified.conffile..etc.pulse.daemon.conf: [modified]
modified.conffile..etc.pulse.default.pa: [modified]
mtime.conffile..etc.pulse.daemon.conf: 2017-03-18T20:58:01.387562
mtime.conffile..etc.pulse.default.pa: 2015-12-20T08:49:47.368322

[john nunnington (jnunnington)]

sound devices disappear from output options. If I'm listening through Spotify, Spotify won't play until that has been restarted (from memory so do RhythmBox and Banshee)

[john nunnington (jnunnington)]

kern.log entries at time of failure:

Mar 19 11:50:01 silverstone unity-settings-[3397]: Unable to get default sink
Mar 19 11:50:01 silverstone unity-settings-[3397]: Unable to get default source
Mar 19 11:50:01 silverstone unity-settings-[3397]: Failed to connect context: Connection refused

[Luke Yelavich (themuso)]

Please run apport-collect 1673942 in a terminal so we can get some more information about your hardware.

[Luke Yelavich (themuso)]

Could you also get a log from PulseAudio as per https://wiki.ubuntu.com/PulseAudio/Log. Thanks.

[john nunnington (jnunnington)]

apport information

[john nunnington (jnunnington)]

apport information

[john nunnington (jnunnington)]

apport information

[john nunnington (jnunnington)]

apport information

[john nunnington (jnunnington)]

pulseaudio log from session that died.

[john nunnington (jnunnington)]

output from 'pacmd list'.

I wasn't looking closely at this, but it looked like the PA daemon fell over while trying to execute the pacmd verb.

I'm plugged into the motherboard sound output, and typically it is "stable" from there.

[john nunnington (jnunnington)]

installed 16.04-02 onto an SSD this morning and Spotify/Pulseaudio has been running for 2-3 hours with only a single hiccup where Spotify just stopped - but pulseaudio daemon was still running and restarting Spotify solved the lack of music.

[john nunnington (jnunnington)]

comparing pulseaudio configuration, some rtp modules were uncommented in the failing environment so these were commented back out; result, pulseaudio ran for about 26 minutes before failing. Daemon restarted (as configured) and sound settings retained the selected output device...but spotify is unable to restart or play.

...just failed after 3-4 minutes

[john nunnington (jnunnington)]

i think i have narrowed this down to a faulty RAM (in excess of 30K errors). I will replace this shortly and retest but that would explain why a new build and my other desktop with a similar build are unaffected, and why the error conditions are somewhat erratic.

Does it explain why the fault disappears when the speakers are plugged into the motherboard sound output versus the sound card though?

[john nunnington (jnunnington)]

Nope. Running without the faulty RAM (4GB as opposed to 12GB) and RhythmBox runs continuously (hours) while Spotify halts and cannot resume when pulseaudio terminates and restarts.

Syslog demonstrates pulseaudio death and auto respawn
Mar 25 10:05:25 silverstone pulseaudio[6061]: [pulseaudio] main.c: User-configured server at {b383fd3bcf07437a8a80e84b7264bc1c}unix:/run/user/1006/pulse/native, which appears to be local. Probing deeper.
Mar 25 10:05:25 silverstone pulseaudio[6064]: [pulseaudio] pid.c: Stale PID file, overwriting.
Mar 25 11:08:32 silverstone pulseaudio[7663]: [pulseaudio] main.c: User-configured server at {b383fd3bcf07437a8a80e84b7264bc1c}unix:/run/user/1006/pulse/native, which appears to be local. Probing deeper.
Mar 25 11:08:32 silverstone pulseaudio[7666]: [pulseaudio] pid.c: Stale PID file, overwriting.
Mar 25 11:23:05 silverstone pulseaudio[8055]: [pulseaudio] main.c: User-configured server at {b383fd3bcf07437a8a80e84b7264bc1c}unix:/run/user/1006/pulse/native, which appears to be local. Probing deeper.
Mar 25 11:23:05 silverstone pulseaudio[8058]: [pulseaudio] pid.c: Stale PID file, overwriting.
Mar 25 12:14:47 silverstone pulseaudio[9362]: [pulseaudio] main.c: User-configured server at {b383fd3bcf07437a8a80e84b7264bc1c}unix:/run/user/1006/pulse/native, which appears to be local. Probing deeper.
Mar 25 12:14:47 silverstone pulseaudio[9365]: [pulseaudio] pid.c: Stale PID file, overwriting.
Mar 25 12:16:57 silverstone pulseaudio[9447]: [pulseaudio] main.c: User-configured server at {b383fd3bcf07437a8a80e84b7264bc1c}unix:/run/user/1006/pulse/native, which appears to be local. Probing deeper.
Mar 25 12:16:57 silverstone pulseaudio[9450]: [pulseaudio] pid.c: Stale PID file, overwriting.
Mar 25 13:00:12 silverstone pulseaudio[10629]: [pulseaudio] main.c: User-configured server at {b383fd3bcf07437a8a80e84b7264bc1c}unix:/run/user/1006/pulse/native, which appears to be local. Probing deeper.
Mar 25 13:00:12 silverstone pulseaudio[10632]: [pulseaudio] pid.c: Stale PID file, overwriting.
Mar 25 13:10:48 silverstone pulseaudio[10902]: [pulseaudio] main.c: User-configured server at {b383fd3bcf07437a8a80e84b7264bc1c}unix:/run/user/1006/pulse/native, which appears to be local. Probing deeper.
Mar 25 13:10:48 silverstone pulseaudio[10905]: [pulseaudio] pid.c: Stale PID file, overwriting.
Mar 25 13:15:16 silverstone pulseaudio[11123]: [pulseaudio] main.c: User-configured server at {b383fd3bcf07437a8a80e84b7264bc1c}unix:/run/user/1006/pulse/native, which appears to be local. Probing deeper.
Mar 25 13:15:16 silverstone pulseaudio[11126]: [pulseaudio] pid.c: Stale PID file, overwriting.

[john nunnington (jnunnington)]

no problems for several days while outputting through analog-stereo.

Am i just wasting my time to think that somebody might actually look at this? Other people have reported what look like similar conditions, that never seem to meet a resolution.

If there are some detailed instructions about generating some detailed logs, I can do that if it will help resolve this

[john nunnington (jnunnington)]

SOLVED - after a couple of hints with Tanu Kaskinen, this is solved with the following entry in /etc/pulse/default.pa

.ifexists module-udev-detect.so
load-module module-udev-detect tsched_buffer_size=16384

The suggested cause is that the kernel doesn't allow sufficient time to process the default 50000 bytes.

The pulseaudio daemon process has been running without error (in 5.1 configuration) for over 5.5 hours.

Is this a hardware issue? Or a kernel parameter issue? or a combination of the two?

[Daniel van Vugt (vanvugt)]

Thank you for reporting this bug to Ubuntu.
Ubuntu 16.10 (yakkety) reached end-of-life on July 20, 2017.

See this document for currently supported Ubuntu releases:
https://wiki.ubuntu.com/Releases

We appreciate that this bug may be old and you might not be interested in discussing it any more. But if you are then please upgrade to the latest Ubuntu version and re-test.

[Launchpad Janitor (janitor)]

[Expired for pulseaudio (Ubuntu) because there has been no activity for 60 days.]