[pulseaudio-discuss] LFE remixing

[Alexander E. Patrakov]

02.10.2014 14:28, Tanu Kaskinen wrote:
>>>>> 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.

My argument for the "list of things to try" is not strong either. So I 
think the best strategy is to continue the discussion later, when 
someone actually tries to implement some policy.

-- 
Alexander E. Patrakov