[Lenovo Miix 310, Ubuntu 18.04] Audio no longer working

[Keith Gaughan]

I believe this is a pulseaudio regression, as the output of alsa-info (http://www.alsa-project.org/db/?f=730ab5b8f0499ef58c0e17f67f8f911ba53a011c) looks fine as far as I can see.

I'm currently running Ubuntu 18.04, and I believe this is a regression as audio used to work under 17.10. Since upgrading (which fixed a good number of other incompatibilities with the machine), I've had no luck getting audio to work at all.

I'm attaching the output of dmesg, 'aplay -l', 'aplay -L' and 'pulseaudio -vv'.

If I can provide any other information, or if there's anything you'd like me to try, I'd be happy to help in any way possible.

[Daniel van Vugt (vanvugt)]

Thanks for the bug report. This part of your logs looks most suspicious:

Pulseaudio:
      Installed - Yes (/usr/bin/pulseaudio)
      Running - No

Can you please take a screenshot (Alt+PrtSc) or a photo of your Settings > Sound dialog and attach it here?

Please also open a terminal and run:
  ps auxw | grep pulse
and send us the text output (or a screenshot) of that too.

[Keith Gaughan (kmgaughan)]

Yup, pulseaudio doesn't start at all. When I run it with 'pulseaudio -vv' to get the debug output, it ends with a SIGKILL. There's no daemon running.

Here's a bug that I believe might be connected, and I commented on it before: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1759942

[Daniel van Vugt (vanvugt)]

Please also verify that you see no devices, or just the dummy device in:
  Settings > Sound

If pulseaudio is indeed crashing for you then that's what we need to debug. Please:

1. Apply the workaround from bug 994921.

2. Look in /var/crash for crash files and if found run:
     ubuntu-bug YOURFILE.crash
   and tell us the ID of the newly-created bug.

3. If step 2 failed then look at https://errors.ubuntu.com/user/ID where ID is the contents of the /var/lib/whoopsie/whoopsie-id file on the machine. Do you find any links to recent problems on the machine? If so then please send them to us.

[Keith Gaughan (kmgaughan)]

I don't believe that'll work because pulseaudio is getting a SIGKILL, not a SIGABRT, &c., so apport will never receive a coredump anyway.

I did a bit more research and came across <https://bugs.freedesktop.org/show_bug.cgi?id=100488>. I updated /etc/pulse/daemon.conf, adding 'realtime-scheduling = no', and the daemon was able to run. I think the issue I've been having is related to that bug. However, the odd thing is that I recall under 17.10 being able to plug a HDMI cable in and out without causing PA to die, so I'm not 100% sure it's exactly that issue. Regardless, I've marked <https://bugs.launchpad.net/bugs/1773167> as affecting me.

[Daniel van Vugt (vanvugt)]

You're right; a SIGKILL will not leave any trace. However you also mentioned that happened when you ran it manually so I'm wondering if maybe a different crash is occurring when the daemon is started formally by the system. Hoping anyway.

We need to continue on the assumption that this is a debuggable crash and not caused by SIGKILL. So please complete the steps in comment #4.

If you can then find no further information then unfortunately you're left to figure out what is killing the pulseaudio process. My first guess would be maybe the kernel OOM killer, if the system is low on memory.

[Keith Gaughan (kmgaughan)]

I can get other processes to produce core dumps, but pulseaudio is not producing any.

Given PA stops dying when I add 'realtime-scheduling = no' to /etc/pulse/daemon.conf, this makes me think that the process is hitting either RLIMIT_RTTIME or RLIMIT_CPU, which would cause the kernel to send SIGKILL to the process when PA is scheduled (as it normally is) as a realtime process.

While this is a relatively small machine, I would expect the OOM killer to be a factor regardless of the value assigned to realtime-scheduling, but it _only_ dies when PA is started as a realtime process.

I did some more experiments. For whatever reason, indicator-sound wasn't installed (and there's no reason I would've removed it, so it's a mystery as to why it wasn't installed). Once I installed that, with 'realtime-scheduling = yes', PA would repeatedly die, but eventually start. With 'realtime-scheduling = no', it would start immediately. Without indicator-sound installed, PA would start if 'realtime-scheduling = no', but fail to start if 'realtime-scheduling = yes'.

I'm attaching the contents of /var/log/syslog in the hope that it's useful, at least to show the behaviour I'm seeing.

[Keith Gaughan (kmgaughan)]

I'm also attaching the contents of /var/log/syslog for a desktop session with 'log-level = debug' in PA's daemon.conf file, if it helps.

[Daniel van Vugt (vanvugt)]

Great insight there about RLIMIT_RTTIME.

It appears that yes indeed pulseaudio is unique in that it has a self-imposed RLIMIT_RTTIME of 200000 microseconds. That is also configured in /etc/pulse/daemon.conf:

; rlimit-rttime = 200000

Normal processes have no such limit.

It appears you should sometimes get error messages in the pulseaudio log somewhere along the lines of:

  Soft CPU time limit exhausted, terminating.
  Hard CPU time limit exhausted, terminating forcibly.

but certainly if the hard limit is exceeded quickly then you might see neither of those.

Next...

1. Please send more system information by running:
     apport-collect 1783200
   or by at least sending us the CPU model details, kernel version, and output from `lspci -k`.

2. Report a bug to PulseAudio here:
     https://bugs.freedesktop.org/enter_bug.cgi?product=PulseAudio
   and tell us the new bug ID.

[Daniel van Vugt (vanvugt)]

That last link has moved. It's now: https://gitlab.freedesktop.org/groups/pulseaudio/-/issues

[Launchpad Janitor (janitor)]

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