[pulseaudio-discuss] RFC: Routing and Priority lists

[Janos Kovacs]

Hi,

I apologize for the slow reaction.

> I liked the "my idea was that we would use quite static priority lists
> what would change only if you get an external event" part, but the "like
> incoming call" example ruined it :) Why should an incoming call affect
> any routing priority lists? When an incoming call happens, a stream is
> created for the ringtone. The system should have a static routing
> priority list for ringtones, so no need to update any lists.

Voice guided navigation should never be routed to the earpiece (the
built-in mono speaker) because if you would listen you would not able
to see the map. However, during a phone call navigation instructions
might follow the normal audio targets for the call and be routed to the
earpiece. In addition the incoming call should not ring just beep, but
that is not a routing issue.

So either we would need to dynamically change the priority list or use
multiple priority lists. From Colin comments I understood so that the
multiple lists are preferred. So the priority lists might stay 'static' but
some policy module need to maintain a property on the navigation
stream that tells the 'mode' (ie. in call or not).

> I think you could still have separate ports for each accessory type. It
> would make it simpler to set up accessory specific tuning parameters,
> for example, if the only thing that mattered was the port in use,
> instead of the port and some property.

That's fine if we do not run to the trouble that some of those path's are
considered as duplicate and filtered out.

br
-janos-