login
Search
Hi Takashi-san, I'm experiencing DC offset with the microphone on 2.6.24 (Ubuntu 8.04 LTS x86-64). I can see on Audacity that the DC offset that varies with the recording capture level. Plus, the mixer playback->mic-boost muting enables/disables mic-boost in recording. It feels like the ALC883 pins aren't configured quite right. The mobo is an Asus P5E-VM with current BIOS [1] What's the routine to debug this? Would it help to install windows, dump the register space and compare? Thanks in advance, Daniel --- [1] $ sudo lspci -vvvxxxs 0:1b.0 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 02) Subsystem: ASUSTeK Computer Inc. Unknown device 829f Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0, Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 22 Region 0: Memory at fe9f8000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [70] Express Unknown type IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag- Device: Latency L0s <64ns, L1 <1us Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported- Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ Device: MaxPayload 128 bytes, MaxReadReq 128 bytes Link: Supported Speed unknown, Width x0, ASPM unknown, Port 0 Link: Latency L0s <64ns, L1 <1us Link: ASPM Disabled CommClk- ExtSynch- Link: Speed unknown, Width x0 00: 86 80 3e 29 06 00 10 00 02 00 03 04 08 00 00 00 10: 04 80 9f fe 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 9f 82 30: 00 00 00 00 50 00 00 00 ...
At Mon, 9 Jun 2008 20:59:00 +0100, Could you elaborate? The mic bias level could be changed via the pin You can find *.INI file that contains the default pin configuration in Windows. This might be useful in the case BIOS is broken but Windows does a black magic. Anyway, please run alsa-info.sh with --no-upload option and show the generated file here. It contains the codec information and mixer setup. http://hg.alsa-project.org/alsa/raw-file/tip/alsa-info.sh Also, you can adjust the pin setting on the fly via hda-verb utility below: http://ftp.suse.com/pub/people/tiwai/misc/hda-verb-0.2.tar.bz2 Don't forget to build snd-hda-intel module with CONFIG_SND_HDA_HWDEP=y to use this command. --
When the recording->capture level is set to 0, the mic has no DC offset as expected. Maxing the recording->capture level, the mic input That'll be these defaults stashed in the INF file [2]. Let me know if I'll give this a shot if I get time. Thanks for your time! --- [2] [OEMSettingsOverride.AddReg] HKR,"EP\\0", %PKEY_AudioEndpoint_Association%,,%KSNODETYPE_ANY% ;48k16bit HKR,"EP\\0", %PKEY_AudioEngine_OEMFormat%, %REG_BINARY%, 41,00,C8,70,28,00,00,00,FE,FF,02,00,80,BB,00,00,00,EE,02,00,04 ,00,10,00,16,00,10,00,03,00,00,00,01,00,00,00,00,00,10,00,80,00,00,AA,00,38,9B,71 HKR,"EP\\0", %PKEY_AudioEngine_OEMFormat%, %REG_BINARY%, 41,00,C8,70,28,00,00,00,FE,FF,02,00,80,BB,00,00,00,DC,05,00,08,00,20,00, 16,00,18,00,03,00,00,00,01,00,00,00,00,00,10,00,80,00,00,AA,00,38,9B,71 ;;HKR,"EP\\0", %PKEY_AudioEndpoint_Ext_UiClsid%,,%AUDIOENDPOINT_EXT_UI_CLSID% [OEMSPDIFSettingsOverride.AddReg] HKR,"EP\\0", %PKEY_AudioEndpoint_Association%,,%KSNODETYPE_HDMI_INTERFACE% HKR,"EP\\0", %PKEY_AudioEngine_OEMFormat%, %REG_BINARY%, 41,00,C8,70,28,00,00,00,FE,FF,02,00,80,BB,00,00,00,EE,02,00,04,00,10,00, 16,00,10,00,03,00,00,00,01,00,00,00,00,00,10,00,80,00,00,AA,00,38,9B,71 HKR,"EP\\0", %PKEY_SupportFormat_OEMFormat%, %REG_BINARY%, 41,00,75,00,0c,00,00,00,10,00,00,00,02,00,00,00,00,00,00,00 HKR,"EP\\1", %PKEY_AudioEndpoint_Association%,,%KSNODETYPE_ANY% HKR,"EP\\1", %PKEY_AudioEngine_OEMFormat%, %REG_BINARY%, 41,00,C8,70,28,00,00,00,FE,FF,02,00,80,BB,00,00,00,EE,02,00,04,00,10,00, 16,00,10,00,03,00,00,00,01,00,00,00,00,00,10,00,80,00,00,AA,00,38,9B,71 --- [3] name=daniel&type=33&description=/tmp/alsa-info.txt&expiry=&s=Submit+Post&content= !!################################ !!ALSA Information Script v 0.4.48 !!################################ !!Script ran on: Wed Jun 11 19:13:55 BST 2008 !!Linux Distribution !!------------------ Ubuntu 8.04 \n \l DISTRIB_ID=Ubuntu DISTRIB_DESCRIPTION="Ubuntu 8.04" !!Kernel Information !!------------------ Kernel release: ...
On Wed, Jun 11, 2008 at 8:00 PM, Daniel J Blueman Looking at the datasheet and ALSA report, changing the front mic node id also affects capturing from the (rear) mic input. ftp://66.104.77.130/pc/audio/ALC883_DataSheet_1.3.pdf We get the "hda_codec: Unknown model for ALC883, trying auto-probe from BIOS..." kernel message, so we may need to tweak pci/hda/patch_realtek.c. Also, I can reproduce the problem the with HD and legacy front-panel audio settings in the BIOS. Do you know a way to dump eg the pin configuration in windows or other useful state, so -- Daniel J Blueman --
At Wed, 11 Jun 2008 22:37:49 +0100, Depends on the hardware implementation. But, usually, no, different Note that this is no error but information. The driver has preset models for known devices and use the static configuration table for such devices. For other devices, the driver just relies on BIOS Sorry, no, I've not booted Windows over years :) Takashi --
At Wed, 11 Jun 2008 20:00:17 +0100, You can try to adjust VREF value of mic pins. For example, the node 0x18 and 0x19 correspond to the rear and front mics, respectively. Then run the following as root: # ./hda-verb /dev/snd/hwC0D0 0x18 SET_PIN_WID 0x21 which will change the widget 0x18 (rear mic) to input-VREF 50% (0x21). The original value is input-VREF 80% (0x24). Takashi --
Hi,
I find that a good way to examine the captured PCM is the following command:
$ arecord | od -t x1z -v
With the "Capture" and "Digital" controls both at 0 in alsamixer, this
outputs just a constant 0x80 byte. This seems natural.
With "Digital" at 0, changing "Capture" has no effect. However, with
"Capture" at 0 and these values for "Digital":
db gain -30 byte read 0x80
db gain -28 byte read 0x81
db gain -26 byte read 0x82
db gain -22 byte read 0x83
db gain -19 byte read 0x84
db gain -17 byte read 0x85
db gain -15 byte read 0x86
db gain -13 byte read 0x87
db gain -12 byte read 0x88
db gain -11 byte read 0x89
db gain -10 byte read 0x8a
db gain -9 byte read 0x8b
db gain -8 byte read 0x8d <-- up two here
db gain -7 byte read 0x8e
db gain -6 byte read 0x90
db gain -5 byte read 0x92
db gain -4 byte read 0x94
db gain -3 byte read 0x97
...
db gain 12 byte read 0xff
db gain 13 (and up) byte read 0x00 <-- seems to flip over or get capped
If I now change "Capture" to have dB gain 0 (35% in alsamixer), I get
this instead (for different values of "Digital"):
db gain -30 byte read 0x80
db gain -29 byte read 0x85
...
db gain -18 byte read 0x90
...
db gain -12 byte read 0xa0
...
db gain -6 byte read 0xc0
...
db gain -1 byte read 0xf2
So in fact, if both controls are at dB gain 0 (or one of them is
I tried to do this for my card. For me, I need the 0x19 widget, which
is the internal mic:
Node 0x19 [Pin Complex] wcaps 0x40008b: Stereo Amp-In
Amp-In caps: ofs=0x00, nsteps=0x02, stepsize=0x4f, mute=0
Amp-In vals: [0x00 0x00]
Pincap 0x083724: IN Detect
Vref caps: HIZ 50 GRD 80 100
Pin Default 0x99a30941: [Fixed] Mic at Int ATAPI
Conn = ATAPI, Color = Unknown
DefAssociation = 0x4, Sequence = 0x1
Misc = NO_PRESENCE
Pin-ctls: 0x24: IN VREF_80
Unsolicited: tag=00, enabled=0
And I tried various values for the PinCtl. 0x20, 0x21, and 0x22, (0x24
was the default), but with no change in the input byte stream AT ALL!
And I ...At Thu, 12 Jun 2008 15:03:16 +0200, The "Digital Capture Volume" is the software attenuation/gain in alsa-lib. Keep it in the middle corresponding to 0dB. Otherwise you change the data digitally by the software. This control exists for some devices that have only digital mics and no hardware analog volume controls. Did you get ANY input from the internal mic? If no, the pin mapping There is no safe thing as long as you work as root :) But, I've not heard any report that the wrong pin (at least VREF) broke the whole circuit, though. Takashi --
The external mic:
Node 0x18 [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out
Amp-In caps: ofs=0x00, nsteps=0x02, stepsize=0x4f, mute=0
Amp-In vals: [0x00 0x00]
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-Out vals: [0x80 0x80]
Pincap 0x083734: IN OUT Detect
Vref caps: HIZ 50 GRD 80 100
Pin Default 0x02a19840: [Jack] Mic at Ext Front
Conn = 1/8, Color = Pink
DefAssociation = 0x4, Sequence = 0x0
Pin-ctls: 0x24: IN VREF_80
So what I have done is this:
In alsamixer, Capture is set to 21 dB gain (Digital at 0 dB). This
will read mostly 0xa9 with alsarecord. If I try to sing a tone, this
value can change briefly between 0xa9 and 0xaa for as long as I sing,
such as this:
0631340 a9 a9 a9 a9 a9 a9 a9 a9 a9 aa a9 aa aa aa aa aa >................<
0631360 aa aa aa aa aa aa aa aa aa a9 a9 a9 a9 a9 a9 a9 >................<
...otherwise, it is at a constant 0xa9.
However, something interesting here happens when I change the voltage
level while recording. It seems that there is a short fluctuation (it
lasts only a fraction of a second) where the values change...:
If I change the PinCtl from 0x24 to 0x21, it seems that the data
values will change in this order (with many repetitions of each
value):
... 0xa9 0xb2 0xb1 0xb0 0xaf 0xae 0xad 0xac 0xab 0xaa 0xa9 ...
and then it is back at the constant 0xa9 value. If I change the PinCtl
from 0x21 to 0x24, the values will change in this order
... 0xa9 0xa0 0xa1 0xa2 0xa3 0xa4 0xa5 0xa6 0xa7 0xa8 0xa9 ...
So this seems to be the only difference between the internal and
external mic. I am no expert in this, but I guess the voltage change
will simply raise/lower the membrane of the microphone and the change
will be reflected in the values read back...?
But this at least assures me that the external mic pin configuration is correct.
Vegard
--
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually ...At Thu, 12 Jun 2008 15:48:32 +0200, The input volume is zero. Try to raise "Mic Boost" (if present)? Takashi --
They're already all up. Line In Boost = 100 Mic Boost = 100 Internal Mic Boost = 100 Right after changing all these to max, I've read the value from card0/codec#0 again: Node 0x18 [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out Amp-In caps: ofs=0x00, nsteps=0x02, stepsize=0x4f, mute=0 Amp-In vals: [0x00 0x00] There doesn't seem to be any difference. Even when changing them all to 0 in alsamixer, this output stays the same. Vegard -- "The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation." -- E. W. Dijkstra, EWD1036 --
Sorry, I just discovered yet another "Mic Boost" control in the playback section in alsamixer (the others were in the capture section). Changing this now gives me: Node 0x18 [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out Amp-In caps: ofs=0x00, nsteps=0x02, stepsize=0x4f, mute=0 Amp-In vals: [0x02 0x02] Strange. Vegard -- "The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation." -- E. W. Dijkstra, EWD1036 --
At Thu, 12 Jun 2008 16:01:05 +0200, It's a known bug of alsa-lib mixer abstraction layer. Some controls appear on both playback and capture views although only the value is changed only on playback mode. So, don't worry, it's not your fault ;) Takashi --
At Thu, 12 Jun 2008 15:55:45 +0200, Weird. What happens if you execute the verb directly via hda-verb program like below? hda-verb /dev/snd/hwC0D0 0x18 SET_AMP 0x7002 Takashi --
Yep, this has the same effect has changing the "Mic Boost" control in the Playback section of alsamixer. What I discovered now, though, is that I get a much wider range of values from the external mic (so playback of the captured data actually sounds correct). It actually works, but there is still a very strong DC offset that seems dependent on the level of the "Capture" control. This offset still makes it unusable for recording, since even slightly louder noises will clip the samples. It also seems that this control is reset each time I start Audacity (even though the "Mic boost" level in alsamixer doesn't change). But I guess this unrelated to the DC offset issue. Changing the voltage level now (0x21, 0x22, 0x24, with Mic Boost at 0x02) doesn't change the DC offset, but has the same effect as before (the values fluctuate, but eventually stabilize at the same level). Thanks for the help. Vegard -- "The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation." -- E. W. Dijkstra, EWD1036 --
At Thu, 12 Jun 2008 16:18:14 +0200,
Hmm, then it's all what I can guess right now.
There might be some vendor-specific settings I don't know of.
To be sure, try the following git tree (master branch), pull on
2.6.26:
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
This contains the patches for the next kernel, and some of them are
related with Realtek codecs.
Takashi
--
Maybe. I can readily dump the PCI config space of the Intel HD-audio controller in Windows and list differences; the datasheet from Intel allows us to decode the registers. Will this help us any? Of course, we really need to dump the target behind the HD-bus, but that's -- Daniel J Blueman --
At Thu, 12 Jun 2008 15:58:30 +0100, I don't think it's an issue of PCI register but rather codec setups. PCI registers cannot influence on an analog thing like DC offset. So, we need to peek the HD-audio codec registers if really doing so. Takashi --
Thanks, I've now tried it, but still it doesn't work.
At least the right model is detected, because this is my laptop:
hda_codec.c:2352: hda_codec: model 'acer' is selected for config
1025:11e (Acer Aspire 5720z)
I also applied this patch for some extra debug output (and teach me a
bit about how registers change in response to alsamixer changes):
diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
index d2e1093..588b69c 100644
--- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -129,6 +129,7 @@ unsigned int snd_hda_codec_read(struct hda_codec *codec, hda
_nid_t nid,
res = (unsigned int)-1;
mutex_unlock(&codec->bus->cmd_mutex);
snd_hda_power_down(codec);
+ snd_printdd("read verb %08x parm %08x = %d\n", verb, parm, res);
return res;
}
@@ -153,6 +154,7 @@ int snd_hda_codec_write(struct hda_codec *codec, hda_nid_t n
id, int direct,
err = codec->bus->ops.command(codec, nid, direct, verb, parm);
mutex_unlock(&codec->bus->cmd_mutex);
snd_hda_power_down(codec);
+ snd_printdd("write verb %08x parm %08x = %d\n", verb, parm, err);
return err;
}
..and in the log, I have this when modifying the "Capture" control:
hda_codec.c:157: write verb 00000300 parm 0000a01a = 0
hda_codec.c:157: write verb 00000300 parm 0000901a = 0
Now I consulted the HDA specification, and I find this surprising:
Verb 3h (set Amplifier Gain/Mute) has the following payload bits:
15 Set Output Amp
14 Set Input Amp
...but the payloads that I logged (a01a and 901a) would correspond to
bit 15 being set, which is the Output Amp!
Does that seem immediately obvious to you?
I will dig some more. Thanks for the help so far.
Vegard
--
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
-- E. W. Dijkstra, EWD1036
--
I applied this as well, just to make sure, and I tested again:
@@ -906,6 +908,9 @@ int snd_hda_codec_amp_update(struct hda_codec
*codec, hda_nid_t nid, int ch,
{
struct hda_amp_info *info;
+ printk(KERN_ERR "snd_hda_codec_amp_update(): direction = %s\n",
+ direction == HDA_OUTPUT ? "output" : "input");
+
info = get_alloc_amp_hash(codec, HDA_HASH_KEY(nid, direction, idx));
if (!info)
return 0;
..and yes, changing the "Capture" level does indeed set the Output bit
when modifying this control. Maybe there's something wrong with the
set-up of mixer or pin controls that makes ALSA think this is an
output stream?
Is there something strange here:
Node 0x18 [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out
Pin Default 0x02a19840: [Jack] Mic at Ext Front
Node 0x19 [Pin Complex] wcaps 0x40008b: Stereo Amp-In
Pin Default 0x99a30941: [Fixed] Mic at Int ATAPI
Node 0x1a [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out
Pin Default 0x0281304e: [Jack] Line In at Ext Front
..or it certainly seems that all the inputs claim to have output
capability too. Maybe this is what is confusing ALSA?
I will try to change the Gain/Mute levels manually using hda-verb
using the Input bit instead of Output and see how it goes.
Vegard
--
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
-- E. W. Dijkstra, EWD1036
--
At Thu, 12 Jun 2008 19:29:57 +0200, No. Basically, the input/output amps mean the amp input to the widget and the amp output from the widget, respectively. They don't mean that the playback or capture stream direction. So, it's perfectly OK if the amp is output for a capture stream. One exception is the pin widget. In this case, the input amp means the amp applied for the input signal from this pin, and the output amp means the amp applied before sending to this pin. So, the input/output actually corresponds to the stream direction. But, for other widgets, the amp I/O is just a difference between before or after. Takashi --
Okay, yes. I now output the nid that is changing too, and you are
correct, it is not the pin widget, but this one:
Node 0x23 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out
Amp-Out caps: ofs=0x0b, nsteps=0x1f, stepsize=0x05, mute=1
Amp-Out vals: [0x03 0x03]
Connection: 7
0x18 0x19 0x1a 0x1c 0x14 0x15 0x12*
I guess I will need to read up on what exactly an audio selector is
before attempting any more debugging.
Thank you for keeping up so far. I'll try to shut up now until I have
something more tangible to report :-)
Vegard
--
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
-- E. W. Dijkstra, EWD1036
--
Yes, I had tried this and it does not help, perhaps only changing the magnitude of the sampled mic input. Another smoking gun, is when changing certain mixer settings (both on gnome-mixer and alsamixer), eg playback->front mic amplitude, moving the slider up and down, the L/R linking seems to be almost randomly unlinked and the other L/R channel jumps to a different value. When re-linking the L/R channels, often, it'll unlink again and change both value after reading back the change; mute can be erratic too. Confirmed with 2.6.26-r5. -- Daniel J Blueman --
This seems: http://bugzilla.kernel.org/show_bug.cgi?id=10300 I do not think it's related, I had the mic problem *before* seeing this. It's not fixed as 2.6.26-rc5, btw. Romano -- Romano Giannetti Dep. de Electrónica y Automática http://www.dea.icai.upcomillas.es/romano Univ. Pontificia Comillas (MADRID) -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. --
As the mic is working fine, but with this variable DC offset, it felt like something needed tweaking in the mixer (summation) node. I understand more about the node connectivity now, and found muting the front mic mixer input and setting LR gain to 0 at mixer node 23h addresses the issue: (from page 42 at ftp://66.104.77.130/pc/audio/ALC883_DataSheet_1.3.pdf) # ./hda-verb /dev/snd/hwC0D0 0x23 SET_AMP_GAIN_MUTE 0x7180 Vegard - your HD bus enumeration looks similar and I'd bet the vendor followed the same Realtek application note, so can you give this a shot too? If not, try mixer node 20h. My motherboard (Asus P5E-VM HDMI) has front-panel HD-audio (selectable as legacy in the BIOS) connectors, but I've never been able to get them working, so left the cables disconnected...surely not a board design issue, as default pin configuration wouldn't explain the offset? Thanks, Daniel -- Daniel J Blueman --
Probably the same as https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3824 I am available to help, too. My card works quite well, modulo the mic problem and a lower output than in Vista, and I'd love to see it solved. Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. --
FWIW, I'm seeing this problem as well (ALC268 too) on my Acer Aspire 5720Z laptop. Dupes of this bug report are NOT hard to find: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3609 https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3637 https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3897 (reported by me) https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3930 ...probably more Please, if there's anything I can do to fix this, I will. I can apply and test patches, no problem. I'm attaching my own alsa-info.txt in case it helps. Thanks. Vegard -- !!################################ !!ALSA Information Script v 0.4.48 !!################################ !!Script ran on: Tue Jun 10 14:45:23 CEST 2008 !!Linux Distribution !!------------------ Fedora release 8 (Werewolf) Fedora release 8 (Werewolf) Fedora release 8 (Werewolf) Fedora release 8 (Werewolf) !!Kernel Information !!------------------ Kernel release: 2.6.24.5-85.fc8 Operating System: GNU/Linux Architecture: i686 Processor: i686 SMP Enabled: Yes !!ALSA Version !!------------ Driver version: 1.0.16 Library version: 1.0.15 Utilities version: 1.0.15 !!Loaded ALSA modules !!------------------- snd_hda_intel !!Soundcards recognised by ALSA !!----------------------------- 0 [Intel ]: HDA-Intel - HDA Intel HDA Intel at 0x9b300000 irq 22 !!PCI Soundcards installed in the system !!-------------------------------------- 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03) !!Advanced information - PCI Vendor/Device/Susbsystem ID's !!-------------------------------------------------------- 00:1b.0 0403: 8086:284b (rev 03) Subsystem: 1025:011e !!Modprobe options (Sound related) !!-------------------------------- snd-card-0: index=0 snd-hda-intel: index=0 !!Loaded sound module options !!-------------------------- !!Module: ...
