[pulseaudio-discuss] Mixing audio from multiple sink-inputs to multiple sinks dynamically

[Tanu Kaskinen]

On Wed, 2016-04-06 at 20:50 +0200, Lode Cools wrote:
> On Wed, Apr 6, 2016 at 1:39 PM, Tanu Kaskinen <tanuk at iki.fi> wrote:
> > On Tue, 2016-04-05 at 15:13 +0200, Lode Cools wrote:
> > > Ideally, there would be a solution where you could change the slaves of a
> > > combine-sink dynamically.  But, afaik, this does not exist and is not
> > > planned either.
> > 
> > It may not be planned, but patches implementing dynamic combine sink
> > slave management would definitely be welcome.
> > 
> > module-combine-sink already supports dynamic slave changes internally,
> > because it has a mode where it plays to all sinks in the system, and
> > that requires automatically adding and removing outputs as sinks come
> > and go.
> 
> OK. Understood.  If it starts to become relevant for my intended
> application, I will implement this.  How would the API look like?  Is
> it enough to just catch changes on the sinks property list?

A requirement is that a client can change the outputs of a combine sink
at runtime, right? Clients can't modify the sink property lists, and
I'd like to keep it that way, so using just property lists doesn't seem
like a viable approach. (I also don't like the general approach of
using property lists as an API, even though often it's the easiest way
to get something done.)

I would suggest adding a protocol extension with associated functions
in libpulse. We currently have three protocol extensions, see the ext-
*.h pages listed here (or have a look at the source code):
https://freedesktop.org/software/pulseaudio/doxygen/files.html

The existing extensions can be used as examples of how protocol
extensions can be implemented, although they aren't very good examples
of API design, IMHO: when any changes happen in the state, the
extensions just send a "something happened" event and then you're
supposed to read the full database and figure out what changed. Also,
there's no notification when the extension becomes unavailable (i.e.
when the implementing module gets unloaded). I'd hope that you don't
copy those features.

Once upon a time, I wrote another extension for Tizen, which I think is
a better source for copying:
https://github.com/otcshare/pulseaudio/blob/tizen/src/pulse/ext-volume-api.h

The libpulse functions could have prefix "pa_ext_combine_manager". At
the server side a new module could be added, module-combine-manager,
that implements the protocol extension. A new module isn't strictly
necessary, though, if it's ok that the protocol extension is not
available when there are no module-combine-sink instances loaded. In
any case, this requires coordination between multiple module instances,
and it tends to be unobvious to people how that can be implemented, but
I can explain more about that if this project proceeds that far.

The API should have functions for querying the list of existing combine
sinks and their state (the active and configured outputs), for
configuring the combine sink outputs, and for getting notifications of
changes in the combine sink states. And a way to get a notification
when the protocol extension becomes unavailable.

Feel free to ask any further questions here on the mailing list or in
IRC.

-- 
Tanu