From patchwork Tue Mar 3 09:36:51 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ingo Brueckl X-Patchwork-Id: 5921081 Return-Path: X-Original-To: patchwork-alsa-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 9CDE8BF440 for ; Tue, 3 Mar 2015 10:33:53 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id A47A12026F for ; Tue, 3 Mar 2015 10:33:52 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) by mail.kernel.org (Postfix) with ESMTP id E037E2026C for ; Tue, 3 Mar 2015 10:33:50 +0000 (UTC) Received: by alsa0.perex.cz (Postfix, from userid 1000) id F31D72612AF; Tue, 3 Mar 2015 11:33:49 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 Received: from alsa0.perex.cz (localhost [IPv6:::1]) by alsa0.perex.cz (Postfix) with ESMTP id C7E8E2608CF; Tue, 3 Mar 2015 11:33:39 +0100 (CET) X-Original-To: alsa-devel@alsa-project.org Delivered-To: alsa-devel@alsa-project.org Received: by alsa0.perex.cz (Postfix, from userid 1000) id 99B272608ED; Tue, 3 Mar 2015 11:33:36 +0100 (CET) Received: from moutD.wup.tal.de (moutd.wup.tal.de [213.240.144.30]) by alsa0.perex.cz (Postfix) with ESMTP id B36682606CB for ; Tue, 3 Mar 2015 11:33:29 +0100 (CET) Received: from point.localnet (mue-88-130-96-087.dsl.tropolys.de [88.130.96.87]) (Authenticated sender: ib@wtal.de) by smtp.tal.de (Postfix) with ESMTPA id 2BD4E813CF68; Tue, 3 Mar 2015 11:33:29 +0100 (CET) Received: from ib by point.localnet with local (masqmail 0.2.21) id 1YSk8m-0nv-00; Tue, 03 Mar 2015 11:33:28 +0100 Message-ID: <54f58df6.3dd80617.bm000@wupperonline.de> From: =?ISO-8859-1?Q?Ingo=20Br=FCckl?= To: Raymond Yau Date: Tue, 03 Mar 2015 10:36:51 +0100 In-Reply-To: MIME-Version: 1.0 X-Mailer: blueMail/Linux 1.5 Cc: tiwai@suse.de, alsa-devel@alsa-project.org Subject: Re: [alsa-devel] Intel HDA / ALC662 analog surround problem X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" 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 X-Virus-Scanned: ClamAV using ClamSMTP Raymond, I'm not familiar with hardware, so I had some difficulties to understand what's going on here, but then I got really curious. So I grabbed an ALC662 datasheet and studied the block diagram. Now I think that I'm beginning to understand. >> >> > [ 0.655493] sound hdaudioC1D0: autoconfig: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:line >> >> > [ 0.655494] sound hdaudioC1D0: speaker_outs=1 (0x15/0x0/0x0/0x0/0x0) >> >> > [ 0.655495] sound hdaudioC1D0: hp_outs=1 (0x1b/0x0/0x0/0x0/0x0) >> >> > [ 0.655496] sound hdaudioC1D0: mono: mono_out=0x0 >> >> > [ 0.655496] sound hdaudioC1D0: dig-out=0x1e/0x0 >> >> > [ 0.655497] sound hdaudioC1D0: inputs: >> >> > [ 0.655498] sound hdaudioC1D0: Front Mic=0x19 >> >> > [ 0.655499] sound hdaudioC1D0: Rear Mic=0x18 >> >> > [ 0.655499] sound hdaudioC1D0: Line=0x1a >> >> >> >> > This is a known bug of hda_generic.c for those desktop with internal >> >> > speaker and three audio jacks at rear panel (e.g. those lenovo >> >> > thinkcenter with alc66x codec) >> >> >> >> > The driver prefer to assign volume control/dac to headphone, line out and >> >> > internal speaker instead of line out and the other two multi io jacks >> >> > or You need to increase BAD_MULTI_IO from 0x120 to 0x4120 since >> > BAD_NO_DAC 0x4000 for the driver to select config with mio=1 >> >==> lo_type=0, wired=1, mio=1, badness=0x352 > multi_outs = 14/0/0/0 : 2/0/0/0 (type LO) > out path: depth=3 '02:0c:14' > hp_outs = 1b/0/0/0 : 2/0/0/0 > hp path: depth=3 '02:0c:1b' > spk_outs = 15/0/0/0 : 3/0/0/0 > spk path: depth=3 '03:0d:15' >==> lo_type=0, wired=1, mio=0, badness=0x120 > multi_outs = 14/0/0/0 : 2/0/0/0 (type LO) > out path: depth=3 '02:0c:14' > hp_outs = 1b/0/0/0 : 4/0/0/0 > hp path: depth=3 '04:0e:1b' > spk_outs = 15/0/0/0 : 3/0/0/0 > spk path: depth=3 '03:0d:15' > send: NID=0x18, VERB=0xf00(get_parameters), PARM=0x12(amp_out_cap) > receive: 0x80000000 >==> lo_type=0, wired=0, mio=1, badness=0x4112 > multi_outs = 14/0/0/0 : 2/3/4/0 (type LO) > out path: depth=3 '02:0c:14' > multi_ios(2) = 1a/18 : 3/4 > mio path: depth=3 '03:0d:1a' > mio path: depth=3 '04:0e:18' > hp_outs = 1b/0/0/0 : 2/0/0/0 > hp path: depth=3 '02:0c:1b' > spk_outs = 15/0/0/0 : 0/0/0/0 >==> lo_type=0, wired=0, mio=0, badness=0x4120 > multi_outs = 14/0/0/0 : 2/0/0/0 (type LO) > out path: depth=3 '02:0c:14' > hp_outs = 1b/0/0/0 : 3/0/0/0 > hp path: depth=3 '03:0d:1b' > spk_outs = 15/0/0/0 : 0/0/0/0 >==> restoring best_cfg >==> Best config: lo_type=0, wired=1, mio=0 > multi_outs = 14/0/0/0 : 2/0/0/0 (type LO) > out path: depth=3 '02:0c:14' > hp_outs = 1b/0/0/0 : 4/0/0/0 > hp path: depth=3 '04:0e:1b' > spk_outs = 15/0/0/0 : 3/0/0/0 > spk path: depth=3 '03:0d:15' > The current driver select config with smallest badness > You need an ad hoc check of increasing the badness due to multi io cannot > be assigned for those realtek alc66x codecs with 3stack and internal > speaker I think I've figured out how to safely perform a private kernel patch for it. Now I'm getting the favored config: ==> lo_type=0, wired=1, mio=1, badness=0x352 multi_outs = 14/0/0/0 : 2/0/0/0 (type LO) hp_outs = 1b/0/0/0 : 2/0/0/0 spk_outs = 15/0/0/0 : 3/0/0/0 ==> lo_type=0, wired=1, mio=0, badness=0x120 multi_outs = 14/0/0/0 : 2/0/0/0 (type LO) hp_outs = 1b/0/0/0 : 4/0/0/0 spk_outs = 15/0/0/0 : 3/0/0/0 ==> lo_type=0, wired=0, mio=1, badness=0x112 multi_outs = 14/0/0/0 : 2/3/4/0 (type LO) multi_ios(2) = 1a/18 : 3/4 hp_outs = 1b/0/0/0 : 2/0/0/0 spk_outs = 15/0/0/0 : 0/0/0/0 ==> lo_type=0, wired=0, mio=0, badness=0x120 multi_outs = 14/0/0/0 : 2/0/0/0 (type LO) hp_outs = 1b/0/0/0 : 3/0/0/0 spk_outs = 15/0/0/0 : 0/0/0/0 ==> restoring best_cfg ==> Best config: lo_type=0, wired=0, mio=1 multi_outs = 14/0/0/0 : 2/3/4/0 (type LO) multi_ios(2) = 1a/18 : 3/4 hp_outs = 1b/0/0/0 : 2/0/0/0 spk_outs = 15/0/0/0 : 0/0/0/0 > > The master volume control affects the line out volume (which is named PCM, > > btw), but no other output. Muting the master, however, affects all outputs. > > > > After changing to 4ch or 6ch, the PCM (line out) volume control acts as a > > "master" for surround and center/lfe. > Seem "master playback volume" is not the correct name when using surround > 5.1 and your config lost the virtual master playback volume It seems that this is fixable. Patch will follow. By the way, there is one thing I still don't understand. After booting there is no "PCM Playback Volume" control in alsamixer. As soon as I've played some wav file, it appears. Where does it come from, i.e. is it created by kernel or alsa-lib/utils and why? Ingo diff -Nur a/sound/pci/hda/hda_generic.c b/sound/pci/hda/hda_generic.c --- a/sound/pci/hda/hda_generic.c 2015-02-11 08:01:12.000000000 +0100 +++ b/sound/pci/hda/hda_generic.c 2015-03-02 22:57:34.799192329 +0100 @@ -1233,7 +1233,8 @@ dac = spec->private_dac_nids[0]; badness += bad->shared_surr_main; } else if (!i) - badness += bad->no_primary_dac; + /* no additional badness for 0x15 (speaker) without DAC (during multi-io check) */ + badness += pin == 0x15 ? 0 : bad->no_primary_dac; else badness += bad->no_dac; }