пт, 10 мая 2019 г. в 22:27, Tanu Kaskinen <tanuk@xxxxxx>: > > /* 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 sense. 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 plugins. 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 _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
