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).
*** Bug 525862 has been marked as a duplicate of this bug. ***
If it happens with mplayer, then it's certainly not a GStreamer problem. Probably a PulseAudio or ALSA PulseAudio plugin problem.
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.
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
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
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
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.
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?
Created attachment 364832 [details] output of pacmd ls
Created attachment 364833 [details] output of cat /proc/asound/*/pcm*p/sub*/*
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.
(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.
Created attachment 365052 [details] "pacmd ls" while video is playing in totem
Created attachment 365053 [details] "cat /proc/asound/*/pcm*p/sub*/*" while video is playing in totem
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.
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.
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
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.
removed needinfo flag to stop e-mails to my inbox