[pulseaudio-discuss] LFE remixing

[Alexander E. Patrakov]

28.09.2014 17:36, Tanu Kaskinen wrote:
> On Sat, 2014-09-27 at 02:40 +0600, Alexander E. Patrakov wrote:
>> 26.09.2014 18:17, Tanu Kaskinen wrote:
>>> A summary of my proposal:
>>>
>>> To add LFE low-pass filtering, just hack the current remixer
>>> implementation, no need for interface changes anywhere.
>>
>> OK. With that phrase, I no longer feel that I can interfere with your plans.
>
> I'm not sure how to interpret this. Do we have some plan that you'd like
> to interfere with, but trying to do that would likely to be futile?

No. I explicitly don't want to interfere with your plans, but, before 
you started the thread, I thought I could do so due to miscoordination.

With the "just hack the current remixer now" approach, separation of 
near-term and far-term plans is achieved, the potential of 
miscoordination is (in my subjective opinion) reduced, and that's good.

>> What needs to be done if the stored implementation no longer applies?
>>
>> E.g. imagine USB speakers. On the current kernel, they expose left,
>> right, and LFE channels. A user applies the LFE remixer. Then, after a
>> device firmware update, regressive kernel update or just hardware
>> reconfiguration, on the next boot the same device no longer exposes the
>> LFE channel. So the LFE remixer can't work.
>>
>> How can it say "I am not applicable, you are doing something wrong"?
>
> In this scenario there's only the current remixer involved. It has the
> "enable-lfe-remixing" option, but it's not necessarily relevant in all
> cases. If there's no LFE channel, the option is irrelevant, but the
> remixer implementation can still be used.
>
> It's still a good idea to make it possible to check whether a remixer
> implementation is applicable, though.

OK.

>> Is it always appropriate to fall back to the current remixer implementation?
>
> With the use cases that I'm currently aware of, yes. This might change
> in the future, but there's no need to worry about that now (otherwise
> than by making sure that we don't somehow bake it into the public API
> that forces us to always fall back to the current remixer
> implementation).

Understood. The "don't bake it into the public API" concern will 
definitely become relevant (and less abstract) when there appears one 
more remixer implementation that applies to all combinations of channel 
layouts.

<snip discussion about port switching - I have nothing to add>

>>> Hmm... Now I see one weak point in this proposal: adding the new
>>> attributes to ports, sinks and sources is perhaps not a very good idea,
>>> because we might actually end up with a policy that uses some other
>>> information for choosing the remixer than just the device, in which case
>>> the new attributes would be meaningless or at least insufficient. For
>>> example, whether or not to enable the virtual surround remixer depends
>>> also on the stream channel map.
>>
>> I guess it is not a big problem if the remixers are allowed to say "I am
>> not applicable" to this stream and output combination, in which case a
>> fallback happens to the simple remixer.
>
> That would prevent the user from configuring the fallback parameters on
> per-device basis. For example, if the user enables virtual surround on
> some port, s/he wouldn't have control over what happens when playing a
> stream where the virtual surround implementation doesn't apply.

Then we are talking about a chain of fallbacks, or a list of effects to 
try. What if the configured fallback doesn't apply, too?

>>> Perhaps it would be better to not add those attributes to ports, sinks
>>> and sources, but instead add module-remixing-policy, which could
>>> implement several policy models. The first implemented model would only
>>> use the device to choose the remixer. Saving and restoring the remixer
>>> attributes for each device would be done in module-remixing-policy
>>> instead of module-card/device-restore.
>>
>> Then this module should have knowledge of capabilities (as in "this
>> remixer is absolutely incompatible with this input or output") of each
>> remixer implementation that it covers.
>
> The remixer implementations should be introspectable enough so that the
> module can figure out when the user-provided configuration is
> inapplicable.

OK, and thanks for sharing your ideas.

-- 
Alexander E. Patrakov