On 30.04.19 20:46, Georg Chini wrote:
On 30.04.19 19:23, Alexander E. Patrakov wrote:
/* Callback to process a chunk of data by the filter. May be
NULL */
void (*process_chunk)(float *src, float *dst, unsigned count,
void
*filter_handle);
/* Callback to retrieve additional latency caused by the filter.
May be NULL */
uint64_t (*get_extra_latency)(void *filter_handle);
/* Initializes a new filter instance and returns a handle to
it. */
void *(*init_filter)(unsigned input_channels, unsigned
output_channels, unsigned sample_rate);
/* Deletes filter instance. */
void (*exit_filter)(void *filter_handle);
/* If set, this function is called in thread context when an
update
of the
* filter parameters is requested, may be NULL. The function must
replace
* the currently used parameter structure by the new structure
and
return
* a pointer to the old structure so that it can be freed in the
main thread
* using parameter_free(). If the old structure can be
re-used, the
function
* may return NULL. */
void *(*update_filter_parameters)(void *parameters, void
*filter_handle);
I don't think this is implementable. How are the parameters supposed
to be initially allocated?
Why should this not be possible to implement? Meanwhile I have
it already implemented within the new virtual sink library and
I am using it for the virtual-surround-sink and also for
the ladspa-sink. Setting and querying parameters works
perfectly. For the virtual-surround-sink I allocate new memory
each time, while for the ladspa-sink I prepare a parameter set
in the main thread and copy it to the "real" parameter set
in the IO-thread.
The initial parameter set must be allocated when the
filter is initialized. The parameter_set_all() function can be
used to do that or the filter_init() function could create a
default parameter set.
To make it clear: The proposal for an external interface comes
not out of the blue - I have all the bits already working for the
virtual sinks. That is module-virtual-sink, module-virtual-surround-sink,
module-remap-sink and module-ladspa-sink are fully converted to
the internal version of the interface. For module-equalizer-sink
I did not implement parameter changing because I could not
even figure out what the parameters are, but otherwise it also
uses the common infrastructure. Only module-echo-cancel
is a special case but still partly uses the virtual sink library.
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
