By audio renderer you mean gst-openmax's audiosink or Bellagio's ALSA sink component?

The gst-openmax's audiosink.

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.

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.

for the underrun I'm getting "OMX-ALSA Underrun.."

For the crash it showed "  WARNING: unhandled setup"

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.

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).

I'm going to close this bug as the queue is now emptied.

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