I'm running pulseaudio 0.9.23 on Archlinux on an Acer Aspire One 150. Sound is handled by the snd_hda_intel module. In the default configuration, everything _seems_ to be fine - the microphone input is shown correctly, volume sliders work - but there is no actual input. After some googling, I stumbled over the following post: http://getsatisfaction.com/jolicloud/topics/deaf_internal_mic_on_acer_aspire_one#reply_2108048 After using pavucontrol to reduce the volume of the left microphone channel to 0, microphone input suddenly appears and works as intended. This seems to be an incredibly obscure fix for somewhat common hardware and should be handled correctly without workarounds. If you need more information or if I can help in any way, please let me know.
Created attachment 49760 [details] output of pulseaudio -vvvvv
While it would be possible to work around this in pulseaudio, in general I would say that these kind of things need to be fixed in the ALSA layer. The sound driver already knows about a lot of quirks of different hardware models. Handling of a out of phase stereo mic array should be added to that too.
David: how do you suggest we resolve this?
We have a workaround (i e quirk) for some of these in the kernel already. We write to some secret register, that turns the Internal Mic into a Mono mic. So if you're having ALC269 or ALC271X (as seen in /proc/asound/cardX/codec#X ) you can just submit a quirk to the kernel. Unfortunately I've also seen it happening for ALC268 and ALC272X (and IIRC, one Conexant?) and we don't know the secret register for those (yet). There are various ways we can work around this in both the kernel, alsa-lib and PulseAudio layers. It's a matter of picking the right one. I'm leaning towards trying to fix it in the kernel's codec drivers, because 1) we already have quirking infrastructure there 2) we already have some working quirks already in that layer 3) it would benefit other sound applications that use ALSA directly. The downside to that is really that we're silencing out one channel for everyone, leading to no application being able to use both channels, even if they would implement some kind of "auto-detect-and-reverse-one-channel" functionality. But should such need arise later on, we could possibly implement a kcontrol to switch this functionality on and off...
Is this something we've fixed on the ALSA side (as I recall was the intention)?
Yes, we use "Inverted Internal Mic" in ALSA to mark that one of the channels are inverted. So I think this can be closed from PulseAudio side. If this is still a problem with the latest kernel feel free to raise a bug in alsa-devel.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.