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

[David Henningsson]

On 2015-02-06 12:41, David Henningsson wrote:
>
>
> On 2015-02-04 18:45, Alexander E. Patrakov wrote:
>> 29.01.2015 03:14, David Henningsson wrote:
>>> Hi!
>>>
>>> Hui and I have been working on some LFE filter patches lately, and this
>>> is our first draft for review/feedback.
>>>
>>> First, I have greedily stolen the math from CRAS, because CRAS is BSD
>>> and
>>> as I understand we don't have a problem with merging more liberal
>>> licenses.
>>>
>>> The LFE filter is implemented in the resampler, which means it is done
>>> for
>>> every sink-input rather than every sink - this might mean some
>>> additional
>>> CPU processing if many different streams play back at the same time, but
>>> putting it on the sink side would disable the possibility to mix a 2.0
>>> stream
>>> with a 2.1 stream.
>>>
>>> The rewind part is very drafty and untested, and I'm not sure I choose
>>> the
>>> best design here. But at least this is something that could act as
>>> base for
>>> discussion.
>>
>> Sorry for a possibly-stupid question, but...
>>
>> Which part of PulseAudio is supposed to disable the effect if the user
>> plugs headphones in? Or is it yet to be written?
>
> 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).

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic