Hi,
I was thinking how ladspa controls could be implemented and exposed in
the client API with the upcoming control framework. Not that I have
plans to implement a client API for ladspa controls any time soon, but I
want to have this some day, and the current control API doesn't seem
optimal for supporting this functionality.
The current plan for the definition of pa_control_info is the following:
typedef struct pa_control_info {
uint32_t index; /**< Index of this control. */
const char *name; /**< Name of this control. */
const char *description; /**< Description of this control. */
pa_proplist *proplist; /**< Property list for this control. */
pa_control_type_t type; /**< Type of this control. */
void *data;
/**< Type-dependent data. See pa_control_type_t for information
* about what data each type has. */
} pa_control_info;
It seems to me that the type field should be changed from an enumeration
to a string, so that modules would be free to introduce new control
types without modifications to the core.
It would also be nice to be able to associate arbitrary controls
directly with e.g. a sink. For that I propose to add an array of
controls to pa_sink_info and friends:
struct pa_sink_info {
...
struct {
const char *key; /* e.g. "volume" or "ladspa" */
uint32_t control; /* index of the control */
} *controls;
unsigned n_controls;
};
This would make the planned volume_control field redundant. However,
this would also make accessing the volume control more complicated,
because applications would have to search the array. If we drop the
volume_control field, we could add a convenience function for doing the
search:
uint32_t pa_sink_info_get_control(const pa_sink_info *info,
const char *key);
Any opinions? If nobody will complain, I will implement these proposals.
--
Tanu
