After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 517185 - queue not emptied
queue not emptied
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-omx
0.10.0
Other Linux
: Normal normal
: 0.10.1
Assigned To: Felipe Contreras (banned)
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-02-18 10:39 UTC by Frederik
Modified: 2008-05-21 22:57 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Frederik 2008-02-18 10:39:54 UTC
When using the gst-openmax plugins with totem/gstreamer, totem crashes (segmentation fault) when jumping to the next song. 
This happens because in the audio renderer, the buffers that are freed are still in the queue (which is reused for the next song).
Comment 1 Felipe Contreras (banned) 2008-02-18 11:38:45 UTC
By audio renderer you mean gst-openmax's audiosink or Bellagio's ALSA sink component?
Comment 2 Frederik 2008-02-18 12:28:59 UTC
The gst-openmax's audiosink.
Comment 3 Frederik 2008-02-18 13:03:41 UTC
Hello Felipe,

It seems that in between songs, totem removes the gst-openmax mp3 decoder from the element chain, causing it to execute its dispose function, so when it gets attached again later (if next song is also an mp3) it gets freshly initialised.

This does not seem to be the case for the gst-openmax's audiosink however. 
It will get its buffers freed in g_omx_core_finish, but the port's queue might still contain pointers to these buffers so that the gst-openmax's audiosink will try to use those freed buffers when playing the next song.

emptying the port queue in g_omx_core_finish fixes this problem for me, although I'm getting OMX buffer underuns from the next song unwards.
Comment 4 Felipe Contreras (banned) 2008-02-18 13:47:06 UTC
Hmm, indeed the ports should be freed in g_omx_core_finish. What is the error message you get from the OpenMAX component?

Right now I'm not able to test the Bellagio's ALSA sink.
Comment 5 Frederik 2008-02-18 14:02:26 UTC
for the underrun I'm getting "OMX-ALSA Underrun.."

For the crash it showed "  WARNING: unhandled setup"
Comment 6 Felipe Contreras (banned) 2008-02-28 17:36:18 UTC
I just committed a couple of changes that should improve the situation when
seeking, but it's not perfect.

I also have issues when starting the playback.

Please verify.
Comment 7 Frederik 2008-03-04 08:20:27 UTC
Hi Felipe,

I just tried your changes, but still get the same underruns

For me, depending on the song, starting the playback can generate an 'OMX_ALSA Underrun..' or 3 when starting the song, but it runs fine afterwards.

When switching songs (I use the same song as next/previous song), I get 19/20 times continious buffer underruns. (although sometimes (1/20 chance) after a dozen times of song switching the next song is suddenly played without buffer underruns again).
Comment 8 Felipe Contreras (banned) 2008-05-19 17:11:12 UTC
I'm going to close this bug as the queue is now emptied.

Please fill another one if you still have the ALSA issues.