Backend with gstreamer src that uridecodebin can't find?

I’m moving from mpd to mopidy and am looking for 1:1 replacements for local sources. In mpd I can access my CD player via the cdda:// protocol and capture input from a sound card (my turntable with USB) via the alsa:// protocol.

Gstreamer supports both via cdiocddasrc and alsasrc, respectively. So all good on that front.

However, scoping the code, I think every backend I’ve seen relies on uridecodebin. That’s fine for CDs, because cdiocddasrc implements a URI handler, but alsasrc does not.

I’m down to make a custom backend but I’m hoping some expert might suggest what would be needed for a backend wrapping alsasrc.

By “custom backend”, are you talking about a custom gstreamer source element? Or a Mopidy Backend? Assuming the former, I think wrapping alsasrc with something that providers GstURIHandler is the best bet. You can do it in c, rust, or python. Python will be the easiest to distribute (if that’s interesting) but sometimes the python bindings are randomly missing parts of the API, I think that’s because it’s not well utilised. I’m not sure myself how you practically do it though. Presumably you can’t just extend alsasrc, so you have to extend GstAudioSrc and do some low-level stuff (see)? Or can you just extend a Gst.Bin, instantiate an alsasrc in there, and then wire it up to the pads? You might be able to find better help at https://discourse.gstreamer.org/

I was thinking about a Mopidy Backend, but I think your response might have confirmed my suspicion that it’s not really possible with the existing architecture. I did a little more poking around in the source code and it seems everything is run through playbin. So, if playbin can’t handle it, neither can Mopidy.

Which brings us to the solution that you, @kingosticks, suggested. Basically make a gstreamer plugin that does the job.

In that case, I’m inclined to first pursue a patch to alsasrc directly to get it to handle URIs. That seems like the “right” solution, given that it looks like an oversight that it doesn’t already handle it. One piece of evidence for that is that, IIRC, the author of playbin is also the author of alsasrc.

Of course, the other possible solution, as you suggest, is to create a src plugin that is a lightweight wrapper around alsasrc. That might be easier to do.

I’ll report back if I make any further headway here. Meanwhile, I’d certainly like to hear from others with more expertise than I (which is basically any, really) about my prospects.

Mopidy used to support an alternate pipeline for use with Spotify audio but since we no longer need that it was removed since it added a lot of complexity.

Again, I think you’ll find good advice on the gstreamer forums with which direction to take. I’m also curious why they didn’t add URIHandler support to alsasrc (and the like).

I’m in the process of trying to fix that: Draft: alsasrc, alsasink: add URI handling (RFC) (!7551) · Merge requests · GStreamer / gstreamer · GitLab

The only other issue with enhancing alasrc, is that you won’t see the efforts available in Debian stuff for years. Unless you a) don’t care b) redistribute just that plugin yourself.

Well, I’m running Mopidy on a raspberry pi with NixOS, so I can get the desired result pretty much immediately. :wink: