> At high level I think things could work like this: > > A new card appears. It has the capability to provide some number of > profiles, each of which will create some number of sinks and sources, > each of which will provide some number of ports. All these "potential > ports" are marked as available or not (or unknown) based on jack > detection. The new potential ports are fed into the routing system's > priority lists as new routes. > > After that, all active streams are re-evaluated in priority order. (How > do the stream priorities get assigned? I don't know.) At the beginning > of this process the currently active profiles and ports don't affect the > decisions, only the jack detection status matters. The highest priority > stream's device priority list is checked, and the highest available > route is chosen. The route may need to be then activated (change the > active card profile and device port), and then the stream is moved (if > necessary). Streams prioritization would be nice. At least a "phone" stream shall have the highest priority, which is true in all customer's policy requirements. And all "non-phone" streams can have a same priority, lower than phone. I feel it's hard to further prioritize other streams based on their media roles or applications, as customers never unify on this. In addition, some device have profiles for "phone" or "non-phone" respectively (e.g. Bluetooth HSP and A2DP profiles).This can make things simple, we need only care the 1st priority "phone" stream. When a new "phone" stream is created and routed to a device or an existing "phone" stream is routed to a new connected device/card, if that card has a profile more suitable than active profile, that card need change profile and phone stream will be routed to the new sink/source. This will also trigger other stream's routing to the new device but no further profile changes. And when the "phone" stream is unlinked, the card can change to a profile more suitable for "non-phone" streams, if SINK_INPUT/SOURCE_OUTPUT_UNLINK hooks can tell me the original device it linked to. It seems to me that the above work can be done a module based on sink-input/source-output's PUT/MOVE_FINISH/UNLINK hooks. Please correct me if I miss something. I'm not sure if there are other similar "stream role & profile" relationships like "phone & Bluetooth profiles". Thanks Mengdong
