> So out of the box, a default priority list will start to be built up. > For some special cases (as now, such as module-intended-roles) some > devices will be injected into certain lists at specific levels. So > headset devices (bluetooth or USB) will be used by default for VOIP > calls, but probably not for music playback. Nice. And It would be helpful if the phone role priority list can also be built up out of box, when new headset devices are connected :-) > No, the weightings will be hard coded in the module which registers them > (although it could of course be a module argument if you wanted). It's OK for me. > > One thing I did outline tho', is that when new devices are plugged in > (and inserted into priority lists at the appropriate locations - top for > headsets in the phone role priority list, bottom for headsets in other > lists etc), the adjusted list will not be written to disk. Although I support that the hot-plug triggered list adjustment will not be written to disk, " bottom for headsets in other lists etc" is not suitable for me because of the customer requests below. I need a chance to change the default position, probably through a module as you suggested. > > > 2. When a used removable devices is plugged in, can its entry be > > moved to the top of the priority lists that contain the device? Our > > customer requests sound always be played through the latest connected > > device, no matter this device is new or used before. And although > > there is no routing by using the public API calls, the hot-plug event > > can be taken as a "user event" to show the user intention. For > > example, when a BT headset is connected, its HSP sink shall be > > injected or moved to the top of both default playback and "phone" > > priority lists. A user can press "handfree" during a call to route > > sound to loud speaker/mic from BT, but if he later connects the BT > > headset again, he can hear the voice from the BT headset. We hope > > this feature can be supported at least with some kind of > > configuration, considering different user requirements. > > This doesn't seem like it would be too hard to support. I'll have to > have a wee think, but I think this can be supported cleanly enough. It > certainly wouldn't be a mode we'd want to configure on the desktop, but > I certainly think it can be supported via a relatively simple module > you'd load on your config. > Would you kindly elaborate on how such a module works? Is there a hook for priority list entry update? So this module can change the headset entry's position in the list before next round routing is triggered. And many thanks for your feedback on profile switch! Regards Mengdong
