[pulseaudio-discuss] RFC: Routing and Priority lists

[Janos Kovacs]

I try to build a multimedia policy for embeded systems like smart
phones, TV's in vehicle entertainment systems etc.
The idea is to have a policy decsion making daemon that would control
audio/video routing among other things. This policy
daemon supposed to push down policies to the actual madia handling
daemons eg. pulseaudio, X server or Wayland
compositor. So my comments come from that angle.

In general the priority list seem to be suitable approach for us.
However, in the routing decision we want to deal with logical
devices like 'speaker', 'headset'  etc not cards, sinks ports etc.
That would allow to separate policies from the HW adaptation.
IMO the mapping of logical devices to actual cards/sinks/sources/ports
should be done in pulseaudio. One reason we are
interested in UCM is that UCM natively support those logical devices.

The routing is somewhat similar what Tanu once proposed some time ago.
Generally the routing would happen like:
1.) the policy decision point would figure out a priority list of
logical devices for each media roles and push those lists to
     pulseaudio.
2.) a routing module in pulseaudio would maintain mappings between
logical devices and actual cards/sinks/sources/ports
     and the availablility of those logical devices. In case of
multiple logical devices it would select the preferred one (lets
     discuss later how this would happen).
3.) the routing module would also track the streams and maintain a
list of the active media roles.
4.) when streams appear/disappear the the routing module would figure
out the card and port settings by walking through
     of the active media roles. Media roles would have priorities and
the routing module would first set the cards/ports for the
     highest priority routing target of the highest priority media
role. The subsequent media roles would be routed to the first
     non-conflicting routing target (that can be in worst case the
nulll sink). Consequently the cards/ports would be set
     accordingly.
5.) the actual streams will be (re)routed to their sinks/sources if needed.

If the routing infrastructure will not support logical devices as
routing targets, in step 4 the routing module would create
for each media role a routing list with the single sink entry.

I am actually prototyping something to see how this algorithm would
work in practice. What we call a logical device maps
to device port in pulseaudio. It seems that the above algorithm can be
done but some infrastructural support for logical devices
would be good. For instance adding properties to device ports would
help. A property that describes the connected device
would help a lot (ie. instead of 'analog output' one could see that
actually a 'speaker' is connected to the jack). And of cource
some protocol change that this property could be get/set by applications.

I think the pulseaudio routing module and the policy daemon would not
be very much needed in desktops but makes much
sense IMO in embedded systems with limited user interaction capabilities.

My primary objective is to make sure that upcoming pulseaudio routing
infrastructural, port detection and UCM support
related changes are not blocking the above described algorithm. I also
hope to attract some other folks to this idea to
use the policy daemon + the pulseaudio module in embedded systems.

First I am interested in your opinions and go into details if you were
interested in such approach.

-janos-