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
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss