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. Regarding multiple instances of module combine sink. I though I've added the instance id of the combine module to 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. On Thu, 2017-01-12 at 03:56 +0200 Tanu Kaskinen wrote: > On Wed, 2017-01-11 at 17:44 +0530, Arun Raghavan wrote: > > On Wed, 11 Jan 2017, at 03:45 AM, Tanu Kaskinen wrote: > > > Thanks for the patch! > > > > > > On Thu, 2017-01-05 at 20:13 +0100, Steffen Pfendtner wrote: > > > > Subject: [PATCH] added two new commands to native API to control the combine sink slaves after the combine sink has been created > > > > > > There's a misunderstanding: you edited the command line interface, not > > > the native protocol. Applications use libpulse, which implements the > > > native protocol, so that's where the client interface should be added. > > > The command line interface is used by pacmd and the startup script > > > interpreter. If you already integrated this feature in pulseaudio-dlna, > > > I guess you run pacmd commands from pulseaudio-dlna? > > > > > > We have two similar tools: pacmd and pactl. Unlike pacmd, pactl is a > > > regular client that uses libpulse to interact with the server. It's > > > pretty pointless to have two tools that do the same thing, so I hope we > > > can get rid of pacmd some day. pacmd doesn't work over the network, and > > > also doesn't work when pulseaudio runs in the system mode. > > > > > > You can add this functionality in the command line interface if you > > > really want to, but if you do that, you have to add it to pactl as > > > well, because I don't want new features in pacmd that are not supported > > > by pactl. Adding the functionality to pactl is highly desirable even if > > > you don't add the functionality to the command line interface, though. > > > > > > Assuming that the API is added to the "core" instead as a protocol > > > extension (see my previous mails: [1][2][3]), you'll need to add new > > > commands that are sent from src/pulse/introspect.c and handled in > > > src/pulsecore/protocol-native.c. I would suggest adding > > > src/pulsecore/combine-sink.[ch] that has pa_combine_sink_add_output() > > > and pa_combine_sink_remove_output() along with anything else protocol- > > > native.c needs for dealing with the new commands. The API shouldn't be > > > in sink.h, because that's for common sink functionality, while this API > > > is only for one specific sink implementation. > > > > First, to make this concrete. module-combine currently allows multiple > > instances, so I guess we would either need to change it to allow a > > single instance, or add a module-combine-manager module to implement the > > extension API. I prefer the former. > > Presumably you'd then add some new argument to module-combine-sink to > signal that it should run in the "manager mode"? If we are going the > extension route, I would prefer a separate manager module, but I don't > care about that detail very much. > > > While I'm not entirely against the idea of having this in core, I look > > at this in terms of what do we gain, and what do we lose. If we were to > > make this API core: > > > > 1. We gain a little bit by not jumping through the extension API hoops > > In my opinion avoiding the extension API hoops is a pretty big > advantage. Normally an extension can disappear at any time, because the > module can be unloaded. Do you think this should also be the case for > the combine-manager API? If the extension can be or become unavailable, > that will inherently make the API more complex. > > One option would be to implement some kind of transparent on-demand > loading of the manager module, and prevent it from being unloaded while > there are clients using it. That would still require applications to > register themselves as users of the API, which could be avoided if the > API was always available. > > > 2. We lose a little flexibility, because IMO the core API is more of a > > commitment for us than an extension API (we would still want to be very > > very reluctant to ever break it) > > I don't think there's any real difference in commitment. An API break > is an API break, the effects are the same regardless of whether the API > is labeled as "core" or "extension". > > > 3. We lose a little more flexibility because combine becomes THE way to > > group outputs in the core API, or we have API duplication if we revisit > > other mechanisms (such as the node routing layer) > > I don't have high hopes for the new routing layer being resurrected > anytime soon, but even if it will be, it will anyway duplicate all > existing routing APIs, so I don't feel it's that bad adding another bit > of routing APIs that might get duplicated by the new layer. > > > There are minor concerns around what happens if-module-combine-sink > > isn't available for some reason in both cases, but that's not something > > that would swing my opinion either way. > > I'm not sure what you mean by "not available". Do you mean that the > module is not installed, or not loaded? If you mean not installed, I > think that case is safe to ignore. If a distribution doesn't install > module-combine-sink along with the main pulseaudio package, that's > their fault. I don't think we need to support that. > > > Given this, I lean towards having an extension API. If you have strong > > reasons to prefer the core API, I'm still quite open to being convinced. > > :) > > My "strong reasons" boil down to avoiding unnecessary complexity in the > client API. Having the API in the core should also make the > implementation quite a bit simpler, but that carries less weight in my > consideration. >
