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
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
