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-
