10.02.2015 16:57, David Henningsson wrote: > > > On 2015-02-06 12:41, David Henningsson wrote: >> >> >> Hrm, that is actually a good question. In theory, I would expect >> module-switch-on-port-available to switch profiles between 2.0 and 2.1 >> as headphones are plugged in and out, but in practice, >> >> - I'm not 100% sure if our "don't switch to HDMI" might prevent >> switching from 2.1 to 2.0 when headphones are plugged in, and >> >> - As the 2.0 profile is available on speakers, that will continue to >> be selected when headphones are unplugged. >> >> So, while this is not directly related to whether there is an LFE filter >> or not - we already have a 2.1, 5.1, etc, profiles - indeed the problem >> might become worse with the LFE filter. > > Having given this a second thought, I'm thinking maybe an improvement of > the priority-list based routing would be the best option. (Which I'm not > working on as often as I perhaps should...). > > I e, the port-based priority list routing should also remember what > profile a particular port was on. > > E g, first time boot you will start up on stereo + speaker (because > stereo has higher prio than 2.1). > The user then switches manually to 2.1 which makes the routing module > remember "2.1 profile for speaker port". > > Then the user plugs headphones in. That causes a switch to stereo, > because the headphones port is not supported on 2.1. > After unplug again, the routing module will switch port to speaker (the > highest priority port that is available) and profile to 2.1 (because it > remembered that). I have read your reply, and think that this proposal would work. Card+port based priority-list routing is indeed a common feature request, according to what I see on IRC. However, I also have a subjective feeling that I don't quite get the whole picture with cards, ports and profiles. Currently, both profiles and ports belong to a card (struct pa_card contains hashmaps of them). But, when the routing module is loaded, due to automatic profile switching, your proposal effectively makes a profile a property of a port, not of a card, with an additional complication that one cannot change the profile of a port that is not currently active. Two versions of the enitiy-relationship diagram (with and without the module) must thus be maintained in one's mind. -- Alexander E. Patrakov
