It would make JACK be automatically started, which might not be the desired effect if the user is running another sound server. Generally the audio sinks/sources are not automatically starting any sound servers, so that they are only selected if the user actually wants to run that specific one.

Yes, we don't autostart sound daemons as a matter of policy.

Sebastian: This may always be the case, of course. It is not specific to gstreamer in that sense. In any case, autostarting can always be prevented by either configuration (jackdrc) or environment (JACK_NO_START_SERVER) whereas "not autostarting" being enforced by JackNoStartServer in the source can unfortunally not be compensated for. I think it would be good if the choice could be given to the user. If I recall correctly, it is even so that currently the client library does not start jackd unless JACK_START_SERVER is set (without JackNoStartServer).

Not sure for the policy, but GStreamer can cause daemon to start wherever dbus is used. It is the case for pulse audio as an example. I'm sure though the implemented method is there so pulse and Jack can cohabit.

I would add a new property here.

I'm not sure dbus is an appropriate substitute for the jack client library autostart mechanism here. dbus autostart services are "available on request" because they *are* dbus mediated services and the starting can be performed "transparently" to the requesting client. This is not the case for Jack, as far as I can see.

As for the policy, if I understand correctly what you mean: I think it can be expected that if the pipeline contains a Ysink (for audio or video alike), then it will be correct to assume that the associated "backend" Y (if any) necessarily has to run. Very much because the case where the sink is backed by a daemon which can started or not is just a special case. If there is a sink for Y in the pipeline (like alsa, jack or X video), then it is to be assumed that Y is in a working state (i.e.: if there is a daemon, it is running). If, for some reason or another, various sinks cannot coexist, it is the responsiblity of the user not to create them in the first place.

So in summary I think this is WONTFIX from our side, but we would accept a property that would allow applications that want this behaviour to change it.

Please let us know if you intend to make a patch for that or not.

I don't think that property is a good idea either.

Forking inside the plugin caused some nightmares to me. Some nice deadlocks with a misconfigured server that was running an application with CEF/tcmalloc and playing sounds with GStreamer that was spawning pulse server from the audio sink.

I think forking to a new process (with exec) will not bear the risk of introducing any such issues which you encountered elsewhere. Any multithreaded application whatsoever should be able to just spawn a child - regardless of threading.

This is a WONTFIX from our side, sorry.

Audio servers should be started by the session or application if needed.