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

[Alexander E. Patrakov]

сб, 20 апр. 2019 г. в 05:54, Georg Chini <georg at chini.tk>:
> But what you are basically saying is that the equalizer does
> not hold what Andrea claims it can do and that it is only useful
> as a 10-band equalizer. I wonder why her work was then
> accepted as a master thesis.

I don't know the Italian requirements for a master thesis. In Russia,
rejections of this kind of thesis are rare: it's a time-boxed activity
without a second chance to choose a topic (unlike the real scientific
work), and rejections would make it a not-worth-it gamble in the
students' eyes. And the same kind of number-of-pages stuffing (by
including chapters on "considered but rejected" techniques) is common,
I did it too.

We do need a recheck from Italian experts not related to the
government issued degrees. Probably on JACK mailing lists?

And hopefully you now understand why I am inclined to reject even
objectively-good scientific code submissions, if they are making
something a part of PulseAudio: insufficient number of local experts
that would have rejected bad submissions. OTOH, a plugin architecture
that allows us to tap into the work by an existing pool of experts,
without taking any responsibility, would be awesome.

> >>> Besides, consumer electronic devices (TVs, HDMI receivers, Hi-Fi
> >>> amplifiers) just do not have equalizers with a variable number of
> >>> bands, for usability reasons. I don't see a reason for PulseAudio to
> >>> be different.
> >>>
> >> You can't add sliders on the fly on a consumer electronic
> >> device but you can do so in software. Why should we be guided
> >> by a behavior that is governed by physical limits? If the algorithm
> >> supports it, I see no reason why it should not be implemented.
> >> (As said above naturally within some sane limits, you are right
> >> that it would make no sense to have for example 50 bands.)
> > Sliders in a consumer electronics device such as a TV are just virtual
> > widgets on the screen, i.e. software, not physical knobs. Again, their
> > number is fixed because of usable and "intuitive" UI.
> I guess there are enough people who would wish for more
> flexibility.
> >
> >> Surely you could go for several different plugins, but I do not
> >> see the reason why the code should be duplicated a couple
> >> of times. The goal is to have one plugin and not a collection.
> >> I just don't like the idea that you have to duplicate things only
> >> because of the limitation of the surrounding framework.
> >> That's why I am looking for a way to dynamically adapt the
> >> number of control ports or - which seems to be supported
> >> by LV2 - use a control port that is an array.
> > And my point is exactly that there is a reason, filter order, not
> > related to any framework limitations, for different code for different
> > number of bands.
> >
> >> Another example where an array would be useful as a control
> >> port is the virtual-surround-sink. The HRIR data used by the filter
> >> is an array of floats which could vary in size.
> > I also disagree here. Yes, it can vary in size, but should not be
> > treated as a control port at all. There is no way to usefully control
> > it for a user, that's why. It should therefore be either hard-coded
> > (as done in Windows) or loaded through a file.
>
> If you load it through a file like pulseaudio does, how do
> you pass the values to the filter? Or should the plugin itself
> load the file?

The plugin itself should load the file. The fact that the file does
not come with the plugin itself is a major bug that unfortunately
exists for licensing reasons. I think we should find a free-enough
data source for HRIR/HRTF and just hard-code the impulse responses,
though. We can investigate reusing the data from CSound.

--
Alexander E. Patrakov