Detecting hotplug routing changes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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/]



[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux