[pulseaudio-discuss] [PATCH v2 04/10] card, sink, source: Introduce pa_device_prototype

[Tanu Kaskinen]

On Mon, 2013-12-09 at 20:31 +0200, Tanu Kaskinen wrote:
> @@ -45,7 +64,13 @@ typedef struct pa_card_profile {
>      unsigned priority;
>      pa_available_t available; /* PA_AVAILABLE_UNKNOWN, PA_AVAILABLE_NO or PA_AVAILABLE_YES */
>  
> -    /* We probably want to have different properties later on here */
> +    /* When populating these hashmaps, note that you initially own the device
> +     * prototype objects that you add, but once you call
> +     * pa_card_new_data_add_profile(), the prototype ownership moves to
> +     * pa_card_new_data (and later to pa_card). */

Doing the ownership transferring this way turned out to cause some
trouble down the road. Instead of passing the prototypes to the card
indirectly via pa_card_new_data_add_profile(), I think it's better to
create the prototypes separately from the profiles, and pass the
prototypes to the card directly with
pa_card_new_data_add_device_prototype().

The problem that I faced was that I wanted to add some constraints to
what kind of profiles are allowed (I want to forbid profiles that have
multiple devices containing the same port), so I changed
pa_card_new_data_add_profile() so that it can fail when the profile
breaks those constraints. Making the function failable means that the
profile creating code must be able to roll back the profile creation. If
device prototype creation is tied to profile creation, the roll-back
includes freeing device prototypes that aren't yet owned by the card,
but it's not so easy to figure out which prototypes are already owned by
the card and which are not. If device prototype creation isn't tied to
profile creation, life and code is much simpler. A side effect is that a
card may end up containing device prototypes that aren't part of any
profile and therefore stay unusued, but I don't think that does any
harm.

I don't know if I should make v3 of this patch set, or should I do the
changes on top of this patch set. The former would be cleaner, but the
latter would be easier for me. Opinions welcome...

> +    pa_hashmap *sink_prototypes; /* pa_device_prototype -> pa_device_prototype (hashmap-as-a-set) */
> +    pa_hashmap *source_prototypes; /* pa_device_prototype -> pa_device_prototype (hashmap-as-a-set) */

-- 
Tanu