On 27.04.19 12:55, Georg Chini wrote:
On 27.04.19 12:04, Tanu Kaskinen wrote:
On Fri, 2019-04-26 at 11:40 +0200, Georg Chini wrote:
On 26.04.19 10:56, Tanu Kaskinen wrote:
On Tue, 2019-04-23 at 21:20 +0200, Georg Chini wrote:
The current scheme for
updating
parameters I have in mind should work for any of the existing filters
and relies on
passing around parameter structures:
After implementation, the actual interface looks like this:
/* 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. If the old
* structure can be re-used, the function may return NULL. */
void *(*update_filter_parameters)(void *parameters, void *userdata);
/* Frees a parameter structure. May only be NULL, if
update_filter_parameters()
* is also NULL or if update_filter_parameters() always returns
NULL. */
void (*parameter_free)(void *parameters);
/* The following functions can be provided to set and get
parameters. The parameter
* structure is defined by the filter and should contain all
parameters that are
* configurable by the user. The library code makes no assumption
on the contents
* of the structure but only passes references. The library
implements a message
* handler which supports the following messages that use the
functions below:
* parameter-get - Retrieve a single parameter.
* parameter-set - Set a single parameter.
* parameter-get-all - Retrieve all parameters as a comma separated
list.
* parameter-set-all - Set all parameters simultaneously.
* parameter-get-description - Returns a filter description and a
list that describes
* all parameters. Format of the list
elements is:
* {{Identifier}{Type}{default}{min}{max}}
* The last message can be used to get information about the filter
or to implement
* a filter control GUI that is independent of the filter type.
* If filter_message_handler() is defined, all other messages are
passed on to the
* filter. The get functions are expected to return a string in the
message handler
* format while the set functions receive plain strings. */
/* Get the value of the parameter described by identifier. The
value shall be returned
* as a string in value. The identifier may be any string that the
filter recognizes
* like a name or index, depending of the implementation of this
function. */
int (*parameter_get)(const char *identifier, char **value, void
*userdata);
/* Sets the value of the parameter described by identifier. The
value is expected as
* a string. The identifier may be any string that the filter
recognizes like a name
* or index. Returns a parameter structure filled with all current
parameter values,
* reflecting the updated parameter, so that the structure can be
passed to
* update_filter_parameters(). update_filter_parameters() will
replace the current
* parameter set with the new structure. */
void *(*parameter_set)(const char *identifier, const char *value,
void *userdata);
/* Returns a list of the values of all filter parameters. Each
parameter must be enclosed
* in curly braces and there must be braces around the whole list. */
char *(*parameter_get_all)(void *userdata);
/* Expects an array of all filter parameter values as strings and
returns a parameter
* structure that can be passed to update_filter_parameters(). See
set_parameter(). */
void *(*parameter_set_all)(const char **all_params, int
param_count, void *userdata);
/* Returns a parameter description string as described above. */
char *(*parameter_get_description)(void *userdata);
/* Handler for additional messages. */
int (*filter_message_handler)(const char *message, char
*message_parameters, char **response, void *userdata);
It is not fixed yet what parameter_get_description() will exactly
return, so the list
above has to be viewed as an example. The set functions receive plain
strings
so that they need not be able to parse message handler parameter strings.
On the other hand, the get functions should return the result in the message
handler format.
Parameter sets can either be re-used or freshly allocated each time a
parameter
changes. If the update_filter_parameters() function returns a non-NULL
value,
the pointer will be freed in the main thread using the parameter_free()
function.
Does the interface look OK? Any suggestions?
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
