[alsa-devel] Dynamic HDMI PCM creation

[Takashi Iwai]

At Mon, 17 Sep 2012 13:03:56 +0200,
Jaroslav Kysela wrote:
> 
> Date 17.9.2012 12:40, Takashi Iwai wrote:
> > At Mon, 17 Sep 2012 12:15:23 +0200,
> > David Henningsson wrote:
> >>
> >> On 09/10/2012 03:01 PM, Takashi Iwai wrote:
> >>> Hi David,
> >>>
> >>> as we discussed at Plumbers, I tried some hack to create/delete
> >>> HDMI/DP PCM stream per hotplug/unplug.  Test patches are found in
> >>> sound-unstable git tree topic/hdmi-dynamic-pcm branch
> >>>    git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable.git
> >>>
> >>> The patches are all small and easy, but it's still in a pretty rough
> >>> cut.  It won't handle some cases, e.g. unplug during suspend, or
> >>> such, I'm afraid.  After all, it's just a test.
> >>>
> >>> With these patches, the PCM device appears and disappears properly
> >>> upon HDMI/DP hotplug/unplug on my system.  On mine, it appears as
> >>> /dev/snd/pcmC0D8 as it's an Intel on-board.  So far, so good.
> >>>
> >>> Now the problem is that PA gets confused when this happens.  It can
> >>> switch to HDMI/DP, but then the analog output disappears from PA's
> >>> profile.  You cannot switch back to analog output after that, even
> >>> after you unplug HDMI/DP cable.
> >>>
> >>> Or, it might be my PA version...  I'll check newer one.
> >>> But it'd be good if you also check in your side.
> >>
> >> Hmm.
> >>
> >> As you probably know, PA does extensively test opening device strings at 
> >> startup, and then never again.
> >> As such, I can understand that PA gets confused if you start adding and 
> >> removing PCM devices, because that changes whether and how different 
> >> device strings can be opened.
> >>
> >> Looking forward, with HDMI, it's a reality that this will happen. And 
> >> therefore we need to deal with it in PA somehow, even if this is 
> >> non-trivial. So the first question would be - what notification 
> >> mechanism should we have to trigger "reprobing"? Are we recommended to 
> >> use the jack detection kcontrol API, or is there something else that 
> >> tells us that suddenly "hdmi:1,2" will actually be worth trying again?
> > 
> > The kcontrol API is already implemented, so it's good to support for
> > it.
> 
> You refer ELD interface?

No, the jack detection kcontrols.

> > If we do check the dynamic PCM probing for HDMI, I'd propose for
> > adding a new PCM class SNDRV_PCM_CLASS_HDMI or such, and set this
> 
> I'm not sure if HDMI devices are different than others. For example, for
> digital S/PDIF inputs, the input stream parameters can change too
> including the signal presence. It would be good to propose one mechanism
> for all plug-and-play wiring schemas.

In that case, it's fine.  PA has no special treatment for such
devices.  (Or, it might face the same problem when it's listed as
"spdif".)

 From what I've seen, there is no big issue in the driver side at all
about dynamic creation/deletion of PCM streams.  All the problem is
about PA, and PA _is_ the reason we need a better hotplug PCM
handling.  So, you cannot think of any solution without considering
how PA would behave.

> > class in patch_hdmi.c.  Then PA can check the sysfs entry and
> > decide whether to reprobe the HDMI entry.
> 
> Please, could you describe more, why we need to have dynamic PCMs for
> HDMI?

It's not about "have to".  It's a possible solution for feasible HDMI
hotplug handling we've discussed since the last year's audio BoF.
As the same topic came up in Plumbers, I stated the patch just as a
proof-of-concept.

> I would prefer to have just a notification, if the cable is
> connected and the PCM layer is ready (ELD stuff). Also, if some physical
> connectors are not used on some hardware, they should/may be blacklisted
> so the driver won't create PCM devices for them.

Using kcontrol notifier is the current solution indeed.  But the whole
coding is missing in PA side, so far.  OTOH, PA has already the
handling of dynamic PCM device creation/deletion (e.g. for
USB-audio).  So, it can be more natural to provide the dynamic PCM
from the kernel for HDMI, too.  The patch was posted to evaluate
that.

> Also, the stream parameter checks seems missing in the HDMI PCM
> implementation. It may be good to fail with -EIO when the cable is not
> connected or unplugged and, eventually, if the end-point PCM parameters
> are changed.

Well, then PA will face a similar problem like this patch.
PA probes the available HDMI devices at start up.  If the device
returns an error -EIO at open when unplugged, PA will continue to
ignore the device.  It's what I understand.  I might be wrong about
that in the recent PA versions, though.

> If the dynamic HDMI PCMs are implemented, are the device numbers fixed
> (related) to physical connectors?

In my patch, it's still fixed.  Just creation is delayed and the slot
is kept.  But it's just my patch, and it doesn't correlate directly
with the idea of dynamic creation/deletion of PCM devices.


Takashi