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.
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.
OK.
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).
Understood. The "don't bake it into the public API" concern will
definitely become relevant (and less abstract) when there appears one
more remixer implementation that applies to all combinations of channel
layouts.
<snip discussion about port switching - I have nothing to add>
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?
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.
OK, and thanks for sharing your ideas.
--
Alexander E. Patrakov
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
