[pulseaudio-discuss] LFE remixing

[Alexander E. Patrakov]

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.

> To make the remixer parameters configurable per device:

>   - Add two string attributes to ports, sinks and sources: the remixer
> implementation id and the preset name.

Correct. Ideally we need this per port (so that LFE remixing is disabled 
on headphones, and virtual surround is enabled only on headphones, 
including those connected to an HDMI monitor). However, there is a 
possibility of a sink that doesn't belong to any card and thus does not 
have ports, so we need this (or a fake "default" port) on sinks, too.

I am not yet ready to talk about sources, but guess that similar 
arguments apply.

>   - Modify module-card-restore and module-device-restore so that they
> save and restore the new attributes.

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"? Is 
it always appropriate to fall back to the current remixer implementation?

>   - Implement a preset database.
>   - Modify pa_resampler so that its remixing behaviour can be controlled
> by giving the remixer implementation id and the preset name to
> pa_resampler_new.

OK.

>   - Modify pa_sink_input and pa_source_output so that they use the
> device's remixer attributes when calling pa_resampler_new().

OK, but then there is an open question who should react to active port 
changes. I.e., if virtual surround was enabled on headphones, it should 
be switched off when switching to speakers. This means calling 
pa_resampler_new() on port changes. Maybe it is a good idea to implement 
this similarly to a sink input move.

> To support multiple remixer implementations:
>   - Add a registry for remixer implementations so that modules can add
> and remove implementations dynamically.
>   - Modify pa_resampler_new() so that it uses the remixer registry when
> initializing the remixer.

OK.

> 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.

> 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.

-- 
Alexander E. Patrakov