Sound lags when opening video files

[Simplehuman]

When I open any video file from Nautilus or from VLC I see that video starts but there is no sound. It takes a few seconds and the sound appears, but since the beginning of the audio track. So video and sound are out of sync.

The workaround is to rewind the video at the beginning by using the slider.

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: vlc-nox 2.0.4-0ubuntu1
ProcVersionSignature: Ubuntu 3.5.0-18.29-generic 3.5.7
Uname: Linux 3.5.0-18-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.6.1-0ubuntu4
Architecture: amd64
Date: Sun Oct 21 01:33:08 2012
ExecutablePath: /usr/bin/vlc
InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Beta amd64 (20121006)
MarkForUpload: True
ProcEnviron:
 LANGUAGE=ru_UA:ru
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=ru_UA.UTF-8
 SHELL=/bin/bash
SourcePackage: vlc
UpgradeStatus: No upgrade log present (probably fresh install)

[Mort Yao (mort-yao)]

The commit http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=a813e85503355496c7ea6397e39072fd8ffedcff (sink,source: Update sample rate if possible on stream uncork) causes an audio/video synchronization issue in VLC media player (2.0.1).
The audio track always comes with a few seconds of delaying after the video starts to play (but once the video scroll bar is dragged the audio should be synchronized with the video again)
After reversed this diff the issue does not appear in VLC anymore.

The problem seems to be VLC only; Totem and MPlayer works fine with this commit.

* pulseaudio/libpulse 2.0-1
* vlc 2.0.1-1
* gnome-shell 3.4.1 on Arch x86_64

[Gareth Hart (tghe-retford)]

Created attachment 61893
vlc -vvv console output

Also the same on my system. For your information, both VLC 2.0.1 stable package and VLC git 20120520 build show the error. I am using Arch Linux with kernel 3.3.6-1-ARCH and PulseAudio package version 2.0.1. My laptop has the Intel 6 series/C200 series chipset family high definition audio controller and the bug occurs with both the analog and IEC958 S/PDIF outputs.

[Newton-electron (newton-electron)]

I'm also getting the same error with pulseaudio 2.0-1. I'm using kernel 3.3.6-1-ARCH.

Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller

[Kittyinapc (kittyinapc)]

Created attachment 63123
VLC console log

[Kittyinapc (kittyinapc)]

I am also having this problem on debian. I have not noticed a delay but it causes my audio to crackle which is very annoying.

Versions:

VLC media player 2.0.1 Twoflower (revision 2.0.1-0-gf432547)
VLC version 2.0.1 Twoflower (2.0.1-0-gf432547)
Compiled by pbuilder on www.marillat.net (May 29 2012 16:35:24)
Compiler: gcc version 4.7.0 (Debian 4.7.0-10)

pulseaudio 2.0

Here is where someone posted the bug to vlc's bug tracker: https://trac.videolan.org/vlc/ticket/6853. It has been marked as notvlc so I presume this is a pulseaudio issue.

I've attached my vlc log.

[Kittyinapc (kittyinapc)]

It seems the problem is intermittent and present at the start for me. For example at the start I see this and eventually it gets to 44100hz.

[0xe7f978] pulse audio output warning: too late by 63581 us
[0xe7f978] pulse audio output debug: changed sample rate to 44343 Hz
[0xe7f978] pulse audio output warning: too late by 63074 us
[0xe7f978] pulse audio output debug: changed sample rate to 44381 Hz
[0xe7f978] pulse audio output warning: too late by 62122 us
[0xe7f978] pulse audio output debug: changed sample rate to 44413 Hz
[0xe7f978] pulse audio output warning: too late by 60691 us
[0xe7f978] pulse audio output debug: changed sample rate to 44439 Hz
[0xe7f978] pulse audio output debug: changed sample rate to 44353 Hz
[0xe7f978] pulse audio output debug: changed sample rate to 44267 Hz
[0xe7f978] pulse audio output debug: changed sample rate to 44181 Hz
[0xe7f978] pulse audio output debug: changed sample rate to 44100 Hz

While the too late by x ms is happening other sounds in my system distort or crackle. Will test further on request.

[Leszek Lesner (leszek-lesner)]

Opening /etc/pulse/default.pa and disabling timerbased scheduling by replacing
load-module module-udev-detect
with
load-module module-udev-detect tsched=0
solves the problem here after a reboot.

[Rémi Denis-Courmont (rdenis)]

There are two sides to this:
1/ VLC 2.0.4 starts PulseAudio playback late. This should be fixed in VLC-2.0 commits 0554a01551ae49613062c2d96701d277000e4109 and 9701837bb454c682ba5697e665d79d6e51ae305d.
2/ Depending on the audio hardware, PulseAudio tends to suspend the VLC sink (input) and then spends almost 2 seconds between the time VLC asks to start and the time it actually starts. I believe this is a PulseAudio bug and I have been bringing it on #pulseaudio for several months. But the PulseAudio developers are not paid to support VLC, so they are in no hurry to fix it.

[Rémi Denis-Courmont (rdenis)]

In any case, it would help to have the VLC and PulseAudio logs...

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Simplehuman (simplehuman)]

Pulseaudio log

[Simplehuman (simplehuman)]

I hope it is correct VLC log. It is the way I found in Google to make it.

[Rémi Denis-Courmont (rdenis)]

No that does not look like the full VLC log.

[Simplehuman (simplehuman)]

Please, tell me how can I make a correct full VLC log

[Rémi Denis-Courmont (rdenis)]

vlc -vv

[Simplehuman (simplehuman)]

This is what I've got in the terminal

[Raymond (superquad-vortex2)]

which sound card are you using ?

the had_prealloc_max was change back to 64 since ubuntu 12.04

  0.718| 0.000) I: [pulseaudio] source.c: sysfs.path = "/devices/pci0000:00/0000:00:07.0/0000:04:00.1/sound/card0"
( 0.718| 0.000) I: [pulseaudio] source.c: device.bus = "pci"
( 0.718| 0.000) I: [pulseaudio] source.c: device.vendor.id = "10de"
( 0.718| 0.000) I: [pulseaudio] source.c: device.vendor.name = "NVIDIA Corporation"
( 0.718| 0.000) I: [pulseaudio] source.c: device.product.name = "GF110 High Definition Audio Controller"
( 0.718| 0.000) I: [pulseaudio] source.c: device.string = "0"
( 0.718| 0.000) I: [pulseaudio] source.c: module-udev-detect.discovered = "1"
( 0.718| 0.000) I: [pulseaudio] source.c: device.icon_name = "audio-card-pci"
( 0.718| 0.000) I: [pulseaudio] alsa-sink.c: Using 2.0 fragments of size 32768 bytes (185.76ms), buffer size is 65536 bytes (371.52ms)
( 0.718| 0.000) I: [pulseaudio] alsa-sink.c: Time scheduling watermark is 20.00ms
( 0.718| 0.000) D: [pulseaudio] alsa-sink.c: hwbuf_unused=0
( 0.718| 0.000) D: [pulseaudio] alsa-sink.c: setting avail_min=15502

   0.824| 0.000) I: [pulseaudio] source.c: sysfs.path = "/devices/pci0000:00/0000:00:1c.5/0000:05:00.0/0000:06:04.0/sound/card1"
( 0.824| 0.000) I: [pulseaudio] source.c: device.bus = "pci"
( 0.824| 0.000) I: [pulseaudio] source.c: device.vendor.id = "13f6"
( 0.824| 0.000) I: [pulseaudio] source.c: device.vendor.name = "C-Media Electronics Inc"
( 0.824| 0.000) I: [pulseaudio] source.c: device.product.name = "CMI8788 [Oxygen HD Audio]"
( 0.824| 0.000) I: [pulseaudio] source.c: device.string = "1"
( 0.824| 0.000) I: [pulseaudio] source.c: module-udev-detect.discovered = "1"
( 0.824| 0.000) I: [pulseaudio] source.c: device.icon_name = "audio-card-pci"
( 0.824| 0.000) I: [pulseaudio] alsa-sink.c: Using 1.0 fragments of size 352800 bytes (2000.00ms), buffer size is 352800 bytes (2000.00ms)
( 0.824| 0.000) I: [pulseaudio] alsa-sink.c: Time scheduling watermark is 20.00ms
( 0.824| 0.000) D: [pulseaudio] alsa-sink.c: hwbuf_unused=0

[Simplehuman (simplehuman)]

Now I'm using Asus Xonar Essence STX . But the problem was there on Creative Sound Blaster X-Fi Xtreme Gamer.

[Simplehuman (simplehuman)]

*Was there also

[Rémi Denis-Courmont (rdenis)]

This is the same as http://trac.videolan.org/vlc/ticket/6853 and is a regression in PulseAudio version 2.0. For some reasons, PulseAudio starts playing back the VLC stream two seconds after VLC asks.

That cannot work nicely from user experience point of view.

[Simplehuman (simplehuman)]

But with Totem there are no problems. It is also using PulseAudio, right?

I've noticed that the problem does not always appear. But it is there for ~90% cases.

[Rémi Denis-Courmont (rdenis)]

But with ALSA or PulseAudio 1.0, there are no problems. This is using VLC, right?

Silly argument.

[Simplehuman (simplehuman)]

If any other media player (not only Totem) is using PulseAudio 2.0 and don't have any problems, and VLC does. Maybe it would be logical to assume that the problem is in VLC?

Please, don't be so agressive.

[Raymond (superquad-vortex2)]

the lag was observed for mp4 video for vlc since ubuntu 12.04

but mplayer can play the same video correctly

are you playing mp4 video to iec958 ?

may be a bug in alsa driver

[Rémi Denis-Courmont (rdenis)]

As said earlier, the lesser part of the problem is a regression in VLC 2.0.4. It is fixed in VLC-2.0 commits 0554a01551ae49613062c2d96701d277000e4109 and 9701837bb454c682ba5697e665d79d6e51ae305d.

The more quantitative part of the problem is a delay of about 2 seconds in PulseAudio startup when the "alternate sample rate" feature is enabled. I am not familiar with PulseAudio internals, so I do not know the root cause. It might also be a weird ALSA driver bug, for all I know. Anyhow, the problem can be worked around by forcing 'alternate-sample-rate' to the same value as 'default-sample-rate' in /etc/pulse/daemon.conf, e.g.:

default-sample-rate = 44100
alternate-sample-rate = 44100

[Rémi Denis-Courmont (rdenis)]

P.S.: As far as I understand, the alternate sample rate was introduced with PulseAudio version 2.0, hence the bug did not occur with earlier versions. So it seems I was right in claiming it comes from a PA rather than VLC update.

[Simplehuman (simplehuman)]

I don't see this issue any more for over 1-2 days. And I have updated only VLC from stable daily builds. So maybe the problem was with VLC and not with Pulseaudio?

[Victor Zamanian (victorz)]

I am still seeing this issue with VLC 2.0.4+git20121208+r469-0~r43~quantal1 from the daily stable PPA.

[Simplehuman (simplehuman)]

I'm talking about this version. But I don't see this issue for 2 days with a lot of video files. Maybe it forks with some codecs and with other don't?

[Simplehuman (simplehuman)]

Here is some proof to my words. I didn't do anyting with any settings and don't install any new software. After VLC update everything is back to normal. No sound unsynchronization

[Raymond (superquad-vortex2)]

did your sound card support 44100Hz or 48000Hz ?

this patch limited the supported rate

http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/src/modules/alsa/alsa-sink.c?id=e67440e2208fb8182916493b57b75e91013510e7

http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=2a48c2d66f0484a914d626faecc3c6aba8851f0e

[Simplehuman (simplehuman)]

I have Asus Xonar Essence STX . I really don't know about 44100Hz or 48000Hz .

But the problem is back after another VLC update.

[Benjamin Drung (bdrung)]

Which VLC version do you have installed?

[Simplehuman (simplehuman)]

After todays update it is 2.0.5+git20121215+r477-0~r44~quantal1

[Benjamin Drung (bdrung)]

Do you know which version was the last working one?

[Simplehuman (simplehuman)]

Recording to my comment #32 and #33 with a video proof. The version was VLC 2.0.4+git20121208+r469-0~r43~quantal1

[Victor Zamanian (victorz)]

Interesting. The VLC team seems to claim that the PulseAudio sync issues are fixed. They posted on their news blog[1] on 2012-12-15 with a link to release notes of version 2.0.5, saying: "2.0.5 also improves the Mac OS interface, some video filters and Pulseaudio synchronization."[2]

Meanwhile, I have VLC version 2.0.5+git20121217+r478-0~r44~quantal1 (i.e. git snapshot from 2012-12-17 -- *after* the release of 2.0.5), and the PulseAudio initial audio delay is still there. Very curious.

[1] http://www.videolan.org/news.html
[2] http://www.videolan.org/vlc/releases/2.0.5.html

[Benjamin Drung (bdrung)]

regression.diff is the diff between 2.0.4+git20121208+r469-0~r43~quantal1 (claimed working) and 2.0.5+git20121215+r477-0~r44~quantal1 (claimed broken). When stripping the translation and non-Linux changes, regression_stripped.diff is left. It does not contain any change to the pulseaudio plug-in that could explain the changed behavior.

[Simplehuman (simplehuman)]

It looks like this issue is random now. If I launch the same video a chance to catch this bug is 50\50.

[Simplehuman (simplehuman)]

So maybe there are no regression. The bug is not fully fixed. IMHO

[Rémi Denis-Courmont (rdenis)]

I am aware of two lag bugs involving PA and VLC:

* Pseudo-random delay with VLC 2.0.4 only.
-> Fixed in VLC 2.0.5.

* 1,9 to 2 seconds delay with PulseAudio 2.0 or later.
-> Not fixed to date, but work-around in comment #21.

[Victor Zamanian (victorz)]

I think I'm on to something here. (I'm now using version 2.0.5+git20121219+r480-0~r44~quantal1, just for your information.) Allow me to explain.

First of all, I have this GNOME Shell extension installed, which might help when debugging this: https://extensions.gnome.org/extension/212/advanced-volume-mixer/

The extension shows which applications are currently using the sound device. During the time when an application is using the sound device, e.g. a video on YouTube is playing, *and* for a short time after, such as when pressing Pause in the YouTube player, there will be a volume item for that particular application in GNOME Shell's volume menu. (You can try this.) There will be one volume slider per application, as well as the master volume.

So now, if I have at least one other application using the audio device, i.e. there is another item in GNOME Shell's volume menu at the time I press the Play button in VLC, then there is *no* initial audio delay in VLC. I repeat, there is *no* audio delay if another application is or very recently was using the audio device. (I guess it takes a while between pausing audio on YouTube and it being unregistered from PulseAudio's list of applications using the audio device.) This is 100 % for me.

After pausing the YouTube video and waiting until Chrome's ALSA plugin is removed from the volume menu, then the audio delay is back again in VLC when pressing play. This is also 100 % for me. So the correlation seems very strong.

My uneducated guess is that it takes about 2 seconds or something until PulseAudio has "warmed up" if no application is using it previously? Or maybe some weird VLC-PulseAudio buffers have to fill before playing the audio? I'll let you folks be the judge. Anyway, it appears (to me at least) that the bug lies with VLC since none of my other audio-playing applications seem to suffer from this bug. Meaning, when I play a video with VLC for example, there is no audio delay on YouTube if a choose to start a video there.

PS: Don't try this with Rhythmbox, as pressing Pause in Rhythmbox never removes the volume item from the volume menu, for some reason.

[Zhou Yi Chao (broken-zhou)]

Same here. Really annoying for VLC user.

I'm not familar with pa so I cannot say whether this patch is has something wrong or not. !!!!!!!But this commit broken the userspace!!!!!!! Should it be reverted?

It's 7 month after this bug has been reported. Should the developer say something to show that this bug is not totally ignored?

[Tanu Kaskinen (tanuk)]

(In reply to comment #7)
> Same here. Really annoying for VLC user.
>
> I'm not familar with pa so I cannot say whether this patch is has something
> wrong or not. !!!!!!!But this commit broken the userspace!!!!!!! Should
> it be reverted?
>
> It's 7 month after this bug has been reported. Should the developer say
> something to show that this bug is not totally ignored?

Sure, I can say something. The problematic commit implements a useful feature, so it probably won't be simply reverted. A better fix is needed (patches very welcome). There have been fixes related to the sample rate updating since pulseaudio 2.0, so it's worth retrying with pulseaudio 3.0, but I don't remember that those fixes would have been timing related, so don't expect too much.

[Tanu Kaskinen (tanuk)]

(In reply to comment #8)
> (In reply to comment #7)
> > Same here. Really annoying for VLC user.
> >
> > I'm not familar with pa so I cannot say whether this patch is has something
> > wrong or not. !!!!!!!But this commit broken the userspace!!!!!!! Should
> > it be reverted?
> >
> > It's 7 month after this bug has been reported. Should the developer say
> > something to show that this bug is not totally ignored?
>
> Sure, I can say something. The problematic commit implements a useful
> feature, so it probably won't be simply reverted. A better fix is needed
> (patches very welcome). There have been fixes related to the sample rate
> updating since pulseaudio 2.0, so it's worth retrying with pulseaudio 3.0,
> but I don't remember that those fixes would have been timing related, so
> don't expect too much.

Thinking a bit more, reverting the patch (or maybe commenting out the code would be better) is maybe the right approach after all, if nobody submits a better fix. Removing the code that was added that patch shouldn't really break anything, the only effect should be that there's sometimes unnecessary resampling, which is better than breaking the timing of applications.

[Tanu Kaskinen (tanuk)]

Before removing any functionality, this must be reproducible by a pulseaudio developer, though. Otherwise there's no way to know when it's safe to add the functionality back. I can't reproduce this with vlc version 2.0.3 and pulseaudio's current development version. I'll try installing vlc 2.0.1 and pulseaudio 2.0 later today.

[Courmisch (courmisch)]

This affects all VLC versions (however please avoid VLC version 2.0.4, which has an audio latency bug of its own), with PulseAudio 2.x.

[Tanu Kaskinen (tanuk)]

Any further hints for reproducing? I have pulseaudio 2.0 installed, and since vlc version shouldn't matter, I still have vlc 2.0.3, not 2.0.1 that the original reporter used. A/V sync is just fine for me, with both pulseaudio and alsa (through pulseaudio) backends of vlc.

[Courmisch (courmisch)]

For me, the bug strikes when all of the following conditions are met:
- The sink (Intel HDA) is inactive.
- The new sink input is created with the _same_ sample rate as the last sink input that was previous connected to the sink.
- Alternate rate is enabled (44100 and 48000).
Correlation/Reproducibility is 100%.

Then there is approximately 2 seconds delay between VLC "trigger"ing its sink input and PulseAudio actually starting playback. (Note that VLC uses manual trigger.)

The bug does NOT strike when alternating sample rate.
The bug does NOT strike when alternate rate are disabled in the configuration.
That is very confusing.

[Tanu Kaskinen (tanuk)]

I was now able to reproduce this. For me this doesn't seem to happen 100% of the time (I test by running "vlc ~/misc/sync_test.mp4", observing the A/V sync, closing vlc, waiting for the sink to suspend, and trying again). The small hardware buffer size that I have (371 ms) might make noticing the delay harder, if the delay is variable, but if it's always one full hw buffer size in length, then I should be able to reliably notice it... I'll build a custom kernel next with a bigger audio buffer, and see if that changes anything.

Btw, Remi, you said that "this affects all VLC versions [...] with PulseAudio 2.x." Do you mean that this doesn't affect 3.0?

[Courmisch (courmisch)]

Did not try PA 3.x, so far not landed in Debian unstable.

[Tanu Kaskinen (tanuk)]

With bigger hw buffer I was able to reproduce the problem 100% of time on pulseaudio 2.0. With the current development version I can't reproduce the problem. Thus, resolving the bug as fixed.

[Rémi Denis-Courmont (rdenis)]

(Upstream) PulseAudio version 3.0 fixed the problem on my system, with VLC 2.0.5.

[Simplehuman (simplehuman)]

Ubuntu 13.04 PulseAudio 3.0 (today's update) . If I run VLC sound disappears completely in the system. Other players work normally. I need to restart PulseAudio to get sound back.

Workaround is like in PulseAudio 2.x - set the Alternate rate to 44100

[Simplehuman (simplehuman)]

Fix realease in the main bug-report

[Bollespiser (dundundunbolle)]

How does one apply this fix? Still bothering me in Ubuntu 13.04, latest VLC version.