Message-ID: <s5hiqm9pe1g.wl%tiwai@suse.de>
Date:	Mon, 16 Mar 2009 18:34:35 +0100
From:	Takashi Iwai <tiwai@...e.de>
To:	Andreas Mohr <andi@...as.de>
Cc:	Maxim Levitsky <maximlevitsky@...il.com>,
	linux-kernel@...r.kernel.org, alsa-devel@...a-project.org,
	Kernel Testers List <kernel-testers@...r.kernel.org>
Subject: Re: [alsa-devel] Bugs on aspire one A150

At Mon, 16 Mar 2009 18:30:00 +0100,
Andreas Mohr wrote:
> 
> Hi,
> 
> On Mon, Mar 16, 2009 at 06:15:39PM +0100, Takashi Iwai wrote:
> > 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.)
> 
> Yes, Capture Volume does influence i-Mic level.
> The Digital Capture control, however, doesn't influence level.
> As doesn't the Mic Boost Capture control (probably about e-Mic only?).

The "Digital Capture Volume" has effect only when "default" PCM is used.
If you record via "hw" or "plughw", it's unused.

> > > > > 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.
> 
> Oh, you mean "inverted" as in "_hardware_ channel which provides opposite
> sample values as compared to the other channel"?

Right.  My guess is that the hardware provides left (or right) channel
is multiplied by -1  (yep "inverted" is no correct word choice).

> > 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.
> 
> That exactly matches my current stream of thought (while reading
> "one channel is inverted" above).
> 
> > So we need to pass some information to change this kind of thing...
> 
> That's something specific to ALC268 codec setup, right?
> ("ALC268 digital mic == left plus right channel, but inverted setup"?)

No.  It's specific to the digital-mic side.


Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists