From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jaroslav Kysela Subject: Re: Dynamic HDMI PCM creation Date: Mon, 17 Sep 2012 14:20:38 +0200 Message-ID: <50571596.8000207@perex.cz> References: <5056F83B.7080602@canonical.com> <5057039C.50906@perex.cz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail1.perex.cz (mail1.perex.cz [77.48.224.245]) by alsa0.perex.cz (Postfix) with ESMTP id DCBAB2616AB for ; Mon, 17 Sep 2012 14:20:38 +0200 (CEST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Takashi Iwai Cc: alsa-devel@alsa-project.org List-Id: alsa-devel@alsa-project.org 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 Linux Kernel Sound Maintainer ALSA Project; Red Hat, Inc.