On Wed, 2011-09-21 at 06:41 +0300, Lin, Mengdong wrote: > Hi Col, > > Thanks a lot for your advice and guiding me to the great design doc of > routing! I hope to continue the discussion from the other thread > http://lists.freedesktop.org/archives/pulseaudio-discuss/2011-September/011374.html > > I have some concerns with module-switch-on-connect (m-s-on-c), > module-device-manager (m-d-m) and device profiles: > 1. m-s-on-c can route audio to the new connected sink/source, and the > new device will become the default sink/source (or become the top of > default priority list in the future). > But when a port becomes available on a non-default device (not of > highest priority), audio will not be routed to that device's new > active port. > (from David's patch > http://lists.freedesktop.org/archives/pulseaudio-discuss/2011-August/011167.html) > So if user is playing music via HDMI and then want to use the > wired-headset (a port on ALSA sink), he cannot just plug in the > headset but still need disconnect HDMI manually. > I would be more convenient if m-s-on-c treats the port more like a > device, i.e. can route audio to the device with a new available port > no matter the device is default or not. The logic is same: if a user > connects/plug-in some device, he want to use it. I fully support this suggestion. In my opinion a port should always be thought as an individual device. (Edit: David replied during me writing this saying something about this feature being dropped...) > 2. m-d-m maintains a media-role-based priority list, m-s-on-c can > route audio to the new connected device but never update the priority > list. This may caused unexpected behaviors for some policy > requriements: > Use case: If I have 3 devices, dev 1 has highest priority, dev 2 has > 2nd priority and dev 3 lowest. Both dev 2 and dev 3 are removable > device. > If I plug in dev2, audio will be routed to dev 2 and then I plug in > dev 3 (without unplugging dev 2), audio will be routed to dev 3. Then > I feel dev 3 is not so good and want to switch back to my previous > choice dev2. But when I unplug dev 3, audio is routed back to dev 1 by > m-d-m. Is it doable to allow m-s-on-c affect the role-based priority > list, so new connected device has a higher priority? > I mean a dynamic priority list made from user connection/disconnection > rather than a pre-defined one. This suggestion also makes sense to me. If there's a good reason not to change the priorities in some setups, then I guess this needs to be made configurable in m-s-on-c, or an alternative version of the module needs to be written. But maybe there isn't a good reason for that, in which case it's best to always just modify the priority list. > 3. device profiles > I hope when a new card is created, it does not always use highest > priority profile. Rather, it can check all live streams' roles and > decide it profile and create the sink/source. E.g. If the Bluetooth > headset is connected during a phone call, it will use HSP profile, > otherwise use A2DP profile. In addition, when new stream is put or > unlinked, the card can change its profile accordingly. I previous > patch Bluetooth modules to do such thing but I feel this is not only > for Bluetooth but a general feature. Is it worth to write a module to > handle this feature? 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). During the route activation some other routes may become unavailable (for example, no a2dp when using hsp). The newly unavailable routes are marked as such, and then this same procedure is done for the next highest priority stream, etc. Some kind of stream prioritization is needed, unless you don't care whether hsp or a2dp will be chosen when both phone and music streams are present. I'm not sure how much work this would require. Probably a lot. At least the priority lists need to be added to the core. (Each pa_sink_input and pa_source_output will have their own device priority list, right?) Then the routing modules need to be updated or created to manage the priority lists. I'd guess that that will take quite a lot of thinking and work. Then the stream prioritization needs to be done somehow. And "potential ports" have to made available as routes to the routing system, with the ability to request the routes to be activated through an unified interface. And jack detection would be nice too. Should the re-routing process that I described above (iterate through the streams in priority order and activate the routes according) be implemented in the core or as a module? It seems to me that it will have to be in the core, with modules requesting the routing re-evaluation when they have updated the device priority lists. -- Tanu
