[pulseaudio-discuss] Moving sources and sinks

[Nick Thompson]

Thank you, Tanu.

I'll take a look at this way.  No doubt I'll have lots of questions  
once I get into it.

Regards

Nick

On May 4, 2008, at 4:15 AM, Tanu Kaskinen wrote:

> 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
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss