[pulseaudio-discuss] [PATCH] added two new commands to native API to control the combine sink slaves after the combine sink has been created

[Tanu Kaskinen]

On Fri, 2017-01-27 at 19:34 +0100, Steffen Pfendtner wrote:
> To catch up your points:
> 
> I will synchronise the pactl to pacmd. pulseaudio-dlna is using pactl
> too. I just missed that point.
> 
> I share your view regarding the location of the new functions. A new
> file set src/pulsecore/combine-sink.[ch] is a good idea to remove this
> from the standard sink stuff.

It's not clear to me if you're planning to make a protocol extension,
or put this stuff in the core protocol. If it's going to be an
extension, then there's no need for pulsecore/combine-sink.[ch].
module-combine-sink will use pa_native_protocol_install_ext() to set a
callback for receiving the messages from clients.

> Regarding multiple instances of module combine sink.
> I though I've added the instance id of the combine module to the API.

By "the instance id of the combine module", do you mean the sink name?
Or the module index? I don't think the module index needs to be part of
the API.

> This way the user or an external application can address which of the
> instances he would like to modify or query.
> This way no central management inside pulseaudio over all sinks on all
> combined sinks is needed. In this way the patch is as essential as it
> can be. You can even add a sink to two different combine sinks or a
> combine sink as input sink to another one if you like to. 
> 
> If the module combine is not loaded and you call the API functions they
> will simply return an error. If you unload the module while its running
> it is part of the module instance to clean up on exit. 
> Simple and stupid and not as complex as some dynamic API stuff.

If an application wants to keep track of what combine sinks exist, how
do you plan to support that without a central management API? Is the
application expected to get a list of all sinks and filter based on
which module owns the sink? The problem with that is that I dislike the
idea of mandating that every combine sink has to have a module-combine-
sink instance associated with it.

I've been involved with a project that made a routing module that
automatically created combine sinks, and having to deal with the module
layer was an extra pain that could have been avoided if there was a way
to create combine sinks without having to load a module every time. I
think that project is dead now (I'm certainly not involved any more),
but I wouldn't be surprised if something similar will be created in the
future. That's why I don't want the API to assume that there will be
always a module-combine-sink instance associated with a combine sink.

-- 
Tanu

https://www.patreon.com/tanuk