skype has lag after 0.9.21+stable-queue-24-gfa64

Bug #511558 reported by Tormod Volden on 2010-01-23
14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
pulseaudio (Fedora)
Fix Released
Medium
pulseaudio (Ubuntu)
Medium
Daniel T Chen

Bug Description

Binary package hint: pulseaudio

I believe it was always fine with 1:0.9.21-0ubuntu6, but after upgrading to 0.9.22~0.9.21+stable-queue-24-gfa64-0ubuntu1 I get a a few seconds input lag in Skype.

1:0.9.21-0ubuntu6 GOOD
1:0.9.22~0.9.21+341-g62bf-0ubuntu1 GOOD
0.9.22~0.9.21+stable-queue-24-gfa64-0ubuntu1 BAD
0.9.22~0.9.21+stable-queue-32-g8478-0ubuntu1 BAD

The above tests was done without rebooting, so if pulseaudio does not restart cleanly when upgrading packages, the above result might be skewed. It can also appear intermittently on the second version at least: Once it was bad on the second call, but good on first, 3rd-4th-5th, another time bad on the first, but good on 2nd-3rd-4th, then after leaving it for some minutes, it was bad on the first call again, but good in the next.

The tests were done with skype 2.1.0.81 (from upstream skype-ubuntu-intrepid_2.1.0.81-1_i386.deb) but it was the same pattern with 2.1.0.47.

TEST CASE:
Call echo123 "Skype Testing Service" and open the DTMF pad and push some buttons.
Expected: The tone is heard as soon as the button is pressed
Happening: The tone is heard after several seconds of delay

(The lag is of course very noticeable in a normal conversation, but the DTMF pad is an easy way to test)

Possibly related upstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=554929

ProblemType: Bug
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.21.
Architecture: i386
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: tormod 1573 F.... pulseaudio
 /dev/snd/controlC1: tormod 1573 F.... pulseaudio
Card0.Amixer.info:
 Card hw:0 'Intel'/'HDA Intel at 0xc8000000 irq 16'
   Mixer name : 'Realtek ALC880'
   Components : 'HDA:10ec0880,08800000,00090500 HDA:11c13026,11c13026,00100600'
   Controls : 39
   Simple ctrls : 23
Card1.Amixer.info:
 Card hw:1 'U0x46d0x9a2'/'USB Device 0x46d:0x9a2 at usb-0000:00:1d.7-7, high speed'
   Mixer name : 'USB Mixer'
   Components : 'USB046d:09a2'
   Controls : 2
   Simple ctrls : 1
Card1.Amixer.values:
 Simple mixer control 'Mic',0
   Capabilities: cvolume cvolume-joined cswitch cswitch-joined penum
   Capture channels: Mono
   Limits: Capture 0 - 3072
   Mono: Capture 0 [0%] [18.00dB] [on]
Date: Sat Jan 23 13:56:51 2010
DistroRelease: Ubuntu 10.04
Package: pulseaudio 1:0.9.22~0.9.21+341-g62bf-0ubuntu1
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.32-11.15-generic
SourcePackage: pulseaudio
Uname: Linux 2.6.32-11-generic i686

Tormod Volden (tormodvolden) wrote :
description: updated
description: updated
description: updated
description: updated
Tormod Volden (tormodvolden) wrote :

I now see pulseaudio is not restarted when I reinstall packages, so the above results are probably wrong, arghh.

$ ps uax|grep pulse
tormod 1573 1.4 0.8 102476 8464 ? S<sl 12:57 1:16 /usr/bin/pulseaudio --start --log-target=syslog
tormod 1609 0.0 0.2 10668 2960 ? S 12:57 0:00 /usr/lib/pulseaudio/pulse/gconf-helper
tormod 4956 0.0 0.0 3104 808 pts/1 S+ 14:28 0:00 grep pulse

Tormod Volden (tormodvolden) wrote :

OK, after rebooting with 0.9.22~0.9.21+stable-queue-32-g8478-0ubuntu1, the situation is this:
A first call is always lagged, consecutive calls within ca 10 seconds from finishing the previous is good. So if I wait a bit before taking the next call, it will always be lagged.

Which Skype beta is this? Please use dpkg -l skype

Tormod Volden (tormodvolden) wrote :

As noted in the bug description, this is skype 2.1.0.81 but I saw the same with 2.1.0.47.

Tormod Volden (tormodvolden) wrote :
Tormod Volden (tormodvolden) wrote :
boilerbots (forums-boilerbots) wrote :

This worked for me, comment out "module-suspend-on-idle" from the system.pa and default.pa files then shutdown gdm and kill all running pulseaudio daemons. Re-start GDM and now it seems to work without audio lag.

I noticed that the amount of time required after a call for the lag to occur is coincident with this suspend-on-idle time. I don't know what this means but it might help someone fix the real problem.

pzukowski (paul-zukowski) wrote :

boilerbots: where are the system.pa default.pa files? I am still new to Linux. Thanks.

Daniel T Chen (crimsun) on 2010-02-22
Changed in pulseaudio (Ubuntu):
assignee: nobody → Daniel T Chen (crimsun)
importance: Undecided → Medium
status: New → In Progress
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package pulseaudio - 1:0.9.22~0.9.21+stable-queue-32-g8478-0ubuntu10

---------------
pulseaudio (1:0.9.22~0.9.21+stable-queue-32-g8478-0ubuntu10) lucid; urgency=low

  * 0093-backport-fixes-stable-queue-head.patch: Backport the following
    changesets from the stable-queue branch:
    + dfe27f (don't complain about missing SHM segments)
    + 5ce18c (fix definition of INVALID_INDEX for vala)
    + 6bbdd2 (fix definition of the GLib mainloop adapter for vala)
    + 3f44bf (Use "Subwoofer" in channelmap)
    + 117c99 (fix wrapping of port setting calls for vala)
    + ddabaa (explicitly mention 'test' role in proplist)
    + 8adf53 (increase verboseness when not restoring sink)
    + 180589 (use sample name for unmodified fallback)
    + f9b957 (don't queue cached sample when sink is suspended)
    + b2e9fb (pass buffer_attr to recording streams)
    + a469d4 (make devices resume for corked state to fix latency
      miscalculation) (LP: #511558)
    + 4a3210 (improve buffer_attrs logging)
  * 0094-add-missing-mixer-paths-and-rerun-automake.patch has been
    merged upstream (047e16f in the stable-queue branch), but we'll continue to
    carry it until the next stable tarball is rolled.
 -- Daniel T Chen <email address hidden> Sun, 21 Feb 2010 22:37:37 -0500

Changed in pulseaudio (Ubuntu):
status: In Progress → Fix Released
Changed in pulseaudio (Fedora):
importance: Unknown → Medium
status: Unknown → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.