ALC861 : Mic does not work after installation

[JK]

Binary package hint: alsa-base

Hi!

 I'm currently trying to get the mic to work an a friend's Toshiba A100. First I installed Ubuntu 9.04 and tried to record using audacity and the audio-recorder but had no luck. Then I upgraded to 9.10 (Alpha 6) but that didn't help. Within karmic, audio-recorder even crashes on exit and sound playback is a little bit choppy and strange noises occur when switching between windows or minimizing/maximizing them. However, playback works while recording does not.

The weirdest thing about this bug is that is does NOT occur when using the live system! I tried both 9.04 and 9.10 A6 live CD and succeeded to record and playback my own voice using an external mic (there is no builtin mic). But after the installation the mic stops working! Because of that, I believe that it's a configuration issue rather than a bug within the driver. I checked that the selected input-device is correct and not muted (using alsa-mixer). I also commented out all options within alsa-base.conf (hoping to reproduce the settings from within the live session) but it did not help. Does anybody have some suggestions?

Here are some error messages from dmesg that may be helpful:

[ 9.750229] HDA Intel 0000:00:14.2: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 9.959887] hda_codec: Unknown model for ALC861, trying auto-probe from BIOS...
[ 9.959995] input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:14.2/input/input7
.
[ 41.980016] hda-intel: azx_get_response timeout, switching to polling mode: last cmd=0x00170503
[ 42.986301] hda_intel: azx_get_response timeout, switching to single_cmd mode: last cmd=0x00170503

Here is some additional hardware information:

00:14.2 Audio device: ATI Technologies Inc IXP SB4x0 High Definition Audio Controller (rev 01)
    Subsystem: Toshiba America Info Systems Device ff10
    Flags: bus master, slow devsel, latency 64, IRQ 16
    Memory at d0000000 (64-bit, non-prefetchable) [size=16K]
    Capabilities: [50] Power Management version 2
    Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
    Kernel driver in use: HDA Intel
    Kernel modules: snd-hda-intel

**** List of PLAYBACK Hardware Devices ****
card 0: SB [HDA ATI SB], device 0: ALC861 Analog [ALC861 Analog]
  Subdevices: 0/1
  Subdevice #0: subdevice #0
card 0: SB [HDA ATI SB], device 6: Si3054 Modem [Si3054 Modem]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

Here's the output of 'lsmod'

Module Size Used by
aes_i586 8124 3
aes_generic 27484 1 aes_i586
binfmt_misc 8356 1
ppdev 6688 0
snd_hda_codec_realtek 203296 1
snd_hda_codec_si3054 4636 1
snd_hda_intel 26600 4
arc4 1660 2
snd_hda_codec 69276 3 snd_hda_codec_realtek,snd_hda_codec_si3054,snd_hda_intel
snd_pcm_oss 37920 0
snd_mixer_oss 16028 1 snd_pcm_oss
ecb 2524 2
snd_pcm 75296 5 snd_hda_codec_si3054,snd_hda_intel,snd_hda_codec,snd_pcm_oss
snd_seq_dummy 2656 0
joydev 10272 0
snd_seq_oss 28576 0
snd_seq_midi 6432 0
snd_rawmidi 22208 1 snd_seq_midi
snd_seq_midi_event 6940 2 snd_seq_oss,snd_seq_midi
pcmcia 36808 0
snd_seq 50224 6 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event
ath5k 123940 0
radeon 636000 2
iptable_filter 3100 0
snd_timer 22276 2 snd_pcm,snd_seq
snd_seq_device 6920 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_rawmidi,snd_seq
mac80211 181236 1 ath5k
yenta_socket 24168 1
ttm 36212 1 radeon
ip_tables 11692 1 iptable_filter
rsrc_nonstatic 11644 1 yenta_socket
led_class 4096 1 ath5k
lp 8964 0
drm 159584 4 radeon,ttm
snd 59204 19 snd_hda_codec_realtek,snd_hda_codec_si3054,snd_hda_intel,snd_hda_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_seq_oss,snd_rawmidi,snd_seq,snd_timer,snd_seq_device
ath 8060 1 ath5k
ati_agp 6760 0
x_tables 16544 1 ip_tables
i2c_algo_bit 5760 1 radeon
soundcore 7264 1 snd
psmouse 56180 0
pcmcia_core 35792 3 pcmcia,yenta_socket,rsrc_nonstatic
i2c_piix4 9932 0
parport 35340 2 ppdev,lp
snd_page_alloc 9156 2 snd_hda_intel,snd_pcm
shpchp 32272 0
serio_raw 5280 0
cfg80211 93084 3 ath5k,mac80211,ath
agpgart 34988 3 ttm,drm,ati_agp
video 19188 0
output 2780 1 video
ohci1394 29900 0
8139too 22620 0
8139cp 19260 0
mii 5212 2 8139too,8139cp
ieee1394 86596 1 ohci1394

[JK (m0d)]

After talking to people in https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/391114 and doing some search I've got some news on this. The option "probe_mask=8" fixed the problem with the crackling sound and the timeout errors from above, at least it seems so... Furthermore, alsa-mixer shows all devices correctly (capture devices were missing before). At the first glance, everything seems correct now...

However, one problem remains: recording STILL doesn't work! When recording with audacity, the time-slider doesn't move forward but is constantly flickering. And when using GNOME's sound recorder, recording stops immediately after starting it and the app crashes on exit each time. PA's "volume meter" for recording doesn't show anything either. I'm running out of ideas right now...

[JK (m0d)]

When reading this
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/354620
and this
https://bugs.launchpad.net/netbook-remix/+bug/320032
it seems that the problem may be related to PulseAudio. Is PA indeed not active during a live session?

I would test that, but I don't want to completely uninstall PA but deactivate it. Unfortunately, the audio settings in karmic are completely different and I found no way to change everything to ALSA. Is there a way to completely deactivate PA in Karmic?

[JK (m0d)]

I found a way to reactivate the mic: adding "option position_fix=1" to alsa-base.conf. See this guide for further information:
http://www.kernel.org/pub/linux/kernel/people/tiwai/docs/HD-Audio.html

However, the recording quality is much lower than within the live session. Even when setting the capture device to max. volume, the recorded stream is very quiet and contains significant noise. Within the live session, the recorded stream was much louder, even with the capture device almost muted, and contained almost no noise!

I compared the PA and ALSA settings in the live system with those of the installed system (using pacmd and the alsa-info-util script) and saw no difference. It is totally unclear why it suddenly stops working after installation and also why the quality is much lower when using the necc. options "probe_mask=8" and "position_fix=1". I tried other options too (like "model=toshiba") but they didn't help. Imho, getting the audio to work is the biggest problem nowadays when installing a linux distribution...

[rizlo (davide-molteni)]

ok I tried in a live session (toshiba A100) sound works but with the loop issue, also the mic works but the recording is very quiet with a lot of noise seems like when position_fix=1 is added on the installed system... On the installed system, without modifying alsa-base.conf mic don't work. Tell me if you need some useful output.

[rizlo (davide-molteni)]

I just noticed that even with position_fix=1 mic still don't work!

[JK (m0d)]

> Tell me if you need some useful output.

I think it would be important to find out where the differences between the live and the installed session come from. I've tried to do that by comparing the output of the alsa-info script (www.alsa-project.org/alsa-info.sh) and commands like "pacmd list". Unfortunately, that did not reveal the cause for this strange effect. Like I already said, even the modem did not break anything during the live session (it was detected correctly). After giving back the laptop to its owner, I couldn't do any more tests but it seems that there are many people who experience a similar problem... at least there is always a difference between the live and installed session that has not been explained yet! Maybe because few people even think of testing sound within the live session...

You could either open a new bug report (let me know the link please) or append the output of your tests here. Hopefully, someone will find the cause and maybe even fix your sound...

Regards

JK

[JK (m0d)]

Oh, I just remembered something important: there was always a difference between the "alsa-mixer" controls in the live and the installed session. Within the live session, all devices have been detected correctly (including PCM, modem and mic) but within the installed session (without additonal flags) there were only modem and PCM, no input device!

[Daniel T Chen (crimsun)]

That's definitely a linux issue, then. These sorts of codec races are
horribly nasty to debug. You probably need a probe_mask parameter for
your install.

[JK (m0d)]

> You probably need a probe_mask parameter for your install.

Already did that, probe_mask=8 disables the modem and brings back the sound (read above). It does not help reactivating the mic though, but that can be achieved with position_fix=1. And especially the second flag doesn't make any sense to me. I know (vaguely at least) what it does, but I can't understand why it is only neccessary on the installed system!? And also I can't understand why the recording quality is much worse within the live session (using "position_fix=1")...

> That's definitely a linux issue, then.

I'd love to read more about what you think about this! How are the symptoms described above explainable with race conditions? And, if it's really kernel related, maybe you should change the "affects" tag...

Regards

JK

[Daniel T Chen (crimsun)]

On Sun, Nov 8, 2009 at 4:22 AM, JK <email address hidden> wrote:
> Already did that, probe_mask=8 disables the modem and brings back the
> sound (read above). It does not help reactivating the mic though, but
> that can be achieved with position_fix=1. And especially the second flag
> doesn't make any sense to me. I know (vaguely at least) what it does,
> but I can't understand why it is only neccessary on the installed
> system!? And also I can't understand why the recording quality is much
> worse within the live session (using "position_fix=1")...

Then you're likely using the wrong probe_mask parameter.

> I'd love to read more about what you think about this! How are the
> symptoms described above explainable with race conditions? And, if it's
> really kernel related, maybe you should change the "affects" tag...

Codec probing is always racy. Check out the code in sound/pci/hda.

Also, you don't need to wait on me to change the affects field.

[JK (m0d)]

> Then you're likely using the wrong probe_mask parameter.

Hu? Why should it be wrong? It's just a bit mask that enables probing only for the codec in 4th slot. If you'd look at the debug output that I've already appended, you'd see that the 1st slot is occupied by the modem and the 4th by the ALC861 codec. Thus, the only appropriate bitmask is 8. And it kinda works since it brings back sound output. The mic (i.e. the input device) has no dedicated slot but is part of the ALC codec, so imho it should not be influenced by the probe_mask (as long as you don't disable the ALC codec of course). If you can explain why it's the wrong probe_mask for the mic, then please let me know!

> Codec probing is always racy. Check out the code in sound/pci/hda.

I don't disagree with that. But that does not explain the bugs described above. Just because "code probing is racy" it does not mean that it has to break your audio!

> Also, you don't need to wait on me to change the affects field.

I did not change it because I am not convinced that this is indeed a kernel bug. All that I've got from you thus far are some vague comments and assumptions, without any explanation or evidence that would make them plausible. While I appreciate to finally get some responses, I've expected a bit more that the plain old "you did sth wrong" (obviously without checking the debug info) and "it's not our fault" phrases, especially from a member of the "audio development team"...

Regards

JK

[Daniel T Chen (crimsun)]

@JK You're right, I'll explain this further in the week when work
isn't killing me.

[Endre Gabriel (endre-gabriel)]

I can confirm this bug. The same problem with exactly the same sympthoms occurred on my Fujitsu Siemens AMILO Pi 1505. It has also ALC861.

E.

[JK (m0d)]

Any news regarding this bug? Daniel, you promised some more information on the codec probing stuff...

[Brad Figg (brad-figg)]

Please, if you are still having issues, test with the latest development release of Ubuntu. ISO CD images are available from http://cdimage.ubuntu.com/releases/ .

If it remains an issue, could you run the following command from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p alsa-base 434511

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds .

Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text.

Please let us know your results.

[icb410 (ian-berke)]

it's working for me in lucid

[rizlo (davide-molteni)]

The audio looping/repeating issue is solved in lucid beta1 but the mic input is still not working on installed system. From live session both audio and microphone works fine. This with default parameters in alsa-base.conf

[rizlo (davide-molteni)]

on lucid mic works adding "position_fix=1" to alsa-base.conf

[Daniel T Chen (crimsun)]

rizlo: please file a separate bug affecting alsa-driver.

JK: sorry for the delay. It's difficult to say without traces for your live cd and rotary (presuming it's a rotary HD and not SSD) what order the resources are grabbed. I can't rule out firmware errors, hardware errors, or linux errors. The best thing to do at this stage is to test a mainline build as Brad suggested.

[Launchpad Janitor (janitor)]

[Expired for alsa-driver (Ubuntu) because there has been no activity for 60 days.]