Bug 71204

Summary:	ALSA playback hangs when period size is greater than 30ms and tsched=1
Product:	PulseAudio	Reporter:	Maarten Baert <maarten-baert>
Component:	alsa	Assignee:	pulseaudio-bugs
Status:	RESOLVED MOVED	QA Contact:	pulseaudio-bugs
Severity:	normal
Priority:	medium	CC:	lennart
Version:	unspecified
Hardware:	x86-64 (AMD64)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:

Description Maarten Baert 2013-11-04 02:37:34 UTC

I use Arch Linux 64-bit. Since a few weeks ago, the Flash plugin has become unusable because audio playback is extremely buggy: the sound is always choppy and occasionally Flash hangs completely. This was strange because there hasn't been a Flash update. Now I noticed that not just Flash is affected, but all applications that play sound through ALSA - even 'aplay'. I *think* this happened when PulseAudio was upgraded from the stable 4.0 release to git commit 35fea57. The bug is still there in commit 09e88de.

The problems gradually get worse as the period size is increased, and if the period size goes just a single sample above 30ms, the application locks up immediately. Examples:

aplay --period-size=500 --buffer-size=10000 in.wav # OK
aplay --period-size=1323 --buffer-size=10000 in.wav # choppy, occasional lockup
aplay --period-size=1324 --buffer-size=10000 in.wav # instant lockup

This is a 44100Hz file. If I do the same test with a 48000Hz file, the threshold is 1440-1441 samples.

The buffer size doesn't make the issues disappear, but it makes them less frequent.

When the audio is choppy, the application prints these messages:
underrun!!! (at least 266.301 ms long)
underrun!!! (at least 266.266 ms long)
underrun!!! (at least 264.251 ms long)
The time printed roughly corresponds to the delay between the messages. This in turn depends on the buffer size - larger buffer sizes result in larger values.

When the application locks up, it is waiting for poll() inside libasound.so (I don't have debug symbols, sorry).

If I add tsched=0 to the PulseAudio config file, the issues are gone.

The systemd log contains these messages a few times (the first one is from August 4, long before the update that broke it):
Nov 04 01:10:58 laptop-maarten pulseaudio[15762]: [alsa-sink-92HD73C1X5 Analog] alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write!
Nov 04 01:10:58 laptop-maarten pulseaudio[15762]: [alsa-sink-92HD73C1X5 Analog] alsa-sink.c: Most likely this is a bug in the ALSA driver 'snd_hda_intel'. Please report this issue to the ALSA developers.
Nov 04 01:10:58 laptop-maarten pulseaudio[15762]: [alsa-sink-92HD73C1X5 Analog] alsa-sink.c: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail.

I tried running 'alsa-time-test' for about 10 minutes with PulseAudio suspended, but it didn't hit any asserts.

The ALSA driver is snd_hda_intel.
/proc/asound/pcm: 00-00: 92HD73C1X5 Analog : 92HD73C1X5 Analog : playback 1 : capture 1
lspci: 00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series Chipset High Definition Audio (rev 06)

Comment 1 Maarten Baert 2013-11-05 00:15:42 UTC

I ran git bisect, the problem appeared with this commit:
http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/src/pulse?id=5f326b705d8f7f0c14e7e0c7d7c2751f3a5ebe43
After more testing I discovered that the problem was already there long before that commit (even in PulseAudio 3.0), but the threshold used to be 60ms instead of 30ms, so I never noticed it.

If there's anything else I can do to help track this down, please tell me.

Comment 2 Tanu Kaskinen 2013-11-08 12:13:44 UTC

Marking as a release blocker for now. Let's investigate if this is really a PulseAudio bug, or is ALSA at fault.

Comment 3 David Henningsson 2013-11-15 13:00:37 UTC

Hi,

There was a patch related to buffering and the Flash plugin over here:

https://bugs.freedesktop.org/show_bug.cgi?id=66962

Would you mind testing it and see if it helps you?

Thanks!

Comment 4 Maarten Baert 2013-11-16 21:39:21 UTC

I tried the patch. For Flash, it is an improvement but still far from perfect. There are still interruptions every 10 seconds or so, and after a while Flash hangs. For aplay it made no difference.

Comment 5 Tanu Kaskinen 2013-11-29 12:42:34 UTC

One data point: poljar in IRC reported that he tried to reproduce this, also on Arch 64-bit, but couldn't reproduce.

Comment 6 Tanu Kaskinen 2013-12-04 08:30:04 UTC

I finally tried this myself too. I couldn't reproduce. Since it seems that most people can't get aplay to lock up even if they try, I'm removing the release blocker status from this bug. That also means that the priority of this bug is not very high for me personally any more. Hopefully someone else will have time to investigate, but I wouldn't hold my breath...

Comment 7 GitLab Migration User 2018-07-30 10:35:07 UTC

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/518.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.