[pulseaudio-discuss] LFE remixing

[Tanu Kaskinen]

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?

> > 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"?

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.

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

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

Right. We could detach and attach streams when changing ports. That's ok
by me; I don't see any reason why we would need to keep the streaming
uninterrupted during port switches. I actually already ended up
implementing such behaviour at least in the first iteration of the
routing work (never published), and IIRC that's also in the current
iteration.

It's of course also possible to trigger resampler reconfiguration
directly from the port switching code too, if the stream re-attaching
approach gets strong opposition.

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

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.

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

-- 
Tanu