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

[Tanu Kaskinen]

Hi all,

It looks like in the future the ALSA drivers for some Intel hardware 
will dynamically create a new PCM device when a DisplayPort monitor is 
plugged in. This is being discussed in this thread (part of the thread 
is also cross-posted to pulseaudio-discuss): 
http://thread.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/62703/focus=63002

PulseAudio doesn't currently support dynamic PCM devices, so work is 
needed to add that support. I may work on that, or it may be someone 
else from Intel. I'll describe here what code changes I think we should 
make. That serves two purposes: to get feedback about the plan before 
any code gets written, and to help with the implementation work if 
someone else than me is going to write the code.

This is a long mail, but I'm sure I still didn't think of every issue 
that will arise when implementing this...


Event: monitor gets plugged in
------------------------------

The first thing that happens should be that PulseAudio gets a wakeup 
from the alsa mixer, when a new ELD control for the monitor is added. 
This is important, because the mixer should be ready when PulseAudio 
starts to use the new PCM device. It's up to the driver developer to do 
this right. This wakeup can be ignored, so no code changes are needed in 
PulseAudio to handle this.

The second thing that happens is that udev notifies PulseAudio about a 
new PCM device. Interfacing with udev is done in 
src/modules/module-udev-detect.c. Currently PulseAudio only cares about 
new and removed cards, so module-udev-detect has to be modified to also 
keep track of what PCM devices each card has, so that new devices can be 
noticed.

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.

When moving the code from module-alsa-card to pa_alsa_card, some changes 
to the sink and source error handling is needed. Currently, if something 
fails in the IO thread of an alsa sink or source, the sink/source 
unloads the module that owns the sink/source (see the end of 
thread_func() in alsa-sink.c and alsa-source.c). Now the owner module of 
alsa sinks and sources becomes module-udev-detect, and we certainly 
don't want to unload that if a single sink or source fails. The 
sink/source should notify the pa_alsa_card object of the failure (new 
functions pa_alsa_card_sink_failed() and pa_alsa_card_source_failed()), 
and pa_alsa_card should free the failed pa_alsa_sink or pa_alsa_source 
object.

Let's get back to the pa_alsa_card_pcm_added() function. What should it 
do? We shouldn't support dynamic PCMs for arbitrary hw PCMs, because 
that's not compatible with relying on logical device names like "front", 
"surround51" etc. At this point we only need to support dynamic PCMs 
that are dedicated to hotplugged HDMI/DisplayPort/Thunderbolt devices. 
The current proposal to detect such PCMs is to add a new HDMI class to 
snd_pcm_class_t, which can be queried with snd_pcm_info_get_class().

Currently when opening HDMI devices, we use "hdmi:x,y" as the device 
string, where x is the card index and y is the device index. The device 
index may be different than the hw device index, but the mapping between 
"hdmi:x,y" to "hw:x,z" is static. The mapping can be different with 
different drivers, AFAIK. We currently blindly try all device indexes 
from 0 to 7 when probing the card. Takashi Iwai told that such behaviour 
won't be compatible with drivers that create dynamic PCMs for HDMI. I 
guess the reason is that the dynamically allocated hw device indexes can 
(and usually do) fall outside the index range that is used in "hdmi:x,y".

Since the new HDMI PCM class is new, old kernels and old alsa-lib won't 
use that class even with PCMs that are actually dedicated to HDMI. We 
need to tell apart drivers that use the new HDMI PCM class and drivers 
that don't. With drivers that never use the HDMI class, we should keep 
using the "hdmi:x,y" device strings. With drivers that use the HDMI 
class, we should use "hdmi:CARD=x,SYSDEV=z", where z is the hw device 
index (the SYSDEV parameter doesn't currently exist, so alsa-lib needs 
to be updated to support it). How do we tell the two kinds of drivers 
apart? The current proposal is to add a version field to the PCM info. 
Version 0 would mean that the driver is unaware of the HDMI PCM class, 
and version 1 would mean that the driver will set the PCM class to HDMI 
when appropriate.

I assume that the PCM info version will be provided separately for each 
PCM device, but I expect the version to be always the same for every 
device that belongs to the same card. We definitely need to make the 
decision between the two models at the card level in any case, because 
we can't really mix the "hdmi:x,y" model with the "hdmi:CARD=x,SYSDEV=z" 
model within the same card. When probing a new card, we should check the 
PCM info version of the first device that we probe, and choose the HDMI 
model for the card based on that. If the first device has PCM info 
version 0, then we won't support dynamic HDMI devices for that card, 
even if subsequent devices would somehow have version 1.

The "mapping" concept in our alsa-mixer code corresponds to the PCM 
devices. What mappings exist is configured in 
src/modules/alsa/mixer/profile-sets/default.conf. We have many HDMI 
entries, here are a couple of examples:

[Mapping hdmi-stereo]
description = Digital Stereo (HDMI)
device-strings = hdmi:%f
paths-output = hdmi-output-0
channel-map = left,right
priority = 4
direction = output

[Mapping hdmi-stereo-extra1]
description = Digital Stereo (HDMI 2)
device-strings = hdmi:%f,1
paths-output = hdmi-output-1
channel-map = left,right
priority = 2
direction = output

The "device-strings" option doesn't suit the HDMI case very well, if we 
sometimes have to use "hdmi:x,y" and sometimes "hdmi:CARD=x,SYSDEV=z". 
Also, the path configuration files assume a particular mapping from 
"hdmi:x,y" to "hw:x,z" when dealing with ELD information and jack 
detection, and that assumed mapping is incorrect with dynamic HDMI 
devices. (This assumption probably also means that our HDMI ELD and jack 
detection functionality is currently broken on non-HDA cards.)

I propose that we add a new boolean option for mappings, which would 
indicate that the mapping represents more than one PCM device, and that 
the PCM and mixer handling is performed according to the complex HDMI 
specific rules that I've explained above. The option name could be e.g. 
"dynamic-hdmi". When "dynamic-hdmi" is be set for a mapping, the 
"description", "device-strings", "paths-output" and "direction" options 
in the configuration file would be ignored, and the appropriate values 
for those would be hardcoded. That would allow us to shorten 
default.conf quite a bit, and also remove all the hdmi-output-N.conf 
path files (the generated paths would be hardcoded too).

All that hardcoding isn't nice from flexibility point of view, but I 
don't think the lost flexibility is very important in this case. I 
believe that any alternative solution that would keep everything in the 
configuration files would introduce a significant amount of complexity 
to deal with the variance in the "hdmi:x,y" -> "hw:x,z" mapping (and I'm 
not sure it's even possible to have non-HDA-specific ELD information and 
jack detection support with the old-style "hdmi:x,y" device strings, 
since we don't have a reliable method to figure out what hw PCM device 
index y corresponds to).

In case of dynamic HDMI mappings, the HDMI profiles need to become 
dynamic too. So, if a profile definition in a configuration file 
references a mapping that has the "dynamic-hdmi" flag set, that profile 
definition will then represent multiple profiles, one for each HDMI 
device. I'm not sure how to deal with the "description" option. Should 
it be ignored, or should we append a number to the description when 
there are multiple HDMI devices? When profiles are autogenerated (which 
is the common case), then the existing profile description logic should 
work fine.

So, when pa_alsa_card_pcm_added() sees that a new HDMI PCM device 
appeared, it should create a new mapping for the device, a new path for 
the mapping, and a new profile containing the mapping. Then 
pa_alsa_card_pcm_added() needs to call pa_card_add_profile(), and 
hopefully it will just work.


Event: monitor gets unplugged
-----------------------------

When a monitor gets unplugged, module-udev-detect gets a notified, and 
it should figure out that a PCM device has disappeared. It should then 
call pa_alsa_card_pcm_removed(), which is a new function that needs to 
be implemented.

pa_alsa_card_pcm_removed() should mirror pa_alsa_card_pcm_added(), just 
undoing the things that _added() did, in reverse order. So, first it 
should call pa_card_remove_profile(). That function doesn't exist 
currently, so it needs to be implemented. Next 
pa_alsa_card_pcm_removed() should free the pa_alsa_profile, 
pa_alsa_mapping and pa_alsa_path objects corresponding to the removed 
device. I think that's it for pa_alsa_card_pcm_removed().

If the profile that is being removed is active, pa_card_remove_profile() 
should change the card profile to something else. I suppose it should 
use the same logic as what pa_card_new() uses when choosing the default 
profile.

-- 
Tanu