I’m writing a little program in Python to play audio CDs (CDDA) on my computer using gstreamer.
I’ve got something that works, but I’m wondering if there is a better way to do it.
In order to receive information about what’s going on with the CDDA, the program needs to listen for messages, especially message::tag to know what track is being played and message::eos to know when the track is finished.
Right now, I’m using GLib.Mainloop in a separate thread to listen to these, but I was wondering if it was the best thing to do.
In addition, at some point, I’d like to add a very simple UI using GTK, which also has its own event/signal handling, so I was wondering if there was a “centralized” way to handle gstreamer messages and GTK signals.
I’m also new here so caveat emptor , but whats your reason for starting a new thread to call loop.run? I think you should be good to call it directly in your main thread.
GTK uses the GLib main loop as well, so you can use bus.add_signal_watch() with a GTK main loop as well, and then both the gstreamer bus messages and GTK events will be processed in the main thread using the same event loop.
If I run loop.run() in the main thread, well, the loop runs so the execution is blocked, waiting for things to happen. But I would like to be able to issue commands (like next or previous to switch CDDA tracks, etc.).
Thanks! Currently, I’m using pyglet to display things on the screen, but as I said in my previous message I’m thinking of switching to GTK as it would probably be a bit easier to do what I want to do with it.
However, just out of curiosity, if I was to stick to pyglet, how could I do, given that it doesn’t interact with gstreamer the same way GTK does?
There’s no obligation to use or run a GLib main loop for what it’s worth.
The GstBus watch API that integrates with that is just provided for convenience.
You can handle bus messages differently. Can’t really make any concrete suggestions because I am not familiar with pyglet, but if it runs a different kind of event loop you could e.g. set up a time that pops messages off the bus every X milliseconds, or (better) you add a bus sync handler (which would be called from the thread that posts the message(s)) that wakes up your alternative main loop somehow and triggers a callback in the event loop thread.
, but whats your reason for starting a new thread to call