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

[Tanu Kaskinen]

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:
> > > 
> > > 
> > >       /* 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.

Hmm, maybe you're right that it's a bit more user friendly format. It
feels somewhat ugly to send a list as a string when the transport has
native support for lists, but I think I can live with that.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk