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

[Georg Chini]

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?