[pulseaudio-discuss] Moving sources and sinks

[Tanu Kaskinen]

On Sat, May 03, 2008 at 04:48:05PM -0700, Nick Thompson wrote:
> Given what you say (above) about per device routing not being possible I 
> think the area I'd like to concentrate on is figuring out how a module 
> can detect streams as they are being created.  That way it could get the 
> call in to switch sink input before the stream is started.  So figuring 
> this out would be a great start.

This is how I think it might work:

1. Register yourself to listen to new sink input events. The
pa_core structure (core.h) has an array of hooks, each
corresponding to one type of event. The following will do
the registration:

pa_hook_connect(core->hooks[PA_CORE_HOOK_SINK_INPUT_NEW],
                my_callback,
                my_userdata);

There the "core" variable is a pointer to pa_core.
my_callback is a function that gets called when the event
happens, and my_userdata is pointer to any data you want the
callback function to have access to.

2. Change the destination sink. The callback gets as
parameters a pointer to pa_core, a pointer to
pa_sink_input_new_data, and the userdata pointer you gave in
the registration function. pa_sink_input_new_data has the
field "sink", which you can set in the callback to be the
sink you want the sink input to connect to.

This probably conflicts at least with module-volume-restore,
which uses the same hook and does sink redirection too.

> I've been looking at a client app (it is, I think necessary to have one 
> to relay policy info about routings to the module), but I don't think 
> stream routing via a client would be a good way to address the issue.  
> There is likely to be a fair lag between a stream being created, a 
> notification being received that the stream has been created, to 
> communication to the client, and the communication back to the client to 
> switch a sink input.  There doesn't appear to be a means to do most of 
> this from a command line, and its not clear to me how the ipc mechanism 
> between the client and the daemon can be exploited to this end.

You could still do the tracking based on which null sink the
stream tries to connect to. Otherwise, if you decide to
manage the routing information in a separate program, I
don't think you can use the client API in any way, so you'll
have to use some other ipc solution.

-- 
Tanu Kaskinen