On Mon, Mar 16, 2009 at 06:34:35PM +0100, Takashi Iwai wrote:
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:
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.
I just tried connecting a headset and switching to E-Mic. What I can say is: - opposite levels does NOT happen there (E-Mic is "analog micro"-based, right?) - leaving E-Mic unplugged will actually record from i-Mic (due to properly working EAPD mechanism, right?)
BTW, the output (of arecord -Dplughw:0 -c2 -traw -fdat foo.wav) _does_ have inverted channels:
00000130 2A 02 D2 FD 65 02 A5 FD 10 00 E7 FF 99 FF 72 00 *...e.........r. 00000140 53 FE A7 01 ED FF 12 00 4F FF A6 00 86 00 81 FF S.......O....... ... and so on in the entire file ...
One question still: is this a hardware defect (i.e. could this possibly be swapped cables of the microphone connector in this model or so? Not plausible but...), or is this an existing property of the HDA's dig-mic base? You indicated it's the latter I think...
Andreas