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

[Tanu Kaskinen]

On Tue, 2015-09-22 at 09:13 +0530, Arun Raghavan wrote:
> 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.

Alsa and udev code need to communicate somehow. Neither of them
currently have an API that the other could use. To react to udev events
in alsa code we have two options:

1) Add a udev API, and notify the alsa code via hooks in the udev API.

2) Add an alsa API, and notify the alsa code via direct function calls.

In my opinion direct function calls are way cleaner, that's why I chose
adding an alsa API in my proposal.

-- 
Tanu