Hiya Harry, 'Twas brillig, and Harry Van Haaren at 21/06/11 11:31 did gyre and gimble: > I'm working on an applet that will inform the user when streams have > been swapped to a newly plugged in device. > The problem that I'm facing is that I don't know what angle to approach > the problem from. Ahh nice. I've actually already done a bit of work in this area (tho' quite incomplete). Sorry I missed you on IRC yesterday, but I should be about today for the next few hours at least. > So far I've used the ext_stream_restore callbacks to try get enough > information to detect it, but the callbacks also > run on changes in volume etc not just hotplug events. Yeah I'd avoid completely ext_stream_restore. It's only one approach to routing, and thus does not cover the whole spectrum (currently routing is a bit disparate and split among several modules implementing specific policies - e.g. module-intended-roles ensures that streams are matched up to sinks via various proplist values). > Another approach I hoped would work is to use the "index" parameter of > the callback registered with pa_context_set_subscribe_callback, > but that approach didn't work either. Not quite sure what you were hoping to do here but I have a suggestion. > If somebody would shed some light on what the cleanest way to achive > this would be I'd appreciate it, My original intention here was to have a few "notification" APIs internally. These notification APIs would allow modules to post information relevant to what's going on. e.g. "New device has appeared", "Stream has moved" etc. etc. It would also be able to gather feedback from the user via some form of input. These APIs would mostly do nothing by themselves, but a module could be loaded into PA to hook into these notifications and then take appropriate action. e.g. a module-notify-logger could just log the events to a file, a module-notify-libnotify could use the notification spec to let the user know via passive popups etc. I had originally intended to be able to ask the user for feedback via the action callbacks of libnotify, but this may no longer be feasable on Ubuntu as they removed support in their default setup (which is totally dumb and causes a UI and cross desktop nightmare but such is life). I believe libindicate could be used here instead. Again, it would ultimately be up to the module to take appropriate action (you could even have a module-notify-festival that spoke the notification to you via the sound device and could interpret voice commands! The options are endless[ly pointless]!) Anyway, I didn't go too far with it but the code still exists here: http://colin.guthr.ie/git/pulseaudio/commit/?h=notifications&id=2d6807530646a1d084f3df9fee0189d5e4a791a0 (I'd be surprised if it compiles and runs these days, but you never know :D) I'd very much like to discuss the general idea here and see what people think. Perhaps your remit goes beyond just notifying in which case the above approach may not be valid depending on the use case. It may even be overdesigned? Who knows... either way I'm happy to discuss. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]
