[pulseaudio-discuss] R: New equalizer module (module-eqpro-sink), some questions

[Jason Newton]

Just some comments on this thread, mainly towards Andrea.

I tried looking over the thesis, but Italian is not my language, and
google translate seems to give up midway through.

Certainly welcome new blood and a new project to make equalization a
better experience.  Extra points for making it a masters thesis, and
doing a (qt) GUI along with it.

I think this thread shows there's some bits of work you have in front
of you for various concerns, but I think you could be weeks out from
getting signoff from Tanu and kind.  When that time comes, you have my
signoff by proxy as well.  I would think about profiles (as csv's,
json?) and potentially per-channel filters as features to have before
merge, but if you stay active, I wouldn't necessarily get held up on
those - I can tell you people will request them for features, though.

One of the things that hasn't changed in PA in all these years is how
to accomplish getting advanced modules like this working without
complexity both for the inside of these modules and for users.  Alot
of people managed to get the old equalizer to work for them, but there
were those that didn't.  That was a shared problem with the LADSPA
equalizer pathway.  You also have to deal with saving states/profiles
to the tools PA gives you which can be alot of support code in what
amounts to a module that is already burdened with complex boilerplate,
and the complexity of how to make a GUI work live.  An equalizer
brings up alot of issues inside of pulse's architecture, for sure.  I
see alot of suggestion and some promise of going the LADSPA pathway
but its got problems, as has been alluded to - these make me recommend
not going that direction, because unless you change LADSPA to suite
pulse's needs, you are sealed to its limitations (you could modify it,
though, but it may remain kludgy overall).  The value that pathway
offers is reducing the number of virtual sinks with duplicated
boilerplate, while the other proposed solutions just goes back to
things like filters and controls apis, creating complex
implementations of abstractions that are likely beyond time resources
in combination with not enough incentive to get the work done.

So my expectations are low that these problems will be dealt with
seamlessly, if ever.  It's still my belief that all filter modules
should be first class modules (even if a new kind), and not LADSPA,
but the DRY violations should to be dealt with to lower maintenance
burden and even make the implementation straight forward and reduce
maintenance issues.  My aim of attack would be on cracking how to
inherit and override module-virtual-sink, which is a much reduced
scope problem, and flexible - it seems like the lowest hanging fruit
to improve the situation significantly, and probably provides a
pathway to "the next step", if still needed.

I'll also note the GUI is going to be in a tricky place.  Hosting it
is problem #1, it is awkward at best to host it inside the PA project,
but it will be coupled to the versions - this was one reason why I
made qpaeq a python script.  It will also take a while before distros
ship another package, too, which in the short term makes things less
easy for users, especially if they have to compile - you will have to
be the catalyst that changes that.  Further, everyone wants one for
their desktop environment and toolkit and seamless integration -
whatever you end up doing, think carefully on this and balance burden
with solution.

Finally, on release/merge, I would think about how to get the word
out.  Google, non-unique/weak terms, and forums lead to alot of
re-circulation of confusion on this subject that dominated useful
information.  It sounds funny to mention SEO, but it is relevant.

-Jason