GNOME Bugzilla – Bug 159318
[alsasink/opt] Time presentation is a few seconds off for mp3 in combination with alsasink
Last modified: 2005-11-11 16:36:55 UTC
Seekbar do not follow sound properly and at EOS the terminal is spewed with: ** (totem:27446): WARNING **: could not link audio/x-raw-int, endianness=(int)1234, signed=(boolean)true, width=(int)16, depth=(int)16, rate=(int){ 8000, 11025, 12000, 16000, 22050, 24000, 32000, 44100, 48000 }, channels=(int)[ 1, 2 ]
The warning is a dup of #159269 and is fixed. The time: I'm unsure. The pipeline is as simple as mad ! audioconvert ! audioscale ! volume ! alsasink. Mad handles the queries correctly. It returns values as it pushes data out. However, this data doesn't ever arrive at alsasink, even though the clock is already ticking (up to 6 seconds for benow.mp3) and mad has pushed those samples out. So it's lagging somewhere in between, I don't know where. Audioconvert uses a standard chain function, same for audioscale/volume. I don't know where it is in between, because if I understand scheduling correctly, then the chain functions call each other, and alsasink (loop-based) is in-the-lead. However, and this is important, I don't see this when using (chain-based) osssink as audio output. Wim, can you tell me what's going on in between?
*** Bug 158724 has been marked as a duplicate of this bug. ***
Seems better for me now. On first playback the streambar jumps a little in the begining in Totem, but on second run in repeat mode it seems to behave 100% correct.
*** Bug 160804 has been marked as a duplicate of this bug. ***
I can no longer reproduce this. I have probably accidently fixed it. Please confirm.
Closing. Please reopen if it's still an issue.