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 _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
