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.
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
