GNOME Bugzilla – Bug 602716
CRITICAL **: gst_alsa_mixer_element_list_tracks: assertion `this->mixer != NULL' failed
Last modified: 2009-11-25 20:01:12 UTC
The following code snippet leads to an assertion CRITICAL **: gst_alsa_mixer_element_list_tracks: assertion `this->mixer != NULL' failed #include <gstreamermm/init.h> #include <gstreamermm/alsamixer.h> int main (int argc, char *argv[]) { Gst::init(argc, argv); Glib::RefPtr<Gst::Mixer> mixer = Gst::AlsaMixer::create("mixer"); assert(mixer); typedef std::list<Glib::RefPtr<Gst::MixerTrack> > tracks_type; tracks_type tracks = mixer->list_tracks(); }
I found the following post in the gstreamer-devel mailing list: http://marc.info/?l=gstreamer-devel&m=115381783205196&w=2 Could you follow the suggestion in the post and see if it makes any difference for you? This may not be a bug after all.
This helps indeed. I'd still call it a bug though :p... in the documentation (or lack thereof). There are no examples and no docs :( It is still not clear to me if I should do: Glib::RefPtr<Gst::Mixer> mixer = Gst::AlsaMixer::create("mixer"); or Glib::RefPtr<Gst::AlsaMixer> mixer = Gst::AlsaMixer::create("mixer"); The latter doesn't seem as portable (some OS might not be able to use AlsaMixer). Strangely enough, you can't use Gst::Mixer to set the element to ready though... So now I have to do: Glib::RefPtr<Gst::AlsaMixer> alsa_mixer = Gst::AlsaMixer::create("mixer"); Glib::RefPtr<Gst::Mixer> mixer = alsa_mixer; alsa_mixer->set_state(Gst::STATE_READY); as mixer->set_state doesn't work... That is kinda counter intuitive (seems non-Object Oriented). I ran into an additional problem, but I'll mail the list about that.
(In reply to comment #2) > This helps indeed. I'd still call it a bug though :p... in the documentation > (or lack thereof). There are no examples and no docs :( gstreamermm simply wraps the C API. The reason you were getting the error is that the GStreamer internals require that an element be in either a paused or ready state before being able to get at the interface it may or may not implement. For documentation I would refer you to the GStreamer Application Development Manual[1] because it is so good at explaining how things work. Unfortunately, this bit of information is not mentioned in the "Interfaces" section. The GStreamer developers do answer these questions on their devel list[2], but there probably should be a mention of this somewhere in their docs so it is not so difficult to know how to use interfaces like Gst::Mixer. I've filed a bug[3] about that. [1] http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/index.html [2] http://gstreamer.freedesktop.org/lists/ [3] https://bugzilla.gnome.org/show_bug.cgi?id=602877 > It is still not clear to me if I should do: > > Glib::RefPtr<Gst::Mixer> mixer = Gst::AlsaMixer::create("mixer"); > > or > > Glib::RefPtr<Gst::AlsaMixer> mixer = Gst::AlsaMixer::create("mixer"); > > The latter doesn't seem as portable (some OS might not be able to > use AlsaMixer). Strangely enough, you can't use Gst::Mixer to set > the element to ready though... So now I have to do: > > > Glib::RefPtr<Gst::AlsaMixer> alsa_mixer = Gst::AlsaMixer::create("mixer"); > Glib::RefPtr<Gst::Mixer> mixer = alsa_mixer; > alsa_mixer->set_state(Gst::STATE_READY); > > as mixer->set_state doesn't work... That is kinda counter intuitive (seems > non-Object Oriented). Using Gst::AlsaMixer directly is best because it inherits from Gst::Element and allows using the Gst::Element::set_state() method to avoid the error you've encountered. Gst::Mixer is an interface and does not inherit from Gst::Element. That's why it's not possible to change the state of a plug-in through that interface. As far as portability, if the header is included, the Gst::AlsaMixer (and other plug-in classes) can be included in code regardless of platform. It is necessary, however, to surround the relevant code with #ifdefs to make sure that a plug-in that does not exist is not used on that platform. > I ran into an additional problem, but I'll mail the list about that.
Closing as the GStreamer docs now include a comment about avoiding this error.