> autoaudiosink appears to be completely non-configurable.

Well, its entire purpose is to try to do its best without configuration :)


> I can find no documentation on "rank" for plugins, let alone how a
> user would adjust them.

Google seems to throw up plenty of results, including our API docs. In case this was your way of asking how to do this, one would use gst_plugin_feature_set_rank() after looking up the plugin feature (element factory) from the GStreamer registry in one's application after calling gst_init() and before starting the pipeline.


> It certainly doesn't appear to try jacksink.

Ah no? It certainly does here. It might also depend on the pipeline, it will only try jackaudiosink if it looks like the caps might be compatible. Since jackaudiosink only accepts F32LE here that may not always be the case.

It may also try alsasink or other sinks before trying jackaudiosink.


> If the user has > 1 audio  interface, autoaudiosink appears to offer
> no way to be configured to use 1

As mentioned above, it's not the purpose of this element to provide a great deal of configuration options. There are other ways for applications such as the GstDeviceProvider API to find available audio output elements (although the jack plugin does not appear to support this yet).


> possibly relying on ALSA's "default" PCM name.

ALSA developers have told me this is not an unreasonable thing to rely on (if I have understood them correctly at least). What is it you would suggest here? Not use the "default" at all? Try more/other devices?

I'm not writing an application, I'm trying to get GStreamer apps to talk to JACK when JACK is running. My application doesn't use GStreamer :)

When I use it in a pipeline starting with audiotestsrc, it fails to talk to JACK. If I replace autoaudiosink with jacksink, everything works as expected. This conflicts with my mental model of what autoaudiosink should do.

But yes, the core issue that I can see is that it seems totally opaque or impossible to control the order in which autoaudiosink tests possible sinks for use. This makes it much less useful to a user, since they can't know (or change) what that order is (certainly not easily).

Yes, relying on "default" for ALSA makes a lot of sense, and on reflection, since there's no way to know that the alsasink would be the one chosen, being able to specify a device name for it is really out of scope.

Users (or app developers) shouldn't have to change the order really, it should still work.

In case there's only one audio device, can it be assumed that if jackd is running alsasink should fail to open the default device?

Well, that's precisely the sort of question that feels to me as if it needs to be configurable. 

sink-ordering = "jacksink,alsasink <args>,...."

would allow a user to control this, but still get a lot of the benefits of autoaudiosink. The answer to "the right order" isn't going to be fixed across users. 

to answer the question you asked, yes, if there is only 1 audio interface and JACK is using it, then any other attempt to use it will fail.

Having some additional API like that on auto*sink could make sense, yes. It's of limited usefulness in general though, as it would have to be set per application somehow and also playbin is not necessarily using auto*sink.

I disagree. One should never have to configure auto*sink. If more is needed the app should do something better instead like use the device probe API or allow the user to select something.

I also don't see the problem yet. It should work fine with jack too in the general. Not sure why it doesn't here.

It can't work appropriately on any system with > 1 audio interface.

Imagine that JACK runs on hw:1, while hw:0 is left available. 

If autoaudiosink probes/tests alsasink first, it will (probably) work, and end up using hw:0. 

If autoaudiosink probes/tests jacksink first, it will work, and end up using hw:1.

How can a user control which of these two outcomes is the actual one?

I guess it depends a bit on what the "auto" in "auto*sink" really means. If it means "find something that works (in the sense that there is a valid pipeline with a sink)", then fine, no configuration is necessary.

But if it means "automatically infer the right thing to do", then I think there has be an implicit sink-ordering parameter and a way to set it.

This really seems like what you want is for jacksink to be higher priority than alsasink? So if a user has JACK running, it'll always get used over talking to the ALSA device directly.

Well,that happens to be my particular need in this instance, but the problem is more general than that. Maybe the user specifically does NOT want gstreamer-based apps to talk to JACK, even when JACK is running. If the app uses autoaudiosink (which is a nice idea, since it centralizes behaviour), they also need to be able to define a priority order for potential sinks.

Then you need a platform-independent way to provide such system configuration, which doesn't really exist. A property on the element won't suffice -- properties are set by the application, not the user, and not globally.

Then how is it possible to use gconf to set parameters? Did that go away with the move from 0.10 to 1.0 ? I have the buffer-size for jacksink set via gconf, with no issues. It appears(ed?) possible to do this for all properties of any gstreamer plugin....

That's right, the gconf*sinks are gone in 1.0

(gconf is also gone, and the gnome apps using it hardcode pulseaudiosink these days)

The GSettings sinks are also gone now.

So instead of using autoaudiosink, if any control is needed then the application should use the device monitor API to select an appropriate device and configure it accordingly. Adding configuration to autoaudiosink does not seem very useful, and in the end it would be application-specific still anyway so the application could just not use autoaudiosink to begin with.