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

[Georg Chini]

On 19.04.19 18:23, Alexander E. Patrakov wrote:
> пт, 19 апр. 2019 г. в 14:13, Tanu Kaskinen <tanuk at iki.fi>:
>> If the plugin gets the number of bands during the
>> initialization, it can create the appropriate number of non-array
>> control ports. Interleaved audio ports aren't needed either, because
>> PulseAudio can do the deinterleaving before passing the audio to the
>> plugin (like module-ladspa-sink already does). If one's going to write
>> an LV2 plugin, it's best to use standard port types so that all hosts
>> will be able to use the plugin.
> In addition, I think that "if the plugin gets the number of bands [at
> runtime]" is a very big "if" for an IIR-based equalizer. So big that I
> would rather hard-code it, or treat equalizers with a different number
> of bands as completely different plugins. The reason is that the
> required slope of inter-band transition (i.e., effectively, the filter
> order) is a function of the width of each band. Implement a filter
> with a too-low order, and it won't be able to isolate (and thus
> control thegain of) a frequency band selectively enough. Implement a
> filter with a too-high order, and its frequency response will be too
> steppy.

My understanding is that Andrea's equalizer algorithm supports
an arbitrary number of bands (certainly within some sane limits).
Please correct me if I am wrong.

> 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.)

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.

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.


The focus of this mail thread is no longer the equalizer, even
though the subject may suggest that and it is often used as an
example. The starting point of the discussion was that I did a
consolidation of the virtual sinks we have in pulseaudio (see
!88) and the result shows that many of the filters we have
could be further consolidated to a single plugin sink. The
question then was which kind of plugin format we should use?
Naturally it would be better to use some standard API instead
of inventing our own. And if we move to a plugin-sink, the
plugin API should also support the features of the new
equalizer, so that this can be integrated as well if Andrea
is willing to contribute to a plugin.

Tanu suggested the LV2 standard, so I took a look into it. My
understanding is, that the CVPort is the type of control structure
I have been looking for, though Tanu says otherwise.

There is however another limitation I see with the LV2 standard,
which is that it does not support interleaved audio channels.
This is not fatal, but at least inconvenient. It looks like massive
overhead to me if you have to de-interlace the audio data, then
run multiple instances of the filter and finally have to interleave
the data again. I think a plugin standard for pulseaudio should
be able to handle interleaved data.