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:
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
I discovered that the sound delay disappears if I make a few calls to skype test call, after starting Skype.
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
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.
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.
(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.
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:)
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.
s/are/a
(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.
Jette, thanks for the suggestion. Hopefully we can get it fixed completely.
Tried removing alsa-plugins-pulseaudio and it didn't fix it.
A new version of skype 2.1 beta was released today (2.1.0.81), does that make any difference?
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.)
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.
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.)
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.
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
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?
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.
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...
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.
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.
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
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
I'll upload a new package with this fix in PA soon.
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?
commenting it out works great for me too. Many thanks Lennart.
(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.
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
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
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.
(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.
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.
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.
(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.
It got muted somehow(alert), so that was it. Thanks! Sorry
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.
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.
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.
With pulseaudio-0.9.21-5.fc12.i686, Skype works nicely, but I hear nothing when playing YouTube videos with Adobe Flash.