From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: DP1.2 MST audio support discussion Date: Wed, 11 Nov 2015 09:05:33 +0100 Message-ID: References: <96A12704CE18D347B625EE2D4A099D1974C250@SHSMSX103.ccr.corp.intel.com> <96A12704CE18D347B625EE2D4A099D1975281F@SHSMSX103.ccr.corp.intel.com> <56288783.1080503@canonical.com> <96A12704CE18D347B625EE2D4A099D19753A2D@SHSMSX103.ccr.corp.intel.com> <56288FF7.9030400@canonical.com> <96A12704CE18D347B625EE2D4A099D19753A91@SHSMSX103.ccr.corp.intel.com> <5628A3EB.8050306@canonical.com> <562A1237.2090909@canonical.com> <96A12704CE18D347B625EE2D4A099D19755BE7@SHSMSX103.ccr.corp.intel.com> <96A12704CE18D347B625EE2D4A099D197574CE@SHSMSX103.ccr.corp.intel.com> <563716D7.3000502@canonical.com> <96A12704CE18D347B625EE2D4A099D19765611@SHSMSX103.ccr.corp.intel.com> <563B1C37.4010400@canonical.com> <96A12704CE18D347B625EE2D4A099D197786EB@SHSMSX103.ccr.corp.intel.com> <5641A088.50609@canonical.com> <96A12704CE18D347B625EE2D4A099D19778A43@SHSMSX103.ccr.corp.intel.com> <96A12704CE18D347B625EE2D4A099D19779C61@SHSMSX103.ccr.corp.intel.com> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by alsa0.perex.cz (Postfix) with ESMTP id 836DE26059E for ; Wed, 11 Nov 2015 09:05:34 +0100 (CET) In-Reply-To: <96A12704CE18D347B625EE2D4A099D19779C61@SHSMSX103.ccr.corp.intel.com> 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: "Yang, Libin" Cc: 'ALSA Development Mailing List' , "'airlied@linux.ie'" , "Lin, Mengdong" , "Nikula, Jani" , "Girdwood, Liam R" , "Lu, Han" , 'Raymond Yau' , "'tanuk@iki.fi'" , 'David Henningsson' List-Id: alsa-devel@alsa-project.org On Wed, 11 Nov 2015 08:58:29 +0100, Yang, Libin wrote: > > > > -----Original Message----- > > From: Yang, Libin > > Sent: Wednesday, November 11, 2015 10:04 AM > > To: David Henningsson; Takashi Iwai > > Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi; ALSA > > Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula, Jani > > Subject: RE: [alsa-devel] DP1.2 MST audio support discussion > > > > > > > -----Original Message----- > > > From: David Henningsson [mailto:david.henningsson@canonical.com] > > > Sent: Tuesday, November 10, 2015 3:45 PM > > > To: Yang, Libin; Takashi Iwai > > > Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi; ALSA > > > Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula, Jani > > > Subject: Re: [alsa-devel] DP1.2 MST audio support discussion > > > > > > > > > > > > On 2015-11-10 07:46, Yang, Libin wrote: > > > > Hi David, > > > > > > > > > > > >> -----Original Message----- > > > >> From: David Henningsson > > [mailto:david.henningsson@canonical.com] > > > >> Sent: Thursday, November 05, 2015 5:07 PM > > > >> To: Yang, Libin; Takashi Iwai > > > >> Cc: Lin, Mengdong; Raymond Yau; airlied@linux.ie; tanuk@iki.fi; > > ALSA > > > >> Development Mailing List; Girdwood, Liam R; Lu, Han; Nikula, Jani > > > >> Subject: Re: [alsa-devel] DP1.2 MST audio support discussion > > > >> > > > >> > > > >> > > > >> So I'm asking my question again. What would happen (on Intel > > > hardware), > > > >> if you stream audio to a converter node on the audio codec, and > > there > > > is > > > >> no pin node connected to that converter node? > > > > > > > > I changed the audio driver and did the test today. The test is: > > > > 1. Pin 5 connect to converter 2 and playback, there is sound from pin > > 5. > > > > 2. Pin 5 connect to converter 2 (no other pin is connected to cvt2), no > > > sound. > > > > 3. Pin 5 connect back to cvt 2, there is sound, playback is normal. > > > > > > > > And in step 2, the playback is still ongoing but no sound is out from > > any > > > pin. > > > > > > Sounds good to me, thanks for testing. Is this workaround something > > we > > > could utilize in order to not break userspace? (This is a question for > > > both you and Takashi.) > > > > > > What we'll end up is essentially three types of objects: > > > > > > * PCM device (5 devices, 3,7,8,9,10) > > > - all five devices are allocated when the driver initializes > > > > This should be for Intel platform, right? The actually number > > should be: > > pin number + device entry number - 1. > > On intel platform, pin_num = 3, dev_num = 3, so it will be 5. > > > > > - all kcontrols are always bound to the PCM device (jack kctl, eld > > > kctl, iec958 kctls etc) > > > > Sure, I agree on it. > > > > > > > > * Monitor (pin + MST index) > > > - dynamically bound to a PCM at monitor plug-in time, according to a > > > scheme that maximises the possibility for a monitor to always end up at > > > the same PCM (as specified in earlier emails) > > > > > > * Converter node (3 nodes for Intel hardware) > > > - dynamically bound to a PCM at playback open time (regardless of > > > whether the PCM has a monitor or not) > > > > If so, we still need use converter on codec. This means we can't turn > > off the power well in i915. > > > > To save the power, i915 suggests that if no monitor is connected, > > we should not use the HDMI codec. This means open a PCM with > > no pin attached will fail. Disconnecting monitor when the corresponding > > PCM is playback will trigger stop PCM. > > > > To help move to the new method smoothly, I will add a flag. > > User can decide whether to use the aggressive power saving > > solution or not. > > In hdmi_pcm_open(), it will judge whether pin_idx is valid, > if not it will return -EINVAL. So for dynamic PCM assignment, > open will fail if no monitor is connected. > > If we want to support open on PCM without monitor, many > code must be rewrited. And it seems open a PCM without > monitor is not a good behavior. As Raymond said in previous > email, For alt analog playback device , it return EBUSY when > DAC of HP is not available. I think for HDMI audio we can > have the aligned behavior? And -ENODEV may be better. Libin, it's why I've been repeated asking to split the patches, instead of posting a big iron patch. Then we can test and evaluate whether this part is really working in general. Takashi