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

[Georg Chini]

On 26.04.19 11:40, 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:
>>>
>>>
>>>       /* 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:
>>>        * get_parameter - Retrieve a single parameter.
>>>        * set_parameter - Set a single parameter.
>>>        * get_all_parameters - Retrieve all parameters as a comma
>>> separated list.
>>>        * set_all_parameters - Set all parameters simultaneously.
>>>        * get_parameter_description - Returns 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. */
>>>
>>>       /* 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_parameter(). update_filter_parameter() will
>>> replace the current
>>>        * parameter set with the new structure. */
>>>       void *(*parameter_set)(const char *identifier, const char *value,
>>> void *userdata);
>>>
>>>       /* Returns a comma separated list of the values of all filter
>>> parameters. */
>>>       char *(*parameter_get_all)(void *userdata);
>>>
>>>       /* Expects a comma separated list of all filter parameter values
>>> and returns a parameter
>>>        * structure that can be passed to update_filter_parameters(). 
>>> See
>>> set_parameter(). */
>>>       void *(*parameter_set_all(const char *all_params, void 
>>> *userdata);
>>>
>>>       /* Returns a parameter description string as described above. */
>> Some comments on the interface:
>
> Thanks, that was what I hoped for.
>
>>
>> "Parameters as a comma separated list" sounds potentially problematic
>> if the specification extends to the public API as well, unless all
>> possible parameter types are defined to not contain commas. Why is the
>> list not encoded in the same way other lists are encoded in the message
>> API?
>
> It surely can be encoded the same way, but currently the
> parameters for the LADSPA sink can be specified on the
> command line as a comma separated list, so I thought it
> would be a good idea to keep that format and allow other
> filters to do the same thing. I do not think it is a big restriction
> to not allow commas in the parameters. I can think of
> following parameter types: Int (signed and unsigned), float,
> bool and string. Only the string type would have a problem
> and we could use escaping there. Or do I miss something?
> The comma separated list is easier to understand for users
> of the interface. 
While trying to implement it, I see that you are right and using the
serialization of the message API is the best way to do it.