[pulseaudio-discuss] RFC: Routing and Priority lists

[Colin Guthrie]

'Twas brillig, and Lin, Mengdong at 14/11/11 10:39 did gyre and gimble:
>> Hi,
>> 
>> I've written up my latest proposal to gather feedback before
>> starting (hopefully soon now) on the implementation. 
>> http://www.freedesktop.org/wiki/Software/PulseAudio/RFC/PriorityRouting
>>
>
>> 
> Thank you for improving the routing infrastructure, Col! I have a few
> questions & suggestions, based on previous customer requirements for
> a MeeGo tablet product:
> 
> 1. Can Pulseaudio register the default playback and some role's
> priority list automatically, with default weight? Even if the
> application does not register any priority lists, pulseaudio can
> build the default playback priority list by itself and add persistent
> and new plugged devices into the list.

Not sure what you mean here... most applications would not care about
priority lists (only mixer apps specifically designed to manipulate the
lists). Most audio producing apps will just setup their streams as
normal, this just changes which sinks/sources PulseAudio will will pick
for those apps.

So out of the box, a default priority list will start to be built up.
For some special cases (as now, such as module-intended-roles) some
devices will be injected into certain lists at specific levels. So
headset devices (bluetooth or USB) will be used by default for VOIP
calls, but probably not for music playback.

> And if a device has
> "device.intended_roles" set, Pulseaudio can also build a role-based
> device list if it does not exists yet and add the device to it. By
> default, the role-based list has a higher priority than the default
> list. If the application want to customize routing, it can register
> new priority lists or update an existing list's weight, as well as
> updating the entries.

No, the weightings will be hard coded in the module which registers them
(although it could of course be a module argument if you wanted).

One thing I did outline tho', is that when new devices are plugged in
(and inserted into priority lists at the appropriate locations - top for
headsets in the phone role priority list, bottom  for headsets in other
lists etc), the adjusted list will not be written to disk. Only when a
user action triggers a change to the list (i.e. the user uses an app
that changes the default device, moves a stream, edits a list etc.) will
the list be written to disk. If a device is plugged and removed without
any user action, the device will be removed from the list again, thus
preserving any code-based rules for where the device should be injected
whenever possible.

> 2. When a used removable devices is plugged in, can its entry be
> moved to the top of the priority lists that contain the device? Our
> customer requests sound always be played through the latest connected
> device, no matter this device is new or used before. And although
> there is no routing by using the public API calls, the hot-plug event
> can be taken as a "user event" to show the user intention. For
> example, when a BT headset is connected, its HSP sink shall be
> injected or moved to the top of both default playback and "phone"
> priority lists. A user can press "handfree" during a call to route
> sound to loud speaker/mic from BT, but if he later connects the BT
> headset again, he can hear the voice from the BT headset. We hope
> this feature can be supported at least with some kind of
> configuration, considering different user requirements.

This doesn't seem like it would be too hard to support. I'll have to
have a wee think, but I think this can be supported cleanly enough. It
certainly wouldn't be a mode we'd want to configure on the desktop, but
I certainly think it can be supported via a relatively simple module
you'd load on your config.


> 3. When a new card is created, can the card tell the properties of
> all its device+port for all profiles, before the sink/source are
> created? Profile switch is always our concern. When a card is
> created, it shall list all profiles and the device+port under those
> profiles. The properties can include "name", " device.intended_role"
> and sample spec. So even if a device+port is not created, we can
> still add them to the priority list and know which profile is
> necessary to create them. The routing system need check card's
> availability and switch profile if necessary. For example, when a new
> BT headset is connected, its HSP sink will be injected to the "phone"
> and default priority list, and its A2DP sink will be injected to the
> default priority list too. For a phone stream, the routing system can
> match HSP sink from "phone" priority list at first, and if the HSP
> sink is not available but the BT card is available, it will set card
> profile to HSP and route sound to the new available HSP sink. And
> when the phone ends, routing system will find A2DP sink is more
> suitable for active media streams and switch BT card to A2DP profile,
> considering sample rate and cha nnel numbers. Here the stream
> priority is also involved, and stream creation/destruction can also
> trigger profile switch and re-routing, as we discussed before 
> http://lists.freedesktop.org/archives/pulseaudio-discuss/2011-September/011398.html

While my work here won't enable this specifically, David's ongoing work
relating to jack detection will actually enable this kind of operation
and I fully intend to build on it to do what you suggest above.

The whole profile switching issue is going to be complex (as I outlined
in the wiki page) and in many cases non-deterministic (or rather results
could vary based on the order in which you do things) but I do intend to
support it for those uses cases that can accept this variation.

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/