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
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Reply via email to