[alsa-devel] EeePC 1005PE microphone is "stereo only", silent in mono
Hello!
I have discovered that the microphone on my ASUS EeePC 1005PE only works in stereo. If recording in mono, the result is inaudible. When I open the stereo recording in audacity, I see that the two channels are in counterphase. If I convert stereo to mono in audacity, I get a straight line, and it's inaudible when played.
The driver itself requires stereo recording:
$ arecord --rate 44100 -D hw:0 -f S16_LE --channels 1 >test.wav Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 44100 Hz, Mono arecord: set_params:1065: Channels count non available
However, pulse audio doesn't enforce it. So it's possible to record a mono file through pulse audio, and it's inaudible. Some programs simply assume a mono microphone and thus get no sound.
I can work it around by setting the level on one of the channels to 100% and to 0% on the other in alsamixer. However, the GNOME volume manager removes that imbalance when adjusting the input level. I would prefer to have a robust solution. Perhaps one of the channels should be inverted. Or maybe the difference between the channels should be reported as mono input. I don't really care about stereo input.
I'm using Linux 3.0 on Fedora 15. I checked out and tested the master branch of sound-2.6.git, and it has the same problem.
It looks like the problem is known. I found this comment in alc882_quirks.c:
/* DMIC fix * This laptop has a stereo digital microphone. The mics are only 1cm apart * which makes the stereo useless. However, either the mic or the ALC889 * makes the signal become a difference/sum signal instead of standard * stereo, which is annoying. So instead we flip this bit which makes the * codec replicate the sum signal to both channels, turning it into a * normal mono mic. */
My laptop has ALC269, bit it also used the DMIC quirk: SND_PCI_QUIRK(0x1043, 0x83ce, "ASUS P1005HA", ALC269_DMIC),
That's the detailed lspci output:
$ lspci -vvnn -s 00:1b.0 00:1b.0 Audio device [0403]: Intel Corporation N10/ICH 7 Family High Definition Audio Controller [8086:27d8] (rev 02) Subsystem: ASUSTeK Computer Inc. Device [1043:83ce] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast
TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 45 Region 0: Memory at f7cf8000 (64-bit, non-prefetchable) [size=16K] Capabilities: <access denied> Kernel driver in use: HDA Intel
I'm not using any module parameters. No external devices are connected to the laptop.
At Sun, 31 Jul 2011 23:39:45 -0400, Pavel Roskin wrote:
Hello!
I have discovered that the microphone on my ASUS EeePC 1005PE only works in stereo. If recording in mono, the result is inaudible. When I open the stereo recording in audacity, I see that the two channels are in counterphase. If I convert stereo to mono in audacity, I get a straight line, and it's inaudible when played.
The driver itself requires stereo recording:
$ arecord --rate 44100 -D hw:0 -f S16_LE --channels 1 >test.wav Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 44100 Hz, Mono arecord: set_params:1065: Channels count non available
However, pulse audio doesn't enforce it. So it's possible to record a mono file through pulse audio, and it's inaudible. Some programs simply assume a mono microphone and thus get no sound.
I can work it around by setting the level on one of the channels to 100% and to 0% on the other in alsamixer. However, the GNOME volume manager removes that imbalance when adjusting the input level. I would prefer to have a robust solution. Perhaps one of the channels should be inverted. Or maybe the difference between the channels should be reported as mono input. I don't really care about stereo input.
I'm using Linux 3.0 on Fedora 15. I checked out and tested the master branch of sound-2.6.git, and it has the same problem.
It looks like the problem is known. I found this comment in alc882_quirks.c:
/* DMIC fix
- This laptop has a stereo digital microphone. The mics are only 1cm apart
- which makes the stereo useless. However, either the mic or the ALC889
- makes the signal become a difference/sum signal instead of standard
- stereo, which is annoying. So instead we flip this bit which makes the
- codec replicate the sum signal to both channels, turning it into a
- normal mono mic.
*/
My laptop has ALC269, bit it also used the DMIC quirk: SND_PCI_QUIRK(0x1043, 0x83ce, "ASUS P1005HA", ALC269_DMIC),
It might be that ALC269 has a same or similar COEF like ALC271 or ALC889. For ALC271, the following verbs do the mono-mixing of d-mic,
{0x20, AC_VERB_SET_COEF_INDEX, 0x0d}, {0x20, AC_VERB_SET_PROC_COEF, 0x4000},
while for ALC889, the following do:
{0x20, AC_VERB_SET_COEF_INDEX, 0x0b}, {0x20, AC_VERB_SET_PROC_COEF, 0x0003},
Try the above via hda-verb once whether it has any effect on your machine.
Takashi
Hello!
Quoting Takashi Iwai tiwai@suse.de:
At Sun, 31 Jul 2011 23:39:45 -0400, Pavel Roskin wrote:
My laptop has ALC269, bit it also used the DMIC quirk: SND_PCI_QUIRK(0x1043, 0x83ce, "ASUS P1005HA", ALC269_DMIC),
It might be that ALC269 has a same or similar COEF like ALC271 or ALC889. For ALC271, the following verbs do the mono-mixing of d-mic,
{0x20, AC_VERB_SET_COEF_INDEX, 0x0d}, {0x20, AC_VERB_SET_PROC_COEF, 0x4000},
while for ALC889, the following do:
{0x20, AC_VERB_SET_COEF_INDEX, 0x0b}, {0x20, AC_VERB_SET_PROC_COEF, 0x0003},
Try the above via hda-verb once whether it has any effect on your machine.
I tried both using hda-verb 0.3 but didn't have any effect. I tied playing with hda-verb a little bit. For COEF_INDEX 0xb, the initial value returned by GET_PROC_COEF is 0x5cc0. The lowest value (after writing 0) is 0x5c00. The highest value (after writing 0xffff) is 0x5dff. Writing 0x0003 results in 0x5c03, quite predictably.
For COEF_INDEX 0xd, the initial value is 0xf000. The range is from 0 to 0xffc0. Setting 0x4000 succeeds, 0x4000 is read back.
Maybe I could run some script looking for acoustic feedback?
This gives feedback:
arecord -f cd --channels 2 | aplay -
This gives no feedback (pulse audio is used, output volume is maximal):
arecord -f cd --channels 1 | aplay -
At Mon, 01 Aug 2011 13:12:29 -0400, Pavel Roskin wrote:
Hello!
Quoting Takashi Iwai tiwai@suse.de:
At Sun, 31 Jul 2011 23:39:45 -0400, Pavel Roskin wrote:
My laptop has ALC269, bit it also used the DMIC quirk: SND_PCI_QUIRK(0x1043, 0x83ce, "ASUS P1005HA", ALC269_DMIC),
It might be that ALC269 has a same or similar COEF like ALC271 or ALC889. For ALC271, the following verbs do the mono-mixing of d-mic,
{0x20, AC_VERB_SET_COEF_INDEX, 0x0d}, {0x20, AC_VERB_SET_PROC_COEF, 0x4000},
while for ALC889, the following do:
{0x20, AC_VERB_SET_COEF_INDEX, 0x0b}, {0x20, AC_VERB_SET_PROC_COEF, 0x0003},
Try the above via hda-verb once whether it has any effect on your machine.
I tried both using hda-verb 0.3 but didn't have any effect. I tied playing with hda-verb a little bit. For COEF_INDEX 0xb, the initial value returned by GET_PROC_COEF is 0x5cc0. The lowest value (after writing 0) is 0x5c00. The highest value (after writing 0xffff) is 0x5dff. Writing 0x0003 results in 0x5c03, quite predictably.
For COEF_INDEX 0xd, the initial value is 0xf000. The range is from 0 to 0xffc0. Setting 0x4000 succeeds, 0x4000 is read back.
Maybe I could run some script looking for acoustic feedback?
This gives feedback:
arecord -f cd --channels 2 | aplay -
This gives no feedback (pulse audio is used, output volume is maximal):
arecord -f cd --channels 1 | aplay -
Kailang at Realtek suggested that the verb above is only for ALC269vb, but he found out another workaround (coef idx 7 bit 7).
Could you try the patch below?
thanks,
Takashi
--- diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index e125c60..d3f67ef 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -4484,6 +4484,17 @@ static void alc269_fixup_pcm_44k(struct hda_codec *codec, spec->stream_analog_capture = &alc269_44k_pcm_analog_capture; }
+static void alc269_fixup_dmic(struct hda_codec *codec, + const struct alc_fixup *fix, int action) +{ + int coef; + + if (action != ALC_FIXUP_ACT_INIT) + return; + coef = alc_read_coef_idx(codec, 0x07); + alc_write_coef_idx(codec, 0x07, coef | 0x80); +} + enum { ALC269_FIXUP_SONY_VAIO, ALC275_FIXUP_SONY_VAIO_GPIO2, @@ -4494,6 +4505,7 @@ enum { ALC275_FIXUP_SONY_HWEQ, ALC271_FIXUP_DMIC, ALC269_FIXUP_PCM_44K, + ALC269_FIXUP_DMIC, };
static const struct alc_fixup alc269_fixups[] = { @@ -4556,10 +4568,15 @@ static const struct alc_fixup alc269_fixups[] = { .type = ALC_FIXUP_FUNC, .v.func = alc269_fixup_pcm_44k, }, + [ALC269_FIXUP_DMIC] = { + .type = ALC_FIXUP_FUNC, + .v.func = alc269_fixup_dmic, + }, };
static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x1043, 0x1a13, "Asus G73Jw", ALC269_FIXUP_ASUS_G73JW), + SND_PCI_QUIRK(0x1043, 0x83ce, "ASUS P1005HA", ALC269_FIXUP_DMIC), SND_PCI_QUIRK(0x104d, 0x9073, "Sony VAIO", ALC275_FIXUP_SONY_VAIO_GPIO2), SND_PCI_QUIRK(0x104d, 0x907b, "Sony VAIO", ALC275_FIXUP_SONY_HWEQ), SND_PCI_QUIRK(0x104d, 0x9084, "Sony VAIO", ALC275_FIXUP_SONY_HWEQ),
On 08/02/2011 03:58 AM, Takashi Iwai wrote:
Kailang at Realtek suggested that the verb above is only for ALC269vb, but he found out another workaround (coef idx 7 bit 7).
Could you try the patch below?
It works! However, I needed an extra change for the new code to be executed. Also, I needed to backport the patch to Linux 3.0 (it's wireless-testing.git, but for the sound code, it's essentially Linux 3.0).
This condition is not true on my system:
if (board_config == ALC_MODEL_AUTO) { alc_pick_fixup(codec, NULL, alc269_fixup_tbl, alc269_fixups); alc_apply_fixup(codec, ALC_FIXUP_ACT_PRE_PROBE); }
board_config is 4 (ALC269_DMIC). So the condition needs to be removed for the fixup to be applied. I guess the fixup for EeePC 1005HA should be called elsewhere. I'm not using any module parameters.
I get nothing but noise on the sound-2.6/master branch. It happens regardless of whether I'm using one or two channels with arecord.
I remember a few cases when I was able to record proper sound with 2 channels on the sound-2.6/master kernel. But most of the time, I would get that noise. It looks like a separate regression.
I could try to bisect it. It's a big investment of time, considering that the system has an Atom CPU, so I'd like to know if there is any interest in that, or there is some patch lying around that would address the noise problem.
So I backported the code to wireless-testing, where I would never get the noise. Now I can record in mono through pulse audio. The sound is nice and clean. Everything is fine!
At Tue, 02 Aug 2011 15:18:18 -0400, Pavel Roskin wrote:
On 08/02/2011 03:58 AM, Takashi Iwai wrote:
Kailang at Realtek suggested that the verb above is only for ALC269vb, but he found out another workaround (coef idx 7 bit 7).
Could you try the patch below?
It works! However, I needed an extra change for the new code to be executed. Also, I needed to backport the patch to Linux 3.0 (it's wireless-testing.git, but for the sound code, it's essentially Linux 3.0).
This condition is not true on my system:
if (board_config == ALC_MODEL_AUTO) { alc_pick_fixup(codec, NULL, alc269_fixup_tbl, alc269_fixups); alc_apply_fixup(codec, ALC_FIXUP_ACT_PRE_PROBE); }
board_config is 4 (ALC269_DMIC). So the condition needs to be removed for the fixup to be applied. I guess the fixup for EeePC 1005HA should be called elsewhere. I'm not using any module parameters.
OK, then just pass model=auto. It may result in different mixer elements, but mostly it should work. (Actually it's helpful if you can test the auto-parser.)
I get nothing but noise on the sound-2.6/master branch. It happens regardless of whether I'm using one or two channels with arecord.
Does it happen no matter whether patched and/or model option value?
I remember a few cases when I was able to record proper sound with 2 channels on the sound-2.6/master kernel. But most of the time, I would get that noise. It looks like a separate regression.
I could try to bisect it. It's a big investment of time, considering that the system has an Atom CPU, so I'd like to know if there is any interest in that, or there is some patch lying around that would address the noise problem.
Before starting bisecting, please give alsa-info.sh outputs on both working and non-working kernels. Then we can compare the visible difference of register values (although coef stuff isn't exposed there).
thanks,
Takashi
On 08/02/2011 03:23 PM, Takashi Iwai wrote:
board_config is 4 (ALC269_DMIC). So the condition needs to be removed for the fixup to be applied. I guess the fixup for EeePC 1005HA should be called elsewhere. I'm not using any module parameters.
OK, then just pass model=auto. It may result in different mixer elements, but mostly it should work. (Actually it's helpful if you can test the auto-parser.)
That was it! sound-2.6/master is working now. No more noise. Stereo and mono are fine. No need to bisect anything.
So I just added "options snd_hda_intel model=auto" to /etc/modprobe.d
Obviously, it would be nice not to pass any parameters. Things should just work.
I get nothing but noise on the sound-2.6/master branch. It happens regardless of whether I'm using one or two channels with arecord.
Does it happen no matter whether patched and/or model option value?
The patch has no effect on the noise. But model=auto makes all the difference. And I wrongly assumed it was a default.
I remember a few cases when I was able to record proper sound with 2 channels on the sound-2.6/master kernel. But most of the time, I would get that noise. It looks like a separate regression.
I could try to bisect it. It's a big investment of time, considering that the system has an Atom CPU, so I'd like to know if there is any interest in that, or there is some patch lying around that would address the noise problem.
Before starting bisecting, please give alsa-info.sh outputs on both working and non-working kernels. Then we can compare the visible difference of register values (although coef stuff isn't exposed there).
I guess it's not needed anymore. What's needed it to make "auto" the default (or some variation of that).
At Tue, 02 Aug 2011 16:15:14 -0400, Pavel Roskin wrote:
On 08/02/2011 03:23 PM, Takashi Iwai wrote:
board_config is 4 (ALC269_DMIC). So the condition needs to be removed for the fixup to be applied. I guess the fixup for EeePC 1005HA should be called elsewhere. I'm not using any module parameters.
OK, then just pass model=auto. It may result in different mixer elements, but mostly it should work. (Actually it's helpful if you can test the auto-parser.)
That was it! sound-2.6/master is working now. No more noise. Stereo and mono are fine. No need to bisect anything.
So I just added "options snd_hda_intel model=auto" to /etc/modprobe.d
Obviously, it would be nice not to pass any parameters. Things should just work.
OK, good to know. The below is a complete patch.
Takashi
--- From: Takashi Iwai tiwai@suse.de Subject: [PATCH] ALSA: hda - Fix digital-mic mono recording on ASUS eeePC
The digital-mic unit on ASUS eeePC gives PDM signals instead of the normal stereo PCM, thus you can't record a mono stream from the stereo stream as is; the summing the stereo signal results in almost zero level, and you'll hear only noise.
As a workaround, use ALC269-specific COEF to manipulate the dmic route for mono, like used for ALC271x. Since this is implemented as a fix-up and the auto-parser works fine for eeePC, the patch drops the model quirk entries for them, too.
Reported-by: Pavel Roskin proski@gnu.org Signed-off-by: Takashi Iwai tiwai@suse.de --- sound/pci/hda/alc269_quirks.c | 7 ------- sound/pci/hda/patch_realtek.c | 26 ++++++++++++++++++++++++++ 2 files changed, 26 insertions(+), 7 deletions(-)
diff --git a/sound/pci/hda/alc269_quirks.c b/sound/pci/hda/alc269_quirks.c index 14fdcf2..5ac0e21 100644 --- a/sound/pci/hda/alc269_quirks.c +++ b/sound/pci/hda/alc269_quirks.c @@ -531,17 +531,10 @@ static const struct snd_pci_quirk alc269_cfg_tbl[] = { SND_PCI_QUIRK(0x1043, 0x1653, "ASUS U50", ALC269_AMIC), SND_PCI_QUIRK(0x1043, 0x1693, "ASUS F50N", ALC269_AMIC), SND_PCI_QUIRK(0x1043, 0x16a3, "ASUS F5Q", ALC269_AMIC), - SND_PCI_QUIRK(0x1043, 0x16e3, "ASUS UX50", ALC269_DMIC), SND_PCI_QUIRK(0x1043, 0x1723, "ASUS P80", ALC269_AMIC), SND_PCI_QUIRK(0x1043, 0x1743, "ASUS U80", ALC269_AMIC), SND_PCI_QUIRK(0x1043, 0x1773, "ASUS U20A", ALC269_AMIC), SND_PCI_QUIRK(0x1043, 0x1883, "ASUS F81Se", ALC269_AMIC), - SND_PCI_QUIRK(0x1043, 0x831a, "ASUS Eeepc P901", - ALC269_DMIC), - SND_PCI_QUIRK(0x1043, 0x834a, "ASUS Eeepc S101", - ALC269_DMIC), - SND_PCI_QUIRK(0x1043, 0x8398, "ASUS P1005HA", ALC269_DMIC), - SND_PCI_QUIRK(0x1043, 0x83ce, "ASUS P1005HA", ALC269_DMIC), SND_PCI_QUIRK(0x104d, 0x9071, "Sony VAIO", ALC269_AUTO), SND_PCI_QUIRK(0x10cf, 0x1475, "Lifebook ICH9M-based", ALC269_LIFEBOOK), SND_PCI_QUIRK(0x152d, 0x1778, "Quanta ON1", ALC269_DMIC), diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index e125c60..c418df1 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -4484,6 +4484,22 @@ static void alc269_fixup_pcm_44k(struct hda_codec *codec, spec->stream_analog_capture = &alc269_44k_pcm_analog_capture; }
+static void alc269_fixup_stereo_dmic(struct hda_codec *codec, + const struct alc_fixup *fix, int action) +{ + int coef; + + if (action != ALC_FIXUP_ACT_INIT) + return; + /* The digital-mic unit sends PDM (differential signal) instead of + * the standard PCM, thus you can't record a valid mono stream as is. + * Below is a workaround specific to ALC269 to control the dmic + * signal source as mono. + */ + coef = alc_read_coef_idx(codec, 0x07); + alc_write_coef_idx(codec, 0x07, coef | 0x80); +} + enum { ALC269_FIXUP_SONY_VAIO, ALC275_FIXUP_SONY_VAIO_GPIO2, @@ -4494,6 +4510,7 @@ enum { ALC275_FIXUP_SONY_HWEQ, ALC271_FIXUP_DMIC, ALC269_FIXUP_PCM_44K, + ALC269_FIXUP_STEREO_DMIC, };
static const struct alc_fixup alc269_fixups[] = { @@ -4556,10 +4573,19 @@ static const struct alc_fixup alc269_fixups[] = { .type = ALC_FIXUP_FUNC, .v.func = alc269_fixup_pcm_44k, }, + [ALC269_FIXUP_STEREO_DMIC] = { + .type = ALC_FIXUP_FUNC, + .v.func = alc269_fixup_stereo_dmic, + }, };
static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x1043, 0x1a13, "Asus G73Jw", ALC269_FIXUP_ASUS_G73JW), + SND_PCI_QUIRK(0x1043, 0x16e3, "ASUS UX50", ALC269_FIXUP_STEREO_DMIC), + SND_PCI_QUIRK(0x1043, 0x831a, "ASUS P901", ALC269_FIXUP_STEREO_DMIC), + SND_PCI_QUIRK(0x1043, 0x834a, "ASUS S101", ALC269_FIXUP_STEREO_DMIC), + SND_PCI_QUIRK(0x1043, 0x8398, "ASUS P1005HA", ALC269_FIXUP_STEREO_DMIC), + SND_PCI_QUIRK(0x1043, 0x83ce, "ASUS P1005HA", ALC269_FIXUP_STEREO_DMIC), SND_PCI_QUIRK(0x104d, 0x9073, "Sony VAIO", ALC275_FIXUP_SONY_VAIO_GPIO2), SND_PCI_QUIRK(0x104d, 0x907b, "Sony VAIO", ALC275_FIXUP_SONY_HWEQ), SND_PCI_QUIRK(0x104d, 0x9084, "Sony VAIO", ALC275_FIXUP_SONY_HWEQ),
Am Mittwoch, den 03.08.2011, 08:26 +0200 schrieb Takashi Iwai:
[…]
From: Takashi Iwai tiwai@suse.de Subject: [PATCH] ALSA: hda - Fix digital-mic mono recording on ASUS eeePC
The official spelling seems to be Eee PC [1].
The digital-mic unit on ASUS eeePC gives PDM signals instead of the normal
Dito.
stereo PCM, thus you can't record a mono stream from the stereo stream as is; the summing the stereo signal results in almost zero level, and you'll
Should »the summing« be »in summary«?
hear only noise.
As a workaround, use ALC269-specific COEF to manipulate the dmic route for mono, like used for ALC271x. Since this is implemented as a fix-up and the auto-parser works fine for eeePC, the patch drops the model quirk entries for them, too.
So as a consequence everyone using `model=auto` can drop that from `/etc/modprobe.d/`?
I do not know how high the regression chance might be, but if there is any, maybe split the patch and write all models in the commit summary
ALSA: hda - Use auto parser for ASUS UX50, Eeepc P901, Eeepc S101 and P1005HA
for people looking through the commit log.
Reported-by: Pavel Roskin proski@gnu.org Signed-off-by: Takashi Iwai tiwai@suse.de
sound/pci/hda/alc269_quirks.c | 7 ------- sound/pci/hda/patch_realtek.c | 26 ++++++++++++++++++++++++++ 2 files changed, 26 insertions(+), 7 deletions(-)
[…]
Thanks,
Paul
On 08/03/2011 04:56 AM, Paul Menzel wrote:
Am Mittwoch, den 03.08.2011, 08:26 +0200 schrieb Takashi Iwai:
[…]
From: Takashi Iwaitiwai@suse.de Subject: [PATCH] ALSA: hda - Fix digital-mic mono recording on ASUS eeePC
Tested-by: Pavel Roskin proski@gnu.org
stereo PCM, thus you can't record a mono stream from the stereo stream as is; the summing the stereo signal results in almost zero level, and you'll
Should »the summing« be »in summary«?
hear only noise.
Actually, I was hearing almost complete silence. I was able to hear a very faint voice if I would scream at the microphone while recording. But I cannot vouch for that and I'm not in the environment to reproduce that test :)
The noise is a different thing. I would get it from the microphone without "model=auto" on the current sound-2.6/master, but not on 3.0. Perhaps some other initialization was tied to "model=auto". But this patch appears to remove the need to use that parameter.
As a workaround, use ALC269-specific COEF to manipulate the dmic route for mono, like used for ALC271x. Since this is implemented as a fix-up and the auto-parser works fine for eeePC, the patch drops the model quirk entries for them, too.
So as a consequence everyone using `model=auto` can drop that from `/etc/modprobe.d/`?
Yes. Disclaimer: I only tried it once, and I rebooted after having "model=auto".
I do not know how high the regression chance might be, but if there is any, maybe split the patch and write all models in the commit summary
ALSA: hda - Use auto parser for ASUS UX50, Eeepc P901, Eeepc S101 and P1005HA
You are not following the naming scheme you are suggesting :)
By the way, the full name of my laptop as written on the underside is ASUS Eee 1005PEB. I assume "B" is for "brown". dmidecode gives 1005PE for the system and 1005P for the base board.
The CPU is Intel Atom N450. I looked for 1005HA online, and they are said to have N270.
I assume 1005HA and 1005PE are different models. Of course, the sound chip may be the same.
At Wed, 03 Aug 2011 10:56:01 +0200, Paul Menzel wrote:
Am Mittwoch, den 03.08.2011, 08:26 +0200 schrieb Takashi Iwai:
[…]
From: Takashi Iwai tiwai@suse.de Subject: [PATCH] ALSA: hda - Fix digital-mic mono recording on ASUS eeePC
The official spelling seems to be Eee PC [1].
The digital-mic unit on ASUS eeePC gives PDM signals instead of the normal
Dito.
stereo PCM, thus you can't record a mono stream from the stereo stream as is; the summing the stereo signal results in almost zero level, and you'll
Should »the summing« be »in summary«?
Eh, no, I meant the "summed" signal.
hear only noise.
As a workaround, use ALC269-specific COEF to manipulate the dmic route for mono, like used for ALC271x. Since this is implemented as a fix-up and the auto-parser works fine for eeePC, the patch drops the model quirk entries for them, too.
So as a consequence everyone using `model=auto` can drop that from `/etc/modprobe.d/`?
I do not know how high the regression chance might be, but if there is any, maybe split the patch and write all models in the commit summary
ALSA: hda - Use auto parser for ASUS UX50, Eeepc P901, Eeepc S101 and P1005HAfor people looking through the commit log.
Sounds reasonable. Done now.
thanks,
Takashi
participants (3)
-
Paul Menzel -
Pavel Roskin -
Takashi Iwai