[pulseaudio-discuss] LFE remixing

[Tanu Kaskinen]

On Sun, 2014-09-28 at 18:21 +0600, Alexander E. Patrakov wrote:
> 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.

Ok, great :)

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

Yes, we could have a list of remixers for each device, and fall back to
the simple remixer with settings from daemon.conf if none of the
remixers in the list work.

However, the "try the listed remixers until one works" approach isn't
good if there are two remixers that both can be used, but one or the
other is preferred on some other criteria than just the device. For this
reason I'd prefer an approach where we have a policy module that allows
configuration with an extensible set of criteria. I don't have concrete
use cases for this, however, so if your taste says that it's better to
store the remixer preferences in the core device objects, because we'll
probably never need anything more flexible, then I don't have very
strong argument.

-- 
Tanu