From owner-freebsd-multimedia@FreeBSD.ORG Wed Aug 13 15:09:47 2008 Return-Path: Delivered-To: freebsd-multimedia@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C732106568B for ; Wed, 13 Aug 2008 15:09:47 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id D43658FC2E for ; Wed, 13 Aug 2008 15:09:46 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.1.14) with ESMTPSA id 193814581; Wed, 13 Aug 2008 18:09:45 +0300 Message-ID: <48A2F930.3010908@FreeBSD.org> Date: Wed, 13 Aug 2008 18:09:36 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.16 (X11/20080726) MIME-Version: 1.0 To: Andriy Gapon References: <53a1e0710808130628t451c5e87n28adb7d01b03dfd4@mail.gmail.com> <48A2E5DA.4060203@FreeBSD.org> <48A2E8D6.10806@icyb.net.ua> <48A2ED4A.6060606@icyb.net.ua> In-Reply-To: <48A2ED4A.6060606@icyb.net.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-multimedia@FreeBSD.org Subject: Re: RFC: massive snd_hda driver update to better conform UAA X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2008 15:09:47 -0000 Andriy Gapon wrote: > on 13/08/2008 16:59 Andriy Gapon said the following: >> Alexander, >> >> I've tried a slightly tweaked version of your releng_7 patch on 6.3. >> It seems that with your patch recording stopped working for me, but >> everything else is OK. >> >> From (non-verbose) dmesg: >> hdac0: mem >> 0xfe024000-0xfe027fff irq 22 at device 16.1 on pci0 >> hdac0: >> hdac0: >> hdac0: hdac_widget_connection_parse: nid=18 WARNING: zero cnid entnum=4 >> j=2 index=0 entries=8 found=2 res=0x21002211 >> hdac0: hdac_audio_as_parse: Pin 28 has wrong direction for association >> 1! Disabling association. >> hdac0: hdac_audio_as_parse: Pin 29 has wrong direction for association >> 1! Disabling association. >> pcm0: on hdac0 >> pcm1: on hdac0 Here is an answer: > nid 27 0x01014011 as 1 seq 1 Line out Jack jack 1 loc 1 color > Green misc 0 > nid 28 0x01813012 as 1 seq 2 Line in Jack jack 1 loc 1 color > Blue misc 0 > nid 29 0x01a19015 as 1 seq 5 Mic in Jack jack 1 loc 1 color > Pink misc 0 pin 27 configured as output while 28 and 29 as inputs Pin 27 is output only so we can't configure it as input. > Parsing pin associations... > hdac_audio_as_parse: Pin 28 has wrong direction for association 1! > Disabling association. > hdac_audio_as_parse: Pin 29 has wrong direction for association 1! > Disabling association. > 7 associations found > Association 1 out (disabled): > Pin nid=27 seq=1 > Pin nid=28 seq=2 > Pin nid=29 seq=5 But they've used in same assignment. So we can: 1. change assignment numbers and get recording from two pins and playback via the third. 2. remove quirks and let BIOS configure those pins as 6 channel output, but then you will probably loose headphone output as soon as there is only three stereo DACs in codec and no HP redirection configured by BIOS. hdac0: Association 1 out (disabled): hdac0: Pin nid=27 seq=1 <- this was going to be 5.1 out hdac0: Pin nid=28 seq=2 hdac0: Pin nid=29 seq=5 hdac0: Association 2 out: hdac0: Pin nid=26 seq=1 <- this was going to be HP 3. if HP redirection supported it can be enabled in addition to 2 4. There is a lot of different recording sources configured, hdac0: Association 15 in: hdac0: Pin nid=31 seq=0 hdac0: Association 15 in: hdac0: Pin nid=32 seq=0 hdac0: Association 15 in: hdac0: Pin nid=34 seq=0 hdac0: Association 15 in: but as soon as there is only one ADC present they are not working. It may be possible to join them together to use with same ADC. >> I can see that current (non-patched) code has the following quirks for >> the above two pins with my codec and my subvendor (ASUS M2NPV-MX >> motherboard): >> >> } else if (id == HDA_CODEC_AD1986A && >> (sc->pci_subvendor == ASUS_M2NPVMX_SUBVENDOR || >> sc->pci_subvendor == ASUS_A8NVMCSM_SUBVENDOR)) { >> switch (nid) { >> case 28: /* LINE */ >> config &= ~HDA_CONFIG_DEFAULTCONF_DEVICE_MASK; >> config |= HDA_CONFIG_DEFAULTCONF_DEVICE_LINE_IN; >> break; >> case 29: /* MIC */ >> config &= ~HDA_CONFIG_DEFAULTCONF_DEVICE_MASK; >> config |= HDA_CONFIG_DEFAULTCONF_DEVICE_MIC_IN; >> break; >> default: >> break; >> } >> } > > The above code is still there after the patch, but the following is gone: > case HDA_CODEC_AD1986A: That is a problem. We must decide what to do with it. It is incorrect and must be revised. > if (subvendor == ASUS_M2NPVMX_SUBVENDOR || > subvendor == ASUS_A8NVMCSM_SUBVENDOR) { > /* nid 28 is mic, nid 29 is line-in */ > w = hdac_widget_get(devinfo, 15); > if (w != NULL) > w->selconn = 2; > w = hdac_widget_get(devinfo, 16); > if (w != NULL) > w->selconn = 1; It was workaround for double stage multiplexing used in this codec. It is dirty hack, so I have removed it. New driver still lack of this setup support so depending on configuration you may still not get those inputs working. I am thinking about that now. -- Alexander Motin