[pulseaudio-discuss] new module module-plugin-sink

Alexander E. Patrakov patrakov at gmail.com
Sat May 11 06:01:17 UTC 2019

пт, 10 мая 2019 г. в 22:27, Tanu Kaskinen <tanuk at iki.fi>:
> > /* Function called when the filter detects a condition to unload the filter. */
> > typedef void (*Kill_Filter_Function)(void *module);
> What's the use case for for filter self-destruction?

Moving to a sink/port where it doesn't make sense. And, we talked only
about self-disabling until moved again, not self-destruction.

> >     unsigned input_channels;                  /* Number of audio input channels, 0 if variable */
> >     unsigned output_channels;                 /* Number of audio output channels, 0 if variable */
> How are these used? You wanted to avoid deinterleaving, so I guess mono
> filters are expected to support variable channels. What kind of filters
> are going to set fixed channels? Is a filter expected to support all
> possible channel counts if it supports more than one channel count?

An example of a filter with fixed output channels would be virtual
surround, which makes sense only for 2 output channels.

> >     size_t fixed_block_size;                  /* Block size in frames for fixed block size filters,
> >                                                * 0 if block size is variable */
> I guess this is added here, because module-echo-cancel uses a fixed
> block size. LADSPA plugins don't seem to care about the block size.

FFT-based equalizer does care.

> >     /* If not NULL, this function is called whenever the active port of a sink or
> >      * the sink itself changes. It is used to communicate the currently active port
> >      * and sink to the filter. */
> >     void (*output_changed)(const char *sink_name, const char *port_name, void *filter_handle);
> What is the filter supposed to do with this information? I recall from
> the earlier discussion that the filter could disable itself, if the
> sink name and the port name look somehow bad, but there doesn't seem to
> be any mechanism for telling the filter which sinks and ports are bad.
> I don't think this logic belongs in the filter anyway, the policy code
> for enabling/disabling filters automatically should be implemented
> separately.

The filter is supposed to use this for self-disabling (virtual
surround on non-headphones), or for loading different sets of
parameters (equalizer) when moved to a different port if it makes

The problem with policy code is that there is no place for it at all,
except the filter itself, if we expect these filters to be written by
external DSP experts. For PulseAudio, it is just a black box written
by someone else, that's the whole point. If we want to write the
policy code, it would be specific for that particular third-party
filter. I.e. the policy code must be also written by that third party
and loaded from an external module (otherwise the filter is not a
black box), and we have no interface for such third-party policy

Note that this kind of "each filter needs policy to self-disable when
inapplicable" argument was supposed to be used as an argument against
conversion of module-virtual-surround-sink to the new interface.
Addition of the callbacks (instead of dropping the use case) was an
unexpected effect of our conversations. There is indeed a weak point
here in the form of an assumption that such policy could only care
about sink and port names.

Alexander E. Patrakov

More information about the pulseaudio-discuss mailing list