[pulseaudio-discuss] Ladspa controls

[Tanu Kaskinen]

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