[pulseaudio-discuss] Routing questions of module-switch-on-connect, module-device-manager and device profiles

[Tanu Kaskinen]

On Wed, 2011-09-21 at 06:41 +0300, Lin, Mengdong wrote:
> Hi Col,
> 
> Thanks a lot for your advice and guiding me to the great design doc of
> routing! I hope to continue the discussion from the other thread
> http://lists.freedesktop.org/archives/pulseaudio-discuss/2011-September/011374.html
> 
> I have some concerns with module-switch-on-connect (m-s-on-c),
> module-device-manager (m-d-m) and device profiles:
> 1. m-s-on-c can route audio to the new connected sink/source, and the
> new device will become the default sink/source (or become the top of
> default priority list in the future).
>   But when a port becomes available on a non-default device (not of
> highest priority), audio will not be routed to that device's new
> active port. 
>   (from David's patch
> http://lists.freedesktop.org/archives/pulseaudio-discuss/2011-August/011167.html)
>   So if user is playing music via HDMI and then want to use the
> wired-headset (a port on ALSA sink), he cannot just plug in the
> headset but still need disconnect HDMI manually. 
>   I would be more convenient if m-s-on-c treats the port more like a
> device, i.e. can route audio to the device with a new available port
> no matter the device is default or not. The logic is same: if a user
> connects/plug-in some device, he want to use it.

I fully support this suggestion. In my opinion a port should always be
thought as an individual device.

(Edit: David replied during me writing this saying something about this
feature being dropped...)

> 2. m-d-m maintains a media-role-based priority list, m-s-on-c can
> route audio to the new connected device but never update the priority
> list. This may caused unexpected behaviors for some policy
> requriements:
>   Use case: If I have 3 devices, dev 1 has highest priority, dev 2 has
> 2nd priority and dev 3 lowest. Both dev 2 and dev 3 are removable
> device.
>   If I plug in dev2, audio will be routed to dev 2 and then I plug in
> dev 3 (without unplugging dev 2), audio will be routed to dev 3. Then
> I feel dev 3 is not so good and want to switch back to my previous
> choice dev2. But when I unplug dev 3, audio is routed back to dev 1 by
> m-d-m. Is it doable to allow m-s-on-c affect the role-based priority
> list, so new connected device has a higher priority?
> I mean a dynamic priority list made from user connection/disconnection
> rather than a pre-defined one.

This suggestion also makes sense to me. If there's a good reason not to
change the priorities in some setups, then I guess this needs to be made
configurable in m-s-on-c, or an alternative version of the module needs
to be written. But maybe there isn't a good reason for that, in which
case it's best to always just modify the priority list.

> 3. device profiles
>   I hope when a new card is created, it does not always use highest
> priority profile. Rather, it can check all live streams' roles and
> decide it profile and create the sink/source. E.g. If the Bluetooth
> headset is connected during a phone call, it will use HSP profile,
> otherwise use A2DP profile. In addition, when new stream is put or
> unlinked, the card can change its profile accordingly. I previous
> patch Bluetooth modules to do such thing but I feel this is not only
> for Bluetooth but a general feature. Is it worth to write a module to
> handle this feature?

At high level I think things could work like this:

A new card appears. It has the capability to provide some number of
profiles, each of which will create some number of sinks and sources,
each of which will provide some number of ports. All these "potential
ports" are marked as available or not (or unknown) based on jack
detection. The new potential ports are fed into the routing system's
priority lists as new routes.

After that, all active streams are re-evaluated in priority order. (How
do the stream priorities get assigned? I don't know.) At the beginning
of this process the currently active profiles and ports don't affect the
decisions, only the jack detection status matters. The highest priority
stream's device priority list is checked, and the highest available
route is chosen. The route may need to be then activated (change the
active card profile and device port), and then the stream is moved (if
necessary).

During the route activation some other routes may become unavailable
(for example, no a2dp when using hsp). The newly unavailable routes are
marked as such, and then this same procedure is done for the next
highest priority stream, etc. Some kind of stream prioritization is
needed, unless you don't care whether hsp or a2dp will be chosen when
both phone and music streams are present.

I'm not sure how much work this would require. Probably a lot. At least
the priority lists need to be added to the core. (Each pa_sink_input and
pa_source_output will have their own device priority list, right?) Then
the routing modules need to be updated or created to manage the priority
lists. I'd guess that that will take quite a lot of thinking and work.
Then the stream prioritization needs to be done somehow. And "potential
ports" have to made available as routes to the routing system, with the
ability to request the routes to be activated through an unified
interface. And jack detection would be nice too.

Should the re-routing process that I described above (iterate through
the streams in priority order and activate the routes according) be
implemented in the core or as a module? It seems to me that it will have
to be in the core, with modules requesting the routing re-evaluation
when they have updated the device priority lists.

-- 
Tanu