[pulseaudio-discuss] [RFC] Exposing ports and profiles to clients

[David Henningsson]

2011-10-24 20:19, Tanu Kaskinen skrev:
> On Sun, 2011-10-23 at 16:46 +0200, David Henningsson wrote:
>> Two different proposals (very drafty) on how to expose ports for
>> inactive profiles, dunno which one is better. The first one adds a
>> cross-reference struct which will repeat itself for every combination of
>> port and profile. The second one adds a profile list for every port. The
>> second one looks less ugly, but would bloat the network a little more as
>> that would make pa_sink_port_info include the profile list as well.
> The first option feels somehow very unintuitive to me. I like the second
> option better.
>
>> Both proposals add port lists to the card. The internal structure for
>> this is coming soon to a patch near you.
>>
>> Both patches can also be combined with a patch that would merge
>> pa_source_port_info and pa_sink_port_info into a single struct (for
>> simplicity).
>>
>> Note: as some of you might remember, I tried adding a "ports" field to
>> the pa_card_profile struct, but that broke the ABI as pa_card has a list
>> that's depending on the size of pa_card_profile.
> If adding a "ports" field to the pa_card_profile struct feels like it
> would obviously be the best option, how would you feel about creating a
> parallel version of the pa_card_profile struct with the design flaw
> fixed? I mean pa_card_profile2. pa_card_profile would get deprecated,
> but in order to keep backwards compatibility it would have to be kept
> around. Any new features would get added to pa_card_profile2.
>
That's a good point. I wonder whether having ports point to profiles or 
the other way around is the more intuitive approach. Given the upcoming 
patch set I'd say having ports point to profiles is slightly more 
intuitive than the other way around, but that might be just because I 
organized it that way in the core. What about a third proposal, like the 
below? It makes the card ports differ from the sink/source ports, but 
that is perhaps less problematic than other approaches.

diff --git a/src/pulse/introspect.h b/src/pulse/introspect.h
index 1d77d45..2b6dc28 100644
--- a/src/pulse/introspect.h
+++ b/src/pulse/introspect.h
@@ -452,6 +452,21 @@ typedef struct pa_card_profile_info {
      uint32_t priority;                  /**< The higher this value is 
the more useful this profile is as a default */
  } pa_card_profile_info;

+/** Stores information about a specific port of a card.  Please
+ * note that this structure can be extended as part of evolutionary
+ * API updates at any time in any new release. \since 2.0 */
+typedef struct pa_card_port_info {
+    const char *name;                   /**< Name of this port */
+    const char *description;            /**< Description of this port */
+    uint32_t priority;                  /**< The higher this value is 
the more useful this port is as a default */
+    pa_port_available_t available;
+    int is_input;
+    int is_output;
+    uint32_t n_profiles;                 /**< Number of entries in 
profile array */
+    pa_card_profile_info** profiles;      /**< Array of pointers 
available profile, or NULL. Array is terminated by an entry set to NULL. */
+} pa_card_port_info;
+
+
  /** Stores information about cards. Please note that this structure
   * can be extended as part of evolutionary API updates at any time in
   * any new release.  \since 0.9.15 */
@@ -464,6 +479,8 @@ typedef struct pa_card_info {
      pa_card_profile_info* profiles;      /**< Array of available 
profile, or NULL. Array is terminated by an entry with name set to NULL. 
Number of entries is stored in n_profiles */
      pa_card_profile_info* active_profile; /**< Pointer to active 
profile in the array, or NULL */
      pa_proplist *proplist;               /**< Property list */
+    uint32_t n_ports;
+    pa_card_port_info **ports;
  } pa_card_info;

  /** Callback prototype for pa_context_get_card_info_...() \since 0.9.15 */