Bug 554929 - Lag with Pulseaudio/Skype, PA not providing requested latency
Lag with Pulseaudio/Skype, PA not providing requested latency
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: pulseaudio (Show other bugs)
12
All Linux
low Severity medium
: ---
: ---
Assigned To: Lennart Poettering
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 566327
  Show dependency treegraph
 
Reported: 2010-01-12 21:53 EST by tedtheologian
Modified: 2010-03-06 13:49 EST (History)
16 users (show)

See Also:
Fixed In Version: pulseaudio-0.9.21-5.fc12
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 566327 (view as bug list)
Environment:
Last Closed: 2010-02-23 18:19:51 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Output of pacmd list-sink-inputs during skype usage (1.27 KB, text/plain)
2010-01-13 04:06 EST, tedtheologian
no flags Details
a piece of PA log (19.34 KB, text/plain)
2010-01-13 05:10 EST, Michal Schmidt
no flags Details

  None (edit)
Description tedtheologian 2010-01-12 21:53:07 EST
Description of problem:
Using PA in latest skype, often there is a severe lag in the audio.  This can be displayed by running:

"pacmd list-sink-inputs" and "pacmd list-source-outputs"

while skype is being used.  If there is lag you are experiencing, you will see the current latency is FAR higher than requested latency.


Version-Release number of selected component (if applicable):
pulseaudio-0.9.21-2


How reproducible:
Often, if not every time.

Steps to Reproduce:
1. Use skype.
2. Notice lag.
3. Run pacmd list-sink-inputs or pacmd list-source-outputs and notice discrepancy. 
  
Actual results:
Severe lag.

Expected results:
Current = requested.

Additional info:
Comment 1 tedtheologian 2010-01-13 04:06:27 EST
Created attachment 383436 [details]
Output of pacmd list-sink-inputs  during skype usage

See the difference in the lantecies?

	current latency: 2004.02 ms
	requested latency: 48.00 ms
Comment 2 Jette Derriche 2010-01-13 04:32:43 EST
I discovered that the sound delay disappears if I make a few calls to skype test call, after starting Skype.
Comment 3 Michal Schmidt 2010-01-13 05:10:46 EST
Created attachment 383450 [details]
a piece of PA log

We had a discussion about this on #pulseaudio where tedtheologian (aka. AnNahar on IRC) put a piece of PA log on pastebin. I'm attaching it here so it does not get lost.

ohsix on IRC noticed this tlength increase in the log:
protocol-native.c: max_request changed, trying to update from 3328 to 128256.

<ohsix> if i'm not mistaken, in that log when it adjusted the tlength, that was the added latency he was seeing
<ohsix> but the log had no indication of why, except the flub from alsa
Comment 4 tedtheologian 2010-01-13 08:58:57 EST
The flub from alsa occurs regarding the USB Headset, but the problem occurs even without the USB Headset.  

The log they reference may not have indicated why, but at the same time, pacmd list-sink-inputs still showed a latency difference like the one posted here.
Comment 5 tedtheologian 2010-01-13 09:11:00 EST
Jette, you'll probably discover it eventually returns as well.  If you are expecting incoming calls, like via skypein, you can't just keep hanging up on people and hoping eventually the lag isn't there.
Comment 6 Jette Derriche 2010-01-13 09:42:34 EST
(In reply to comment #5)
> Jette, you'll probably discover it eventually returns as well.  If you are
> expecting incoming calls, like via skypein, you can't just keep hanging up on
> people and hoping eventually the lag isn't there.    

Correct... 

If I receive a call with sound delay, I tell people to hang up and then I fix the delay and call them back. It is a pain, but at least I am able to have conversations.

I just wanted to mention this 'fix' since nobody else had mentioned it, and some people might think they cant make calls until it is fixed.
Comment 7 tedtheologian 2010-01-13 11:41:23 EST
I'd have to take issue with calling that a fix, or even a workaround.  Some people use skypein as a business line, etc, and telling people you have to hang up after they call you is not a fix, it's a recipe for sounding like you're working out of a bathroom:)
Comment 8 Lennart Poettering 2010-01-13 15:11:01 EST
Michal is right, the tlength is the point where the latency is bumped up. tlength is the "target length" that controls how much audio data the server will ask for and keep around from the client.

tlength was set to 3328 and then bumped up to 128256. Given the sampling freq and sampling units this boils down to 1000*3328/4/16000 = 52ms to 1000*128256/4/16000 = 2004ms which is the about the latency that is apparently experienced here. So now the problem is to figure out what exactly caused this bump.

Michal, I owe you are beer.
Comment 9 Lennart Poettering 2010-01-13 15:13:26 EST
s/are/a
Comment 10 Jette Derriche 2010-01-13 16:17:11 EST
(In reply to comment #7)
> I'd have to take issue with calling that a fix, or even a workaround.  Some
> people use skypein as a business line, etc, and telling people you have to hang
> up after they call you is not a fix, it's a recipe for sounding like you're
> working out of a bathroom:)    

I saw this tip on another website, and it helped me. But I should probably not have written this information here. I am sorry.
Comment 11 tedtheologian 2010-01-13 20:37:39 EST
Jette, thanks for the suggestion.  Hopefully we can get it fixed completely.
Comment 12 tedtheologian 2010-01-20 12:20:11 EST
Tried removing
alsa-plugins-pulseaudio

and it didn't fix it.
Comment 13 Andrew Hutchings 2010-01-21 07:21:40 EST
A new version of skype 2.1 beta was released today (2.1.0.81), does that make any difference?
Comment 14 Péter Kovács 2010-01-22 03:00:03 EST
No apparent improvement. (I didn't do the pacmd diagnostic thing, just made a call on the local network. The sound is of excellent quality except that there is a delay of about 1 second.)
Comment 15 tedtheologian 2010-01-23 14:06:04 EST
I can confirm that the new release does not fix the problem.  I'm having to do a test call before I call someone to fix the delay temporarily.  I do a test call, hang up,then I can call someone without delay.  Not a good solution, particularly if someone calls you.
Comment 16 Péter Kovács 2010-01-24 04:39:48 EST
Test calls don't help in my case (2.6.31.12-174.2.3.fc12.i686.PAE #1 SMP, pulseaudio 0.9.21). The delay problem persists even after two test calls. (The only workaround I found is to disable pulse audio entirely.)
Comment 17 Juergen Kaiserling 2010-01-24 10:05:02 EST
Bringing up the dialpad as suggested earlier did not change anything for me.  I was on a lengthy Skype-to-Skype call last night and found that the amount of delay varied significantly within the hour, increasing in time.  Towards the end of the 1:08:xx call, I had over 2 seconds delay.

If it concerns anyone on here, because I don't know if it is related, the video was misbehaving also.  My friend did not turn on his video, but mine came through normally to the bottom of my forehead.  From there on to the bottom of the screen, the video kept repeating itself for about 5 seconds before refreshing to the next repeating segment.
Comment 18 Kronos003 2010-01-26 17:00:59 EST
I may have found a "fix" - sort of. and this may shed some light on the point of failure and bring us a step closer to a clean solution. This may indeed be a pulseaudio problem.

For the last day and a half I've been playing music constantly via amarok. This may work for other players as well. During this time when people called me or i called them - the latency was normal. the call established immediately and no lag other than network lag was noticed. no need to call and callback to kill the lag.

my suspicion is this. pulse is having issues connecting and syncing to the audio driver when Skype asks for a connection. this is what is inducing the 1s-3s lag. 

-why playing music works- 
Since pulse already has a connection open because of amarok, there is no lag induced while Skype is waiting for pulse to connect to alsa. hence no lag. At this point I'm not sure why other apps dont have this problem when Skype does. Perhaps there needs to be a way for Skype (or maybe even pulse) to monitor this situation and drop enough of the stream to catch up to realtime.

-The Temporary Solution- (Please post how this works for you)
use amarok or other application to constantly be playing a music track. I'm betting this track could be silence and would work.


-So what now?-
so now the question is how do we fix this in skype or pulseaudio - or both. it seems when Skype is NOT the first app to request a connection to a sound driver, there is no issue. so maybe we could find a way to constantly keep a connection open between pulse at all times?(this seems like a potentially dirty fix that we would want an option to enable/disable - i could see it potentially breaking other things)


Here are my relevant specs:

Fedora 12
Linux localhost 2.6.31.12-174.2.3.fc12.x86_64 #1 SMP Mon Jan 18 19:52:07 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux

amarok-2.2.2-3.fc12.x86_64
pulseaudio-0.9.21-2.fc12.x86_64
skype-2.1.0.81-fc10.i586
Comment 19 Kronos003 2010-01-26 17:56:37 EST
hmm - looks like the first app to cause pulse to open a connection to your sound driver gets lagged.(subsequent connections open without any lag from what i can see) Just noticed this in amarok. that might be why the using a sound player to  get pulse to hold open a connection works so well to cut the lag for applications that connect after the connection is already open.

What is going on here?
Comment 20 Juergen Kaiserling 2010-01-27 16:29:14 EST
I tried to repeat Kronos experience this morning with Banshee instead.  Had my son do it likewise.  We both unooaded Skype, brought up Banshee, selected a radio station and loaded Skype.  BTW, this is the only situation that sounds the Skype noise and ringer (by having another application with sound loaded).  We still experienced long varying delays of up to 2 - 3 seconds.
Comment 21 Kronos003 2010-01-28 12:22:50 EST
OK - i think i have a better fix. fenris02 in #fedora at freenode pointed me to this guide.

http://fedorasolved.org/Members/fenris02/pulseaudio-fixes-and-workarounds

I am on Fedora 12 and used the following sections

::Doing the Work 2 (only if #1 above did not resolve the issue):: 
steps 1, 1, 3, and 5


I haven't tested the other parts of the guide, but doing what i did fixed the situation for me. I've been testing it for the last hr or so. I no longer need to be playing something in the background for this to work, but i did notice an increase in cpu usage. Im willing to bet this might make some older boxes rather unhappy...

So now it seems i have no more lag issue. no more hard jump in lag when switching outputs and inputs during a call.

anyway - if this works for you be sure to thank fenris02

Im not sure if this qualifies as a bug fix since it involves turning off timer based scheduling and switching to realtime scheduling. Would be nice to be able to get these results on timer based scheduling...
Comment 22 Jim Hunziker 2010-02-08 11:20:09 EST
I am experiencing the current and requested latency mismatch with Skype 2.1 (64-bit).  As someone mentioned somewhere, the latency goes away if you make enough test calls in a row, and you can tell if the latency is going to be there by how long it takes from when you click to when the dialing sound starts.

Something I noticed that hasn't been mentioned here is that, on calls with high latency, my syslog has entries that look like this:

Feb  8 11:01:30 jhunziker-e6500 pulseaudio[28028]: ratelimit.c: 712 events suppressed
Feb  8 11:01:50 jhunziker-e6500 pulseaudio[28028]: ratelimit.c: 729 events suppressed
Feb  8 11:02:09 jhunziker-e6500 pulseaudio[28028]: ratelimit.c: 333 events suppressed
Feb  8 11:02:19 jhunziker-e6500 pulseaudio[28028]: ratelimit.c: 363 events suppressed
Feb  8 11:04:26 jhunziker-e6500 pulseaudio[28028]: ratelimit.c: 680 events suppressed

Calls with low latency don't have these messages.  I've tried pulseaudio 0.9.19 and 0.9.21.
Comment 23 James 2010-02-10 16:38:38 EST
In my experience, this bug isn't limited to Skype, it's probably just most visible there. I get it with Exaile (gstreamer) if it's the first thing for which Pulseaudio provides service:


$ pacmd list-sink-inputs
Welcome to PulseAudio! Use "help" for usage information.
>>> 1 sink input(s) available.
    index: 1
	driver: <protocol-native.c>
	flags: START_CORKED 
	state: RUNNING
	sink: 0 <alsa_output.pci-0000_00_1b.0.analog-stereo>
	volume: 0: 100% 1: 100%
	        0: 0.00 dB 1: 0.00 dB
	        balance 0.00
	muted: no
	current latency: 1964.67 ms
	requested latency: 90.00 ms
	sample spec: float32le 2ch 44100Hz
	channel map: front-left,front-right
	             Stereo
	resample method: copy
	module: 8
	client: 4 <exaile.py>


and so-on. This has an audible artefact in the form of a brief glitch in the audio about 2 seconds after resuming from pause (see bug 540651). If I then change tracks in Exaile, the latency drops down to something more like what's requested:

	current latency: 72.46 ms
	requested latency: 90.00 ms

and the glitch is correspondingly much sooner.
Comment 24 Kronos003 2010-02-11 02:22:34 EST
I think a good interim fix would be to have a console option to resync a stream - that is to tell pulse to disconnect and reconnect a stream to get the requested latency


it would be nice to have this option in the following places:

console command to resync a given stream(s) possibly with an option to do all streams on one or more devices

 --> a button to resync each stream in pavucontrol <-- THIS would save a lot of trouble for many of us

(if this isnt being done already) an api function in which applications can check to see if they are getting the latency required, then if they are not they can resync themselves based on their own algorithm(x percentage higher than requested)

this would make timer based scheduling much more attractive. it already sounds nicer than realtime scheduling on my system
Comment 25 Lennart Poettering 2010-02-21 21:50:52 EST
OK, there are two issues here. Once, Skype does not really provide the data PA asks for which needs in time to be fixed in Skype (and which I'll pass on them). The other issue is that the negotiation of the buffering/latency parameters Skype asks for is not working correctly if the device in question is suspended and needs to be resumed for audio playback. This is issue is probably what most folks are experiencing. An easy way to work around this to unload module-suspend-on-idle before doing a Skype call. This should fix most problems.

The PA part of the issue is fixed here:

http://git.0pointer.de/?p=pulseaudio.git;a=patch;h=a469d44e6993c4e9e7a53ac91ed53eacb500e279
Comment 26 Lennart Poettering 2010-02-21 23:01:29 EST
I'll upload a new package with this fix in PA soon.
Comment 27 Jim Hunziker 2010-02-22 10:06:04 EST
I can confirm that commenting out

load-module module-suspend-on-idle

from my /etc/pulse/default.pa fixes the Skype problem without having to apply your patch.  Is there any potential harm in not letting sinks suspend?
Comment 28 Andrew Hutchings 2010-02-22 10:29:12 EST
commenting it out works great for me too.  Many thanks Lennart.
Comment 29 Lennart Poettering 2010-02-22 10:37:50 EST
(In reply to comment #27)
> from my /etc/pulse/default.pa fixes the Skype problem without having to apply
> your patch.  Is there any potential harm in not letting sinks suspend?    

Yes. The audio device is never closed during PA's runtime. That means it cannot be powered down and PA will always consume a bit of CPU to write silence the device. Effectively that means it will shorten your battery life.
Comment 30 Fedora Update System 2010-02-23 18:12:47 EST
pulseaudio-0.9.21-6.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/pulseaudio-0.9.21-6.fc13
Comment 31 Fedora Update System 2010-02-23 18:13:15 EST
pulseaudio-0.9.21-5.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/pulseaudio-0.9.21-5.fc12
Comment 32 tedtheologian 2010-03-03 17:50:22 EST
Seems the new version, at least 9.21-5.fc12, is bringing another bug of it's own:

DEBUG: Ignoring sink-input due to it being designated as an event and thus handled by the Event widget

I get that error and no sound on certain skype events now, such as incoming call ring.
Comment 33 Lennart Poettering 2010-03-03 18:48:08 EST
(In reply to comment #32)
> 
> DEBUG: Ignoring sink-input due to it being designated as an event and thus
> handled by the Event widget

That is a debug message generated by pavucontrol. Ignore it.

> I get that error and no sound on certain skype events now, such as incoming
> call ring.    

It's not an error. It's a debug message. That's why it is prefixed with "DEBUG:"...

Skype properly marks ring sounds as event sounds. Hence the event/system sound slider in pavucontrol/g-v-c applies to it.

Nothing of this has anything to do with this update.
Comment 34 tedtheologian 2010-03-03 20:27:35 EST
Lennart, thanks.

However, when I click "make test sound" in skype settings, I get the same error, and no sound.  All of this since update of PA.
Comment 35 tedtheologian 2010-03-04 02:01:19 EST
Also, if I have pavucontrol open during this time, it shows nothing during playback when I hit "make a test sound."

For the sounds that work, I do not get that debug error.
Comment 36 Lennart Poettering 2010-03-04 12:20:48 EST
(In reply to comment #34)
> Lennart, thanks.
> 
> However, when I click "make test sound" in skype settings, I get the same
> error, and no sound.  All of this since update of PA.    

Which error are you speaking of?

And are you sure you have unmuted the alert volume in gnome-volume-control?

(In reply to comment #35)
> Also, if I have pavucontrol open during this time, it shows nothing during
> playback when I hit "make a test sound."

Yes, event sounds are shown only via the System Sounds slider.
Comment 37 tedtheologian 2010-03-04 12:36:41 EST
It got muted somehow(alert), so that was it.

Thanks!  Sorry
Comment 38 Peter Svensson 2010-03-04 13:51:37 EST
FWIW: I have no problems after installing the PA version from -testing. Skype works perfectly even on a low-powered netbook running in battery-optimized mode. 

Good work.
Comment 39 Fedora Update System 2010-03-04 22:40:59 EST
pulseaudio-0.9.21-6.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 40 Fedora Update System 2010-03-05 22:41:46 EST
pulseaudio-0.9.21-5.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 41 Péter Kovács 2010-03-06 13:49:50 EST
With pulseaudio-0.9.21-5.fc12.i686, Skype works nicely, but I hear nothing when playing YouTube videos with Adobe Flash.

Note You need to log in before you can comment on or make changes to this bug.