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

          Priority: medium
            Bug ID: 71204
                CC: lenn...@poettering.net
          Assignee: pulseaudio-bugs@lists.freedesktop.org
           Summary: ALSA playback hangs when period size is greater than
                    30ms and tsched=1
        QA Contact: pulseaudio-bugs@lists.freedesktop.org
          Severity: normal
    Classification: Unclassified
                OS: Linux (All)
          Reporter: maarten-ba...@hotmail.com
          Hardware: x86-64 (AMD64)
            Status: NEW
           Version: unspecified
         Component: alsa
           Product: PulseAudio

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)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
_______________________________________________
pulseaudio-bugs mailing list
pulseaudio-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-bugs

Reply via email to