From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760008AbZCPRPw (ORCPT ); Mon, 16 Mar 2009 13:15:52 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754837AbZCPRPn (ORCPT ); Mon, 16 Mar 2009 13:15:43 -0400 Received: from cantor.suse.de ([195.135.220.2]:51472 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754440AbZCPRPm (ORCPT ); Mon, 16 Mar 2009 13:15:42 -0400 Date: Mon, 16 Mar 2009 18:15:39 +0100 Message-ID: From: Takashi Iwai To: Andreas Mohr Cc: Maxim Levitsky , linux-kernel@vger.kernel.org, alsa-devel@alsa-project.org, Kernel Testers List Subject: Re: [alsa-devel] Bugs on aspire one A150 In-Reply-To: <20090316170015.GA9776@rhlx01.hs-esslingen.de> References: <20090316133001.GA8437@rhlx01.hs-esslingen.de> <20090316143158.GA12725@rhlx01.hs-esslingen.de> <20090316145036.GA26358@rhlx01.hs-esslingen.de> <20090316160208.GB4458@rhlx01.hs-esslingen.de> <20090316170015.GA9776@rhlx01.hs-esslingen.de> User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.3 (x86_64-suse-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-2022-JP Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org At Mon, 16 Mar 2009 18:00:15 +0100, Andreas Mohr wrote: > > Hi, > > On Mon, Mar 16, 2009 at 05:19:38PM +0100, Takashi Iwai wrote: > > At Mon, 16 Mar 2009 17:06:35 +0100, > > 私 wrote: > > > > > > > > What are "sliders"? > > > > > > > > Umm, volume level controls. > > > > > > Yes but there are many of such :) > > > > > > More exactly, from the driver perspective, there are no volume > > > controls but only there are control elements with integer values. > > > Do you mean "Capture Volume" control or which one? > > Hmm, ok, this needs to be more precise: > In gamix (codec "HDA Intel : Realtek ALC268"), the Capture Volume control. Yeah, that's more understandable :) BTW, does "Capture Volume" influence on the recording level even for the built-in mic, right? I'm asking this because the digital mic on STAC/IDT codecs isn't controlled via "Capture Volume" control that is bound to an ADC widget. (That's why "Digital Capture Volume" control exists. It's a value used by alsa-lib softvol plugin for "default" PCM.) > > > And, is the behavior consistent regardless of the value high, i.e. > > > the key is only whether the values for both channels are identical? > > > > BTW, what if you record with the following definition? > > Put the below to ~/.asoundrc > > > > pcm.imix { > > type plug > > slave.pcm "hw" > > ttable.0.0 0.5 > > ttable.0.1 -0.5 > > } > > > > and record like > > > > % aplay -Dimix -c1 foo.wav > > Does NOT exhibit the "equal sliders == no sound" bug (apart from this sliders > are acting normally, i.e. slider low == no sound), despite being a > "plug" type definition (this is what you wanted to discern, right? ;). Interesting. This implies that one channel is inverted indeed. As default the alsa-lib plugin downmixes a stereo stream to a mono stream simply by left/2 + right/2. The above changes the routing policy as left/2 - right/2. So we need to pass some information to change this kind of thing... But a question still remains; why conversion with sox worked. Maybe it didn't mix? Or, the code alsa-lib could be buggy... A simple test would be to just sum all 16bit samples in a stereo stream file externally. That is, first record a RAW file via % arecord -Dhw -traw -fdat foo.dat Then create a mono stream just do 16bit left/2 + right/2 calculation by any way (a good homework for kids :). Is it also problematic? thanks, Takashi From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: Bugs on aspire one A150 Date: Mon, 16 Mar 2009 18:15:39 +0100 Message-ID: References: <20090316133001.GA8437@rhlx01.hs-esslingen.de> <20090316143158.GA12725@rhlx01.hs-esslingen.de> <20090316145036.GA26358@rhlx01.hs-esslingen.de> <20090316160208.GB4458@rhlx01.hs-esslingen.de> <20090316170015.GA9776@rhlx01.hs-esslingen.de> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20090316170015.GA9776@rhlx01.hs-esslingen.de> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: alsa-devel-bounces@alsa-project.org Errors-To: alsa-devel-bounces@alsa-project.org To: Andreas Mohr Cc: alsa-devel@alsa-project.org, Kernel Testers List , Maxim Levitsky , linux-kernel@vger.kernel.org At Mon, 16 Mar 2009 18:00:15 +0100, Andreas Mohr wrote: > > Hi, > > On Mon, Mar 16, 2009 at 05:19:38PM +0100, Takashi Iwai wrote: > > At Mon, 16 Mar 2009 17:06:35 +0100, > > 私 wrote: > > > > > > > > What are "sliders"? > > > > > > > > Umm, volume level controls. > > > > > > Yes but there are many of such :) > > > > > > More exactly, from the driver perspective, there are no volume > > > controls but only there are control elements with integer values. > > > Do you mean "Capture Volume" control or which one? > > Hmm, ok, this needs to be more precise: > In gamix (codec "HDA Intel : Realtek ALC268"), the Capture Volume control. Yeah, that's more understandable :) BTW, does "Capture Volume" influence on the recording level even for the built-in mic, right? I'm asking this because the digital mic on STAC/IDT codecs isn't controlled via "Capture Volume" control that is bound to an ADC widget. (That's why "Digital Capture Volume" control exists. It's a value used by alsa-lib softvol plugin for "default" PCM.) > > > And, is the behavior consistent regardless of the value high, i.e. > > > the key is only whether the values for both channels are identical? > > > > BTW, what if you record with the following definition? > > Put the below to ~/.asoundrc > > > > pcm.imix { > > type plug > > slave.pcm "hw" > > ttable.0.0 0.5 > > ttable.0.1 -0.5 > > } > > > > and record like > > > > % aplay -Dimix -c1 foo.wav > > Does NOT exhibit the "equal sliders == no sound" bug (apart from this sliders > are acting normally, i.e. slider low == no sound), despite being a > "plug" type definition (this is what you wanted to discern, right? ;). Interesting. This implies that one channel is inverted indeed. As default the alsa-lib plugin downmixes a stereo stream to a mono stream simply by left/2 + right/2. The above changes the routing policy as left/2 - right/2. So we need to pass some information to change this kind of thing... But a question still remains; why conversion with sox worked. Maybe it didn't mix? Or, the code alsa-lib could be buggy... A simple test would be to just sum all 16bit samples in a stereo stream file externally. That is, first record a RAW file via % arecord -Dhw -traw -fdat foo.dat Then create a mono stream just do 16bit left/2 + right/2 calculation by any way (a good homework for kids :). Is it also problematic? thanks, Takashi