[alsa-devel] Dynamic HDMI PCM creation

[Jaroslav Kysela]

Date 17.9.2012 13:46, Takashi Iwai wrote:
> 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.

Yep, ok.

>>> 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.

I believe we should do it in one consistent way. The kctl wire status
report / jack presence report should be sufficient to detect, if the PCM
device can be re-probed. I don't understand why to do more work in the
driver, because the user space application is broken or lacking a feature.

>>> 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.

I think that USB-Audio is a different thing. Our driver creates new card
for a newly plugged USB hardware and it seems that PA supports only
dynamic card handling, not dynamic device handling.

>> 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.

I believe that PA should be fixed. For me, it seems unlogical to feed a
stream to hardware which is silent, because the stream parameters do not
match or the wire is not connected.

>> 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.

OK, fine.

					Jaroslav

-- 
Jaroslav Kysela <perex at perex.cz>
Linux Kernel Sound Maintainer
ALSA Project; Red Hat, Inc.