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
