Re: [alsa-devel] Bugs on aspire one A150
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.
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? ;).
Thanks!
Andreas
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
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?).
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"?
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"?)
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?
OK, I know what you're up to, I'll do this external proof ASAP, will take a couple more minutes.
Andreas
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
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
At Mon, 16 Mar 2009 19:06:38 +0100, Andreas Mohr wrote:
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?)
The record from mic-jack is via analog path. The phase-inversion appears only for digital-mic, AFAIK.
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...
My guess is that it's a hardware implementation. Maybe for the noise suppression via mic array.
The question is whether the left / right channels recorded from digital mic are really raw data, or they are for modified data (for differential, etc)... It's hard to guess without the actual data.
Takashi
Hi,
On Mon, Mar 16, 2009 at 09:28:39PM +0100, Takashi Iwai wrote:
At Mon, 16 Mar 2009 19:06:38 +0100, Andreas Mohr wrote:
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?)
The record from mic-jack is via analog path. The phase-inversion appears only for digital-mic, AFAIK.
Thought so.
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...
My guess is that it's a hardware implementation. Maybe for the noise suppression via mic array.
Not sure what this means.
The question is whether the left / right channels recorded from digital mic are really raw data, or they are for modified data (for differential, etc)... It's hard to guess without the actual data.
I don't quite follow you here. Is there anything I could do about this?
Thanks,
Andreas
On Mon, 2009-03-16 at 22:22 +0100, Andreas Mohr wrote:
Hi,
On Mon, Mar 16, 2009 at 09:28:39PM +0100, Takashi Iwai wrote:
At Mon, 16 Mar 2009 19:06:38 +0100, Andreas Mohr wrote:
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?)
The record from mic-jack is via analog path. The phase-inversion appears only for digital-mic, AFAIK.
Thought so.
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...
My guess is that it's a hardware implementation. Maybe for the noise suppression via mic array.
Not sure what this means.
The question is whether the left / right channels recorded from digital mic are really raw data, or they are for modified data (for differential, etc)... It's hard to guess without the actual data.
I don't quite follow you here. Is there anything I could do about this?
Thanks,
Andreas
What about exposing the i-mic as a mono only device to userspace? It is mono after all?
Best regards, Maxim Levitsky
At Tue, 17 Mar 2009 02:52:19 +0200, Maxim Levitsky wrote:
On Mon, 2009-03-16 at 22:22 +0100, Andreas Mohr wrote:
Hi,
On Mon, Mar 16, 2009 at 09:28:39PM +0100, Takashi Iwai wrote:
At Mon, 16 Mar 2009 19:06:38 +0100, Andreas Mohr wrote:
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?)
The record from mic-jack is via analog path. The phase-inversion appears only for digital-mic, AFAIK.
Thought so.
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...
My guess is that it's a hardware implementation. Maybe for the noise suppression via mic array.
Not sure what this means.
The question is whether the left / right channels recorded from digital mic are really raw data, or they are for modified data (for differential, etc)... It's hard to guess without the actual data.
I don't quite follow you here. Is there anything I could do about this?
Thanks,
Andreas
What about exposing the i-mic as a mono only device to userspace? It is mono after all?
No, it's a mic-array. And HD-audio cannot handle a mono stream.
Takashi
On Tue, 2009-03-17 at 08:57 +0100, Takashi Iwai wrote:
At Tue, 17 Mar 2009 02:52:19 +0200, Maxim Levitsky wrote:
On Mon, 2009-03-16 at 22:22 +0100, Andreas Mohr wrote:
Hi,
On Mon, Mar 16, 2009 at 09:28:39PM +0100, Takashi Iwai wrote:
At Mon, 16 Mar 2009 19:06:38 +0100, Andreas Mohr wrote:
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?)
The record from mic-jack is via analog path. The phase-inversion appears only for digital-mic, AFAIK.
Thought so.
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...
My guess is that it's a hardware implementation. Maybe for the noise suppression via mic array.
Not sure what this means.
The question is whether the left / right channels recorded from digital mic are really raw data, or they are for modified data (for differential, etc)... It's hard to guess without the actual data.
I don't quite follow you here. Is there anything I could do about this?
Thanks,
Andreas
What about exposing the i-mic as a mono only device to userspace? It is mono after all?
No, it's a mic-array. And HD-audio cannot handle a mono stream.
No problem. Lets just lie to usespace that it is mono, in kernel driver can pick one of channels?
Maybe this is an array, but this doesn't explain the 'quality' of it. It is so low (in windows too).
Best regards, Maxim Levitsky
At Tue, 17 Mar 2009 13:30:12 +0200, Maxim Levitsky wrote:
On Tue, 2009-03-17 at 08:57 +0100, Takashi Iwai wrote:
At Tue, 17 Mar 2009 02:52:19 +0200, Maxim Levitsky wrote:
On Mon, 2009-03-16 at 22:22 +0100, Andreas Mohr wrote:
Hi,
On Mon, Mar 16, 2009 at 09:28:39PM +0100, Takashi Iwai wrote:
At Mon, 16 Mar 2009 19:06:38 +0100, Andreas Mohr wrote:
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?)
The record from mic-jack is via analog path. The phase-inversion appears only for digital-mic, AFAIK.
Thought so.
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...
My guess is that it's a hardware implementation. Maybe for the noise suppression via mic array.
Not sure what this means.
The question is whether the left / right channels recorded from digital mic are really raw data, or they are for modified data (for differential, etc)... It's hard to guess without the actual data.
I don't quite follow you here. Is there anything I could do about this?
Thanks,
Andreas
What about exposing the i-mic as a mono only device to userspace? It is mono after all?
No, it's a mic-array. And HD-audio cannot handle a mono stream.
No problem. Lets just lie to usespace that it is mono, in kernel driver can pick one of channels?
No, the hardware provides only the stereo streams, so the driver, too.
The downmixing is the job of the user-space. For example, try the patch to alsa-lib I sent in my previous post.
Maybe this is an array, but this doesn't explain the 'quality' of it. It is so low (in windows too).
Properly using the mic-array would reduce the noise fairly well. XP has no mic-array support, IIRC.
Of course, it's possible that Aspire* have badly equipped mic arrays that don't help much noise suppression...
Takashi
At Mon, 16 Mar 2009 22:22:27 +0100, Andreas Mohr wrote:
Hi,
On Mon, Mar 16, 2009 at 09:28:39PM +0100, Takashi Iwai wrote:
At Mon, 16 Mar 2009 19:06:38 +0100, Andreas Mohr wrote:
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?)
The record from mic-jack is via analog path. The phase-inversion appears only for digital-mic, AFAIK.
Thought so.
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...
My guess is that it's a hardware implementation. Maybe for the noise suppression via mic array.
Not sure what this means.
The question is whether the left / right channels recorded from digital mic are really raw data, or they are for modified data (for differential, etc)... It's hard to guess without the actual data.
I don't quite follow you here. Is there anything I could do about this?
The mic array on a laptop is used for beam forming and noise suppressions. These require the software manipulation, of course. The question is what kind of data is read from the hardware. Thus, providing the raw streams for both mic inputs makes sense.
Obviously the stream read from the codec chip is a PCM while usually the digital mic gives the output as PDM. So PDM -> PCM isn't needed here. But, still a question is why a phase inversion in the second channel. Whether it's intentional (e.g. to make the further conversion easier) or not.
Would be interesting if you can figure out which digital-mic component is used on your laptop (and if we can have any chip information by luck).
Takashi
Hi,
On Tue, Mar 17, 2009 at 08:57:06AM +0100, Takashi Iwai wrote:
At Mon, 16 Mar 2009 22:22:27 +0100, Andreas Mohr wrote:
Hi,
On Mon, Mar 16, 2009 at 09:28:39PM +0100, Takashi Iwai wrote:
The question is whether the left / right channels recorded from digital mic are really raw data, or they are for modified data (for differential, etc)... It's hard to guess without the actual data.
I don't quite follow you here. Is there anything I could do about this?
The mic array on a laptop is used for beam forming and noise suppressions. These require the software manipulation, of course. The question is what kind of data is read from the hardware. Thus, providing the raw streams for both mic inputs makes sense.
Makes sense indeed.
Obviously the stream read from the codec chip is a PCM while usually the digital mic gives the output as PDM. So PDM -> PCM isn't needed here. But, still a question is why a phase inversion in the second channel. Whether it's intentional (e.g. to make the further conversion easier) or not.
Would be interesting if you can figure out which digital-mic component is used on your laptop (and if we can have any chip information by luck).
Well, as some manufacturers/types of digital microphones I found Akustica (AKU 1126 / 2000 / 2001 / 2002 / 2004 / 2103), Analog Devices (ADMP421), National Semiconductor (digital microphones, amplifiers LMV1024, LMV1026) [1], [2], [3] and Andrea Digital Array Microphones.
ALC268 specs [4] say that they actually support interfacing LMV1024/1026, SPD0205ND (what the heck is this one?), AKU2000.
Umm wait, Aspire One has ALC269. ALC269 datasheet doesn't say anything about microphone manufacturers.
Note that eeepc models 901++ have ALC269 as well and - surprise, surprise - an inverted noise cancellation issue as well!!!!!: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/331130
"Dreamcom 10 Laptop" [7]: " integrated Realtek HD audio processor, two built-in Akustica digital microphones and two built-in stereo speakers"
This was the only reference up and down that I could find to _any_ notebook's microphone manufacturer listing. I suspect that Aspire One has an Akustica microphone array as well since Akustica seems to be the leading brand (hmm, any ideas about where the second microphone is located if at all existing, but it must exist!!? - probably at the front bottom?). Note that I found that the 16bit inverted data is NOT exactly a sum of 0x10000, IOW those _are_ two _separate_, inverted streams of audio data (for noise cancellation somehow I guess). OH WAIT!! If most Acer models have _both_ microphones at the screen bezel (left and right side) yet Aspire One has them (as I'd guess) at the top of the bezel (known) and at the front bottom, then this would mean - hold your breath - that the microphone array's physical properties (regarding noise cancellation) are moved by 90 degrees, possibly exactly explaining the malfunctioning (this would explain why Aspire One and eeepcs have issues whereas other Aspire models probably don't have them!?!?). Hmm OTOH providing an audio source from somewhere on the left side / right side of the netbook doesn't suddenly provide any audio, thus it's probably a nice theory ;) But OTOH the fact remains that those netbooks have a drastic microphone geometry design change versus the normal Acer notebooks, thus it likely is the reason for this issue somehow, somewhere.
Another very widely used brochure phrase was "Acer PureZone technology with two built-in stereo microphones featuring beam forming, echo cancellation, and noise suppression technologies" I couldn't locate more pointers to details here though.
Insightful Apple OS X ALC269 adaptation descriptions: [5].
Windows Vista (ick!) microphone array discussions: [6].
[1]. http://www.national.com/nationaledge/apr03/article.html (background explanations!) [2]. https://www.national.com/appinfo/amps/microphone.html [3]. http://www.national.com/GER/news/item/1,4300,50,00.html [4]. https://nmso.mdg.ca/specsheets/Intel_ALC268_Sound.pdf [5]. http://ipis-osx.wikidot.com/internal-sound [6]. http://windowsteamblog.com/blogs/windowsvista/archive/2007/11/09/microphone-... [7]. http://www.lcr-europe.org/meter/12/stereo+speaker.html
Andreas
On Tue, Mar 17, 2009 at 11:05:00AM +0100, Andreas Mohr wrote:
"Dreamcom 10 Laptop" [7]: " integrated Realtek HD audio processor, two built-in Akustica digital microphones and two built-in stereo speakers"
This was the only reference up and down that I could find to _any_ notebook's microphone manufacturer listing. I suspect that Aspire One has an Akustica microphone array as well since Akustica seems to be the leading brand (hmm, any ideas about where the second microphone is located if at all existing, but it must exist!!?
- probably at the front bottom?).
NOPE. Aspire One most definitely has a Fortemedia SAM (small array microphone) due to this output: http://sites.google.com/site/kengell/acer-aspire-one---dmesg
" ... ForteMedia SAM-Soft Library Loaded!
ALC INIT ... "
I had already wanted to add the mention of Fortemedia as microphone manufacturer (forgot this last time), then I researched more and found it.
Fortemedia device names include FM2018-380, not sure yet which one is in Aspire One.
http://www.fortemedia.com/products/index.htm ( especially http://www.fortemedia.com/products/fm1182.htm )
Andreas
On Tue, Mar 17, 2009 at 11:38:45AM +0100, Andreas Mohr wrote:
NOPE. Aspire One most definitely has a Fortemedia SAM (small array microphone) due to this output: http://sites.google.com/site/kengell/acer-aspire-one---dmesg
" ... ForteMedia SAM-Soft Library Loaded!
ALC INIT ... "
I had already wanted to add the mention of Fortemedia as microphone manufacturer (forgot this last time), then I researched more and found it.
Fortemedia device names include FM2018-380, not sure yet which one is in Aspire One.
http://www.fortemedia.com/products/index.htm ( especially http://www.fortemedia.com/products/fm1182.htm )
http://www.wpgholdings.com/event/S/SACg_04_ForteMedia_SAM.pdf mentions "FM201x" and www.sacg.com.tw (this one could be useful!). Searching Google "FM201[0-9] Fortemedia" comes up with FM2010 and FM2018 and thus http://www.hengdasheng.com.cn/uploadfile/391/cfile/2008102414057847.pdf which is a relatively informative datasheet.
Andreas
At Tue, 17 Mar 2009 11:47:55 +0100, Andreas Mohr wrote:
On Tue, Mar 17, 2009 at 11:38:45AM +0100, Andreas Mohr wrote:
NOPE. Aspire One most definitely has a Fortemedia SAM (small array microphone) due to this output: http://sites.google.com/site/kengell/acer-aspire-one---dmesg
" ... ForteMedia SAM-Soft Library Loaded!
ALC INIT ... "
I had already wanted to add the mention of Fortemedia as microphone manufacturer (forgot this last time), then I researched more and found it.
Fortemedia device names include FM2018-380, not sure yet which one is in Aspire One.
http://www.fortemedia.com/products/index.htm ( especially http://www.fortemedia.com/products/fm1182.htm )
http://www.wpgholdings.com/event/S/SACg_04_ForteMedia_SAM.pdf mentions "FM201x" and www.sacg.com.tw (this one could be useful!). Searching Google "FM201[0-9] Fortemedia" comes up with FM2010 and FM2018 and thus http://www.hengdasheng.com.cn/uploadfile/391/cfile/2008102414057847.pdf which is a relatively informative datasheet.
I'm not sure whether FM2018 is on a netbook. Rather my guess is it's a digital-mic component by FortMedia together with their software library for SAM handling.
BTW, a simple "fix" for the mono capture problem, you can patch the config file for HD-audio in alsa-lib like below. Then the first channel will be used for mono capture instead of averages. Give it a try.
(But, this won't fix programs that prefer "hw" access such as pulseaudio, of course.)
Takashi
--- diff --git a/src/conf/cards/HDA-Intel.conf b/src/conf/cards/HDA-Intel.conf index 800281e..d3ac002 100644 --- a/src/conf/cards/HDA-Intel.conf +++ b/src/conf/cards/HDA-Intel.conf @@ -57,6 +57,8 @@ HDA-Intel.pcm.default { max_dB 30.0 resolution 121 } + # to avoid possible phase inversions with digital mics + route_policy copy } hint.device 0 }
Hi,
On Tue, Mar 17, 2009 at 12:25:13PM +0100, Takashi Iwai wrote:
At Tue, 17 Mar 2009 11:47:55 +0100, Andreas Mohr wrote:
Fortemedia device names include FM2018-380, not sure yet which one is in Aspire One.
http://www.fortemedia.com/products/index.htm ( especially http://www.fortemedia.com/products/fm1182.htm )
http://www.wpgholdings.com/event/S/SACg_04_ForteMedia_SAM.pdf mentions "FM201x" and www.sacg.com.tw (this one could be useful!). Searching Google "FM201[0-9] Fortemedia" comes up with FM2010 and FM2018 and thus http://www.hengdasheng.com.cn/uploadfile/391/cfile/2008102414057847.pdf which is a relatively informative datasheet.
I'm not sure whether FM2018 is on a netbook. Rather my guess is it's a digital-mic component by FortMedia together with their software library for SAM handling.
I had the same thoughts later. Since they use an extensive SAM handling library, there probably isn't such a chip, otherwise they probably wouldn't need it ;) Could you thus implement a nice beam-forming sound evaluation SAM library for ALSA pretty pretty please? ;) ...or, is that SAM library available to us given that it exists in the factory install? If so, then one should probably make good use of it...
BTW, a simple "fix" for the mono capture problem, you can patch the config file for HD-audio in alsa-lib like below. Then the first channel will be used for mono capture instead of averages. Give it a try.
(But, this won't fix programs that prefer "hw" access such as pulseaudio, of course.)
I'm not *quite* sure whether this is really what you meant, but I patched /usr/share/alsa/cards/HDA-Intel.conf (libasound2 1.0.18-1ubuntu7) in exactly this way and then did arecord -Dplughw:0 -fdat -c1 test.wav; aplay test.wav but well, with equal slider positions there was no audio again.
Andreas
At Tue, 17 Mar 2009 17:18:28 +0100, Andreas Mohr wrote:
Hi,
On Tue, Mar 17, 2009 at 12:25:13PM +0100, Takashi Iwai wrote:
At Tue, 17 Mar 2009 11:47:55 +0100, Andreas Mohr wrote:
Fortemedia device names include FM2018-380, not sure yet which one is in Aspire One.
http://www.fortemedia.com/products/index.htm ( especially http://www.fortemedia.com/products/fm1182.htm )
http://www.wpgholdings.com/event/S/SACg_04_ForteMedia_SAM.pdf mentions "FM201x" and www.sacg.com.tw (this one could be useful!). Searching Google "FM201[0-9] Fortemedia" comes up with FM2010 and FM2018 and thus http://www.hengdasheng.com.cn/uploadfile/391/cfile/2008102414057847.pdf which is a relatively informative datasheet.
I'm not sure whether FM2018 is on a netbook. Rather my guess is it's a digital-mic component by FortMedia together with their software library for SAM handling.
I had the same thoughts later. Since they use an extensive SAM handling library, there probably isn't such a chip, otherwise they probably wouldn't need it ;) Could you thus implement a nice beam-forming sound evaluation SAM library for ALSA pretty pretty please? ;)
A patch please :)
...or, is that SAM library available to us given that it exists in the factory install? If so, then one should probably make good use of it...
An easy one would be a relatively simple algorithm, but I don't know whether any free library code. Better to ask on LAD.
BTW, a simple "fix" for the mono capture problem, you can patch the config file for HD-audio in alsa-lib like below. Then the first channel will be used for mono capture instead of averages. Give it a try.
(But, this won't fix programs that prefer "hw" access such as pulseaudio, of course.)
I'm not *quite* sure whether this is really what you meant, but I patched /usr/share/alsa/cards/HDA-Intel.conf (libasound2 1.0.18-1ubuntu7) in exactly this way and then did arecord -Dplughw:0 -fdat -c1 test.wav; aplay test.wav but well, with equal slider positions there was no audio again.
Don't use -Dplughw:0. Then the default setup will be used.
% arecord -fdat -c1 test.wav
Takashi
Hi,
On Tue, Mar 17, 2009 at 09:32:16PM +0100, Takashi Iwai wrote:
At Tue, 17 Mar 2009 17:18:28 +0100, Andreas Mohr wrote:
I had the same thoughts later. Since they use an extensive SAM handling library, there probably isn't such a chip, otherwise they probably wouldn't need it ;) Could you thus implement a nice beam-forming sound evaluation SAM library for ALSA pretty pretty please? ;)
A patch please :)
Not at the moment at least, sorry. But that would make for a nice little (student?) project (or not so little).
Don't use -Dplughw:0. Then the default setup will be used.
% arecord -fdat -c1 test.wav
Tried that, didn't help. /usr/share/alsa/cards/HDA-Intel.conf still contains the patch, but equal Capture Volume sliders still silenced audio input, whereas non-equal worked. Hmm.
Andreas
At Wed, 18 Mar 2009 10:05:07 +0100, Andreas Mohr wrote:
Hi,
On Tue, Mar 17, 2009 at 09:32:16PM +0100, Takashi Iwai wrote:
At Tue, 17 Mar 2009 17:18:28 +0100, Andreas Mohr wrote:
I had the same thoughts later. Since they use an extensive SAM handling library, there probably isn't such a chip, otherwise they probably wouldn't need it ;) Could you thus implement a nice beam-forming sound evaluation SAM library for ALSA pretty pretty please? ;)
A patch please :)
Not at the moment at least, sorry. But that would make for a nice little (student?) project (or not so little).
Don't use -Dplughw:0. Then the default setup will be used.
% arecord -fdat -c1 test.wav
Tried that, didn't help. /usr/share/alsa/cards/HDA-Intel.conf still contains the patch, but equal Capture Volume sliders still silenced audio input, whereas non-equal worked. Hmm.
What is the output with -v option?
Takashi
Hi,
On Wed, Mar 18, 2009 at 10:19:53AM +0100, Takashi Iwai wrote:
At Wed, 18 Mar 2009 10:05:07 +0100, Andreas Mohr wrote:
Hi,
On Tue, Mar 17, 2009 at 09:32:16PM +0100, Takashi Iwai wrote:
Don't use -Dplughw:0. Then the default setup will be used.
% arecord -fdat -c1 test.wav
Tried that, didn't help. /usr/share/alsa/cards/HDA-Intel.conf still contains the patch, but equal Capture Volume sliders still silenced audio input, whereas non-equal worked. Hmm.
What is the output with -v option?
Sorry for the delay!
$ arecord -fdat -c1 -v test.wav; aplay test.wav Recording WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono ALSA <-> PulseAudio PCM I/O Plugin Its setup is: stream : CAPTURE access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 1 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 24000 period_size : 6000 period_time : 125000 tstamp_mode : NONE period_step : 1 avail_min : 6000 period_event : 0 start_threshold : 1 stop_threshold : 24000 silence_threshold: 0 silence_size : 0 boundary : 1572864000 ^CAborted by signal Interrupt... Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono andi@andinet:/tmp$
Hmm. Note the pulseaudio stuff above...
I did verify that this test run using -v did exhibit failure again.
Thanks,
Andreas
At Fri, 20 Mar 2009 19:56:40 +0100, Andreas Mohr wrote:
Hi,
On Wed, Mar 18, 2009 at 10:19:53AM +0100, Takashi Iwai wrote:
At Wed, 18 Mar 2009 10:05:07 +0100, Andreas Mohr wrote:
Hi,
On Tue, Mar 17, 2009 at 09:32:16PM +0100, Takashi Iwai wrote:
Don't use -Dplughw:0. Then the default setup will be used.
% arecord -fdat -c1 test.wav
Tried that, didn't help. /usr/share/alsa/cards/HDA-Intel.conf still contains the patch, but equal Capture Volume sliders still silenced audio input, whereas non-equal worked. Hmm.
What is the output with -v option?
Sorry for the delay!
$ arecord -fdat -c1 -v test.wav; aplay test.wav Recording WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono ALSA <-> PulseAudio PCM I/O Plugin Its setup is: stream : CAPTURE access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 1 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 24000 period_size : 6000 period_time : 125000 tstamp_mode : NONE period_step : 1 avail_min : 6000 period_event : 0 start_threshold : 1 stop_threshold : 24000 silence_threshold: 0 silence_size : 0 boundary : 1572864000 ^CAborted by signal Interrupt... Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono andi@andinet:/tmp$
Hmm. Note the pulseaudio stuff above...
Yes, that's the very reason. If you don't PA and avoid the default configuration override (e.g. defined in /etc/asound.conf) my patch should work.
Takashi
Hi,
On Fri, Mar 20, 2009 at 09:33:19PM +0100, Takashi Iwai wrote:
At Fri, 20 Mar 2009 19:56:40 +0100, Andreas Mohr wrote:
Hi,
On Wed, Mar 18, 2009 at 10:19:53AM +0100, Takashi Iwai wrote:
What is the output with -v option?
Sorry for the delay!
$ arecord -fdat -c1 -v test.wav; aplay test.wav Recording WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono ALSA <-> PulseAudio PCM I/O Plugin Its setup is: stream : CAPTURE access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 1 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 24000 period_size : 6000 period_time : 125000 tstamp_mode : NONE period_step : 1 avail_min : 6000 period_event : 0 start_threshold : 1 stop_threshold : 24000 silence_threshold: 0 silence_size : 0 boundary : 1572864000 ^CAborted by signal Interrupt... Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono andi@andinet:/tmp$
Hmm. Note the pulseaudio stuff above...
Yes, that's the very reason. If you don't PA and avoid the default configuration override (e.g. defined in /etc/asound.conf) my patch should work.
Sorry, but how would I achieve "don't PA"? I've tried some Ubuntu suggestions (e.g. http://ubuntuforums.org/showthread.php?t=852518 ; didn't work, it's Jaunty here), I tried asoundconf (un)set-pulseaudio (~/.asoundrc contents looked ok then but didn't really help), I tried pasuspender -- arecord -fdat -c1 -v test.wav I always ended up with "ALSA <-> PulseAudio PCM I/O Plugin" mode. (I didn't even attempt the ultimate solution, removing all traces of PA packages, since that would be a ridiculous thing to do) gnome-sound-properties didn't seem overly helpful either... (Sound capture was already set as "ALSA")
If things are that impractical, then there needs to be another builtin way to always have the microphone output end up correct, automatically, instead of having to go through incredible convolutions to try to access the raw ALSA device (which would probably provide a correct mic stream) directly, by default.
Or, to put it another way, in many cases the default ALSA device wouldn't be used (by sound layers or apps or whatever), thus the patch above wouldn't work there if I'm not mistaken, thus there needs to be a different way to fix the microphone.
Or, to have it even more condensed, the more you have to fiddle to make the patch work, the more distance gets between you and the usual Linux distribution use case.
Any ideas or suggestions?
Thanks,
Andreas
At Sun, 22 Mar 2009 13:55:17 +0100, Andreas Mohr wrote:
Hi,
On Fri, Mar 20, 2009 at 09:33:19PM +0100, Takashi Iwai wrote:
At Fri, 20 Mar 2009 19:56:40 +0100, Andreas Mohr wrote:
Hi,
On Wed, Mar 18, 2009 at 10:19:53AM +0100, Takashi Iwai wrote:
What is the output with -v option?
Sorry for the delay!
$ arecord -fdat -c1 -v test.wav; aplay test.wav Recording WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono ALSA <-> PulseAudio PCM I/O Plugin Its setup is: stream : CAPTURE access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 1 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 24000 period_size : 6000 period_time : 125000 tstamp_mode : NONE period_step : 1 avail_min : 6000 period_event : 0 start_threshold : 1 stop_threshold : 24000 silence_threshold: 0 silence_size : 0 boundary : 1572864000 ^CAborted by signal Interrupt... Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono andi@andinet:/tmp$
Hmm. Note the pulseaudio stuff above...
Yes, that's the very reason. If you don't PA and avoid the default configuration override (e.g. defined in /etc/asound.conf) my patch should work.
Sorry, but how would I achieve "don't PA"? I've tried some Ubuntu suggestions (e.g. http://ubuntuforums.org/showthread.php?t=852518 ; didn't work, it's Jaunty here),
I'm no Ubuntu user, so no idea.
Takashi
participants (3)
-
Andreas Mohr -
Maxim Levitsky -
Takashi Iwai