[pulseaudio-discuss] RFC: Routing and Priority lists

[Tanu Kaskinen]

On Mon, 2011-11-28 at 16:07 +0200, Janos Kovacs wrote:
> > 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 see. I don't have an opinion on whether this case should be handled
with switching between priority lists or with a dynamic list - either
seems fine to me.

> > 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.

I guess such filtering would happen with the current code. I'd expect it
to be quite easy to fix, though. What kind of fix that would be probably
depends on what the actual use case is that requires the user to select
the correct accessory type. If it's that different filters (or same
filters with different parameters) need to be applied depending on the
accessory type, the fix might be that the description for the required
filtering is provided in the paths' property lists, and if those lists
are different, then the paths are not duplicates.

Of course, if someone thinks (I don't, at least yet) that needing to
work around the duplicate exclusion logic adds too much complexity,
maybe it's better to have the complexity elsewhere and just add to a
generic port a property that describes the connected accessory.

-- 
Tanu