[pulseaudio-discuss] [RFC PATCH 0/6] LFE filter

[Alexander E. Patrakov]

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