[pulseaudio-discuss] Ladspa controls

[David Henningsson]

On 2014-09-19 10:38, Tanu Kaskinen wrote:
> 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;
> };

Why do we need a *key field here, if each control's name is unique, we 
can just use that as a key instead?

> 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.

Hmm, I guess we could say that the first control in the array is 
required to be the "main volume and mute" control, if sinks always have 
a "main volume and mute" control...

> 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.



-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic