[pulseaudio-discuss] RFC: Routing and Priority lists

[Janos Kovacs]

Hi,

Thanks for the comments.

> Yes, this should generally be OK. The entries in each priority list are
> what I've coined as "device+ports". This is basically a specific port of
> a given device.

Yep, and I think a route in the priority list should be considered unavailable
if the device (ie. sink/source) is available but the active port does not
match. In such case the subsequent, lower priority routes should be
considered as long as a valid route target is not found. If we run out
of the routes, the stream should be moved to the null sink (if loaded :).
Alternatively the null sink can be part of the priority list I guess.
(Or do I miss something here?)

>
> e.g. on some HW I have, I have a single sink, but that sink consists of
> two ports: Speaker and Headphones.
>
> In a given priority list I may favour the built in Headphones first,
> then some external USB headset, then the Speakers.
>
> So as you can see the single sink actually fits into the priority list
> in two different places (or as many different places as there are ports).
> Some separate logic (ultimately coming from David's work on jack
> detection) would ensure a given port is activated when it becomes
> "available". This means that I have some stream playing and it's on the
> speakers, I plugin my USB headset and the stream moves over
> automatically (due to a "reroute" event triggered when the new sink
> becomes available). Then I plug in my headphones into the 3.5mm jack
> socket, and it's detected as now being "available". The "separate logic"
> mentioned, switches port from "speakers" to "headphones" and a "reroute"
> event is triggered (just like a new sink appearing/disappearing,
> "reroute" events are triggered on port changes too) and the stream is
> automatically moved to the Headphones.

Just to make sure we are on the same page:
Basically I propose a routing scheme where the routing decisions would
be made in a nested loop. In the outer loop we would walk through the streams
in decreasing priority order (marked by the media role of the stream).
In the inner loop we would walk through of the media role based routes of the
stream (also in decreasing priority order). The first available route will
be selected and configured, ie. the needed profiles and ports would be set.
Next the stream could be moved to the actual device.  Lower priority streams
should never undo the settings caused by higher priority streams.

So, IMO  the 'separate logic' should not make unconditional port changes,
rather it should consider the actual routing priority lists and make the port
change accordingly.

However, because in your preferences 'headphones' has the highest priority,
the above routing scheme will select the route to 'headphones' and actually
switch the port and move the stream from the USB sink to the sink of the
headphones. The port switching will block lower priority streams from using
the 'speaker'.

So my point is that
- the 'separate logic' should not  unconditionally change the profiles/ports
- we need some mechanism to mark cards/sinks to be configured to prevent
  lower priority streams to undo the possible port changes caused by higher
  priority streams
- since the 'separate logic' completely driven by the priority lists,
  it can actually be part of the basic routing infrastructure.


> NB I've used the term "separate logic" here quite loosely. David has
> some code to do this already, but this may eventually be superceded by
> logic inside the routing daemon that will automatically switch to higher
> priority ports on sinks if they are available.

I guess the above described algorithm (if you like it) could be part of the
of the basic infrastructure inside PA. Might not harm to provide some
mechanism to disable it and allow an external 'separate logic' to do the
profile/port settings if someone wishes to do so.

>> 3.) the routing module would also track the streams and maintain a
>> list of the active media roles.
>
> OK, I won't specifically do that in the proposed implementation, but
> (and feel free to correct me if I'm wrong) this is just a simple matter
> of iterating over the sink inputs and check the media.role property on
> each of them.

Right. The routing module meant to see how the 'separate logic' would
look like as PA module. The whole routing was split into two phases
and the media role tracking was just an optimization. Let's forget
about it for the time being :)

-janos-