[pulseaudio-discuss] [RFC] Dynamically created PCM devices for HDMI/DisplayPort

[Arun Raghavan]

On 22 September 2015 at 00:44, Tanu Kaskinen <tanuk at iki.fi> wrote:
> Replying to a couple of months old thread...
>
> On Tue, 2015-06-30 at 18:08 +0300, Tanu Kaskinen wrote:
>> When module-udev-detect sees a new PCM device, it needs to notify
>> module-alsa-card about it. module-udev-detect's only interface with
>> module-alsa-card is pa_module, which is not useful for adding the
>> notification. I think we should move the bulk of the code in
>> module-alsa-card.c to a new class: pa_alsa_card. module-udev-detect
>> would then create pa_alsa_card objects instead of loading
>> module-alsa-card instances. module-alsa-card would still exist as a
>> wrapper around pa_alsa_card, but the module would not be used by
>> module-udev-detect. With pa_alsa_card in place, we can add a
>> pa_alsa_card_pcm_added() function to its API.
>>
>> pa_alsa_card should be defined in src/modules/alsa/alsa-card.[ch] and
>> included in the libalsa-util.la helper library.
>
> In IRC, Arun recently pointed out a problem in replacing module loading
> with creation of pa_alsa_card objects: users rely on the module
> interface to unload individual alsa cards, so users won't any more be
> able to unload cards that have been loaded by module-udev-detect (the
> main use case for that is probably debugging; you may want to reload
> module-alsa-card with different parameters than what module-udev-detect
> used).
>
> I propose the following solution: module-udev-detect will still load
> module-alsa-card instances using pa_module_load() like before, but
> pa_alsa_card objects will be created too. When module-alsa-card is
> loaded, it creates a pa_alsa_card instance and adds it to a registry
> from which module-udev-detect can look it up using the module index as
> the key. That way users still can unload cards, and module-udev-detect
> still has access to the pa_alsa_card API.

I've not had the time to properly consider the rest of your proposal
(and I'd particularly like to do that for the proposed config stuff),
but I thought I'd comment on this since we spoke about it.

Is there a reason to prefer the pa_alsa_card object to a custom hook
(the way bluetooth discovery communicates with the devices)? Then the
appropriate module-alsa-card can react to the hook and modify its
profile set.

I'm not against moving ALSA handling to an API, but this seems
somewhat cleaner and less intrusive to me to achieve what you want.

Cheers,
Arun