5 ms·
- A stream is something you can play as a sound. It may be loaded from a file or generated on the fly. It may be finite or infinite. One important thing is that
by qalmakka 4y ago
- A stream is something you can play as a sound. It may be loaded from a file or generated on the fly. It may be finite or infinite. One important thing is that a stream is single-shot: it doesn’t have a restart method or anything like that.
- A channel is something where a stream is actually played. You can request the channel to stop, or you can replace the stream this channel is playing.
Am I mistaken, or isn't this very close to what GStreamer already does with sinks and sources?
- lisyarus 4y agoIt pretty much may be!
- tonyarkles 4y agoYeah, very similar model for sure. I say this having used GStreamer in anger though: the complexity of Glib and GObject makes OP’s API quite a bit nicer to use. There are tradeoffs though; while GStreamer is complex and error-prone, it does have two big pieces that OP’s approach doesn’t: - metadata in the streams. GStreamer streams have rich data attached to them that allows both sides of the chain to automatically negotiate the specific format and properties of the data in the stream. - introspection. Given an opaque/genetic GObject pointer to an element in the processing graph, you can query its configuration and sources/sinks without knowing what the object is up front. This ultimately can allow you to walk the entire graph if you want and inspect all of the elements.
- qalmakka 4y ago> the complexity of Glib and GObject makes OP’s API quite a bit nicer to use Yeah, Glib and GObject are a massive PITA, thankfully both have C++ bindings and can be used from Vala, so it's not that bad in practice. The C API is a nightmare though.
- lisyarus 4y agoTrue! But also my use case it quite different compared to GStreamer, and I don't really need all that metadata & introspection.