Bug 523066 - Video playback lags at first, then speeds up incredibly until it catches up, then plays normally.
Summary: Video playback lags at first, then speeds up incredibly until it catches up, ...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: pulseaudio
Version: 11
Hardware: All
OS: Linux
low
high
Target Milestone: ---
Assignee: Lennart Poettering
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 525862 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-09-13 21:02 UTC by Stephan Klein
Modified: 2014-06-24 10:14 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-06-28 14:38:12 UTC


Attachments (Terms of Use)
demonstration of the problem via recordmydesktop (4.99 MB, video/ogg)
2009-09-13 21:02 UTC, Stephan Klein
no flags Details
output of pacmd ls (11.79 KB, text/plain)
2009-10-14 22:52 UTC, Stephan Klein
no flags Details
output of cat /proc/asound/*/pcm*p/sub*/* (824 bytes, text/plain)
2009-10-14 22:53 UTC, Stephan Klein
no flags Details
"pacmd ls" while video is playing in totem (14.55 KB, text/plain)
2009-10-16 14:36 UTC, Stephan Klein
no flags Details
"cat /proc/asound/*/pcm*p/sub*/*" while video is playing in totem (1.69 KB, text/plain)
2009-10-16 14:37 UTC, Stephan Klein
no flags Details

Description Stephan Klein 2009-09-13 21:02:53 UTC
Created attachment 360855 [details]
demonstration of the problem via recordmydesktop

I am reporting this against gstreamer, but it may very very well be an issue with the graphics hardware.

Description of problem:
Please watch the attached video which demonstrates the problem.
Whenever I start playing a video file (does not matter which one or which codec combination) with totem, mplayer or even while playing flash videos (YouTube, CollegeHumor, ...)) the audio plays fine, but the video lags behind for the first couple of seconds. After that it speeds up enormously until it catches up with the audio. From that point on, the video and audio play normally and in perfect sync.
When I jump back to the beginning of the video or to any other point in the video this lag does no happen. It only happens when I start the application that is supposed to play the video file.


Version-Release number of selected component (if applicable):
- GStreamer 0.10.24
- 01:00.0 VGA compatible controller: nVidia Corporation G72M [GeForce Go 7400] (rev a1)
- using the binary nvidia driver (version 185.18.36)
- error occurs in everything gstreamer-based (miro, totem)
- i've made similar observations in vlc

How reproducible:


Steps to Reproduce:
1. Open any given video file.
2. Observe the results.

Actual results:
The problem occurs.

Expected results:
The video should play smoothly from the beginning.

Additional info:
The video file used in the attached demonstration can be downloaded at http://tr.im/yBdW (from YouTube).

Comment 1 Bastien Nocera 2009-10-07 11:04:24 UTC
*** Bug 525862 has been marked as a duplicate of this bug. ***

Comment 2 Bastien Nocera 2009-10-08 16:07:22 UTC
If it happens with mplayer, then it's certainly not a GStreamer problem. Probably a PulseAudio or ALSA PulseAudio plugin problem.

Comment 3 Lennart Poettering 2009-10-09 08:29:35 UTC
which audio driver is this? this really sounds as if the sampling freq reported by the driver is really different from what we actually measure with the system clock.

Comment 4 Nicolas Mailhot 2009-10-09 19:04:48 UTC
In bug #525862 it's

06:00.0 Multimedia audio controller: Creative Labs SB Audigy (rev 03)
        Subsystem: Creative Labs E-MU 1010
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 32 (500ns min, 5000ns max)
        Interrupt: pin A routed to IRQ 20
        Region 0: I/O ports at d000 [size=32]
        Kernel driver in use: EMU10K1_Audigy
        Kernel modules: snd-emu10k1

and

06:01.0 Multimedia video controller: Internext Compression Inc iTVC16 (CX23416) 
MPEG-2 Encoder (rev 01)
        Subsystem: Hauppauge computer works Inc. WinTV PVR 150
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step
ping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort
- <MAbort- >SERR- <PERR- INTx-
        Latency: 64 (32000ns min, 2000ns max), Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 19
        Region 0: Memory at e4000000 (32-bit, prefetchable) [size=64M]
        Kernel driver in use: ivtv
        Kernel modules: ivt

Comment 5 Stephan Klein 2009-10-11 19:41:25 UTC
I am the original reporter:

00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01)
	Subsystem: Hewlett-Packard Company Device 30a5
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 22
	Region 0: Memory at d2400000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [60] MSI: Enable- Count=1/1 Maskable- 64bit+
		Address: 0000000000000000  Data: 0000
	Capabilities: [70] Express (v1) Root Complex Integrated Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
			ExtTag- RBE- FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
		LnkCap:	Port #0, Speed unknown, Width x0, ASPM unknown, Latency L0 <64ns, L1 <1us
			ClockPM- Surprise- LLActRep- BwNot-
		LnkCtl:	ASPM Disabled; Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed unknown, Width x0, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-
	Capabilities: [100] Virtual Channel <?>
	Capabilities: [130] Root Complex Link <?>
	Kernel driver in use: HDA Intel
	Kernel modules: snd-hda-intel


Installed packages:

$ rpm -qa | egrep "(pulseaudio|alsa)"
pulseaudio-libs-zeroconf-0.9.15-17.fc11.i586
pulseaudio-libs-devel-0.9.15-17.fc11.i586
alsa-plugins-pulseaudio-1.0.21-2.fc11.i586
pulseaudio-libs-0.9.15-17.fc11.i586
alsa-lib-1.0.21-3.fc11.i586
wine-pulseaudio-1.1.29-3.fc11.i586
pulseaudio-libs-glib2-0.9.15-17.fc11.i586
pulseaudio-module-x11-0.9.15-17.fc11.i586
pulseaudio-0.9.15-17.fc11.i586
pulseaudio-utils-0.9.15-17.fc11.i586
bluez-alsa-4.42-6.fc11.i586
pulseaudio-module-gconf-0.9.15-17.fc11.i586
pulseaudio-module-bluetooth-0.9.15-17.fc11.i586
alsa-utils-1.0.21-2.fc11.i586

Comment 6 Espen Stefansen 2009-10-11 20:43:04 UTC
I'm running the latest rawhide and this happens to me too. 

00:1e.2 Multimedia audio controller: Intel Corporation 82801G (ICH7 Family) AC'97 Audio Controller (rev 01)
	Subsystem: Dell OptiPlex GX620
	Flags: bus master, medium devsel, latency 0, IRQ 23
	I/O ports at ec00 [size=256]
	I/O ports at e8c0 [size=64]
	Memory at febffa00 (32-bit, non-prefetchable) [size=512]
	Memory at febff900 (32-bit, non-prefetchable) [size=256]
	Capabilities: [50] Power Management version 2
	Kernel driver in use: Intel ICH
	Kernel modules: snd-intel8x0

Comment 7 Lennart Poettering 2009-10-14 21:50:56 UTC
Almost certainly a problem with the timing information we get from the driver. i.e. driver says it can do 44khz but actually does 48khz or so, and our timing interpolation has trouble adjusting to that big deviation.

Comment 8 Lennart Poettering 2009-10-14 22:19:38 UTC
Hmm, could you check if /proc/asound/*/pcm*p/sub*/* matches what "pacmd ls" says in regards to sampling rates?

If this matches up and you play a 44khz sound, is it possible that the pitch is noticably off, as if it was actually played in 48khz? or vice versa? Could you do a listening test on another machine that does not have the problem and compare the pitch of the same sound file played on both?

Comment 9 Stephan Klein 2009-10-14 22:52:45 UTC
Created attachment 364832 [details]
output of pacmd ls

Comment 10 Stephan Klein 2009-10-14 22:53:56 UTC
Created attachment 364833 [details]
output of cat /proc/asound/*/pcm*p/sub*/*

Comment 11 Stephan Klein 2009-10-14 22:56:24 UTC
As far as I can tell, pacmd reports a sample rate of 48khz. The second command does not contain the number "48" anywhere.
I will do the listening test tomorrow, but as I wrote in the original report. The sound does not seem to be noticably off. There could be a very small change in pitch for maybe a millisecond or so. But the main problem is that the video output does not display smoothly.

Comment 12 Lennart Poettering 2009-10-15 22:06:43 UTC
(In reply to comment #11)
> As far as I can tell, pacmd reports a sample rate of 48khz. The second command
> does not contain the number "48" anywhere.

You need to run both commands while you are actually playing the video.

Comment 13 Stephan Klein 2009-10-16 14:36:22 UTC
Created attachment 365052 [details]
"pacmd ls" while video is playing in totem

Comment 14 Stephan Klein 2009-10-16 14:37:15 UTC
Created attachment 365053 [details]
"cat /proc/asound/*/pcm*p/sub*/*" while video is playing in totem

Comment 15 Lennart Poettering 2009-10-27 03:06:18 UTC
So it seems as if both PA and ALSA think they are configured to 48000hz. which is good. 

Hmm, this is F11, right? Could you by any chance check if this is broken on F12 too? (i.e. try out the livecd of the beta?) we recently had some changes that should make timing more stable early during playback, but normally timing should never have been so unstable that it you could see it.

Comment 16 David Timms 2009-11-04 13:47:32 UTC
Just as a me too for eg mplayer playing mpeg2 dvb broadcast recordings. This might be only since the last month or so, but I considered it was more likely a change in mplayer.

Comment 17 Bug Zapper 2010-04-28 10:20:24 UTC
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 18 Bug Zapper 2010-06-28 14:38:12 UTC
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 19 Stephan Klein 2014-06-24 10:14:48 UTC
removed needinfo flag to stop e-mails to my inbox


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