[pulseaudio-discuss] Does pulseaudio provide any callback mechanism for application on device change?

[Colin Guthrie]

'Twas brillig, and Lin, Mengdong at 20/09/11 10:13 did gyre and gimble:
> Hi Col,
> 
> The policy application is a routing manager.  And we hope the
> routing policy would be general rather than for any single customer.
> So it would be very helpful to support it in upstream and PA provides
> a framework for us to write our own routing module.
> 
> Here are the requirements: - No limitation on the types of devices. 
> Support as many audio devices as possible, including loud 
> speaker/mic, wired headset, Bluetooth headset, HDMI output etc.
> 
> - Latest connected device/port has highest priority for audio 
> output/input. PA can automatically route audio to this device/port
> at once. And the device will become the default sink/source. We
> don't consider multiple outputs/inputs for handheld devices now.
> (This work is done in module-switch-on-connect.c after David adds his
> jack detection patch)
> 
> - When the default device is removed or it active port become 
> unavailable, PA can route audio back the previous device/port if 
> still available. (So we need to maintain a device/port usage history 
> list, i.e. a priority list in connection and user choice order)
> 
> - The application get all device/port status and get notified on the 
> change. The user can manually route audio to any available 
> device/port.
> 
> - The default device (its card) can automatically change the profile 
> for the "main" stream. E.g. the Bluetooth headset can change profile 
> from A2DP to HSP when a "phone" stream is created and switch back to 
> A2DP profile after the call ends to play music.
> 
> We'll be grateful if you could share you ideas on these 
> requirements.

Yeah this is pretty much what I expected, so that's very much good news
from my part. The tricky bits are the automatic profile/port switching
(not the ones based on user input (i.e. the jack insert+automatic port
switch is quite easy) but the ones that are automatic (i.e. knowing that
HSP is better for phone streams and A2DP etc.)).

But overall nothing that is in any way surprising.

A good chunk of this policy is already present in the (optional)
module-device-manager module in the PA source. You just load it with
do_routing=1 and it implements per-role priority list based routing.

There is no support currently for the "new device goes in at highest
priority" policy but that would be relatively simple code change.

If you're looking to get something out the door quickly, I suggest you
use that module in your setup.


You may have read it already but I wrote up about 18months ago how I
would envisage things working in a more official capacity (i.e. moving
some of the module-device-manager code into core, but still keeping
things as modular as possible):
http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/ I suggest you
give it a read if you've not already done so as it's still relevant
today (primarily because I've not gotten around to doing the work yet!).

There would need to be new APIs added and the old APIs would have to
work in a semi sensible way too, but I don't think this presents a huge
challenge.

I was planning on working on this quite soon (post 1.0) but if you keep
in touch regarding your needs/timescales etc. then I'd be very happy to
discuss things with you (i.e. plan out API additions, changes to how
existing API functions operate behind the scenes, what new
hooks/callbacks will be needed etc.)

If you need any more info on the priority list routing implemented in
module-device-manager, please just ask.

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