No microphone inputs

[nadrach]

I have several machines running 10.04, netbook, laptop & desktop, all but one of which have no working microphone inputs, and that one works with Ekiga but not Audacity. After repeated trundles through the forum archives I finally found a note today that said that the default alsamixer, 1.0.21, installed with Kubuntu 10.04, has a bug in it relating to several sound cards, at least one of which I have on a machine, and that the cure is to install version 1.0.23 from the alsa dev repository. However, the available instructions date from May 2010 ...

http://monespaceperso.org/blog-en/20...id-lynx-10-04/

... and involve compiling the source, which I would refer not to have to do on multiple disparate hardwares. Is there now, 18 months later, a direct source of the compiled package available?

[nadrach]

Re: No microphone inputs

Life can be interesting. ("Define interesting." -- "Oh god, oh god, we're all going to ...")

I have an Advent QC430 laptop dating from 2007 ... bit cranky ... some keys do not work ... thin vertical white line towards one end of the screen due to faulty contacts ... but it still does the job, especially after replacing Vista with Kubuntu 8.04. On the 1 GB Ram, Vista took over five minutes just to get started and settled; whereas 8.04 could be up, used for a browser query and shut down in less. 10.04 netbook is still matching that performance. However, until now the sound was ... interesting. I could actually overload the output to massive distortion with the controls set high, there were channels displayed in alsamixer and Kmix that made no sense to the physical items ... and as I only discovered in recent tests, having not yet had cause to use a microphone with this PC, neither the external nor internal microphone channels worked.

I now have alsamixer 1.0.24 (not 1.0.23) installed, which came with linux-alsa-driver-modules-2.6.32-34-generic from the ppa:ubuntu-audio-dev/ppa repository via the standard Kubuntu software management GUI. I finally found this option when the monespaceperso.org website delivered all of the comments to the posting mentioned earlier in this thread, not just the first two (see comment 17). Unfortunately, the package made not the slightest difference to the sound setup.

However, after reading an article on Archwiki (https://wiki.archlinux.org/index.php/Acer_Aspire_One) I added the following line at the end of the file /etc/modprobe.d/alsa-base.conf (not etc/modprobe.d/sound.conf as given in the article) ...

options snd-hda-intel model=auto

... and this has completely changed the alsamixer and Kmix setup. Now I only have (the few) channels that match the sound facilities on the unit, except for 'IEC958/IEC958 Default PCM' mute controls (no sliders) on Kmix only, presumably because the sound card can provide this output even though there is no external connector on the laptop. I also have audio output levels such that even when all controls are up full, there is no distortion or overload ... actually, the sound is considerably clearer.

I was completely unable to find any reference document that would provide a list of the possible valid model names for this option to the HDA Intel linux sound driver. There are some lists cobbled together from hit and miss trials by various posters in the Ubuntu, Kubuntu and other forums, and hints of other model names that may work, but no reference document giving them. This surprised me, because in order for any model name to work in the option, it must surely be explicitly coded in the driver ... someone, somewhere must have a list, surely? Some of the potential names identified have little direct relationship with the PC models they apparently work with, which did not make trying to come up with something that would work for the QC430, any easier. After a couple of failed guesses that had no effect, I used the 'auto' option because it apparently reads an ID from the BIOS and may work (although in the Archwiki post, about the Acer Aspire One D255E, 'auto' does not work, but setting 'model=acer-aspire' does). What that ID was, I cannot find, but the option did make good changes.

However, I still don't have any working microphone channels.

A second unit being prepared is a new Acer Aspire One D255E, so I side-stepped installing the development ALSA package and just added ...

options snd-hda-intel model=acer-aspire

... into /etc/modprobe.d/alsa-base.conf. Again, all the extraneous channels disappeared from alsamixer and Kmix, but this included the separate channels for internal and external microphones, all I was left with were "Front Mic", "Front Mic Boost" and "Front Mic Boost Capture". However, I do now have a working microphone input ... not from the internal microphone, but from the external one, the socket for which is actually on the side. What I also found is that whenever a microphone is inserted in this socket, the input signal comes straight out of the speakers ... instant feedback until I muted the speaker and used headphones. Also this is only in Ekiga ... no other sound program, such as Audacity or a plain sound recorder can get a thing. VOIP is the need, however, so Ekiga will do.

On an ASUS eeePC 1000H from 2008, the internal microphones (there appear to be two, under the screen) initially worked with Audacity until I ran Kmix for the first time to get all the channels displayed in the mixer screen. However, Kmix (and alsamixer) did not show microphone channels for either internal or external microphones, only "Mic Boost", which displayed as separate sliders for Mic Boost and Mic Boost Capture, plus a separate channel for "Capture". After Kmix was closed, I found the mic inputs to Audacity were gone and have remained so. However, Ekiga subsequently proved to be able to access a microphone channel, with level controlled by the Mic Boost sliders (they work as a pair and only have 4 settings ... off, 33%, 66%, full), which is switched from internal to external mic when you plug in a mic to the external socket. Adding the "model=auto" line to the "alsa-base.conf" file here made no difference, so I took it out again.

Unfortunately I cannot get video on Ekiga 3.2.6 on this machine, the video driver rejects all format requests, even in each format change into and out of the echo test, the video camera only opens up with an earlier version, Ekiga 2.0.12. (separate thread http://kubuntuforums.net/forums/inde...opic=3119159.0). Hey, ho.

My faith in Kubuntu, or even Linux, to get sound configuration right is currently dented. Checks on other machines, 64-bit as well as 32-bit have thrown up anomalies ... not one has run sound under any Linux distro with anything like consistency. My overall impression of the way sound is handled on PC's, and not just with open source or even software per se (MS and Apple appear little better in attitude), is that it is geek designed on a Friday afternoon ("Hey, let's have some sound ... throw something to together ... what do you want microphones for?"), it certainly has very little to do with any sound system practice I have ever encountered.

The sound card on one desktop had a stereo microphone input; another was mono, but uses a stereo jack; a laptop had a stereo jack that if you insert a mono microphone you get left channel, but a stereo microphone gets both channels, but mixed to mono; several netbooks appear to have 'stereo' internal microphones (there are two, somewhere near the screen, and they show differently on left and right channels) but mono external sockets ... the single common feature is that nowhere in any manual or specification could I find anything to tell me what was supposed to be fitted. Most did not even say there was a microphone, let alone what it was or how an external one connected. In each case ALSA set up single slider controls (when it set up anything).

For a mono input to a stereo system, there should be volume and pan or twin volume, for a stereo input there should be twin volume or volume and balance. A routing diagram should show where each input and output routes from and to, whether in software or hardware. Terms and nomenclature should show consistency. Whilst arbitrary conduct in hardware is something we may be stuck with, what we have at the moment is arbitrary setup, poor description and poor explanation on top. It is a disregard for the end user which frankly, in the third decade of open source, is shaming and has the potential to do incredible damage to a brilliant concept.

Years ago I had a colleague who wore a home-printed T-shirt that said "It's not a bug, it's an undocumented feature." ... defiantly so, even when it irked his superiors ... he said it was a quote from an MS training leaflet he found in a waste bin after a convention where he worked the bar. It wore out around the time we both saw printed versions start to appear. We used to mutually refer to poor documentation (content and/or practice) as "doing a Microsoft" ... it happened a lot. My introduction to Unix was to be stood in front of an upright cabinet console, handed 44 floppies of SCO Xenix and told to "Load that!". My request for an install document was met with a scathing silent "look" in reply. Eventually I found one, which I characterised as written by people who knew what they were doing for other people who knew the same, definitely not for the customer who was intended to use the system. Full of colloquialisms, bad grammar and cryptic references, it had the added downside that the majority of customers would read it through the medium of English as a second language. I have to say, that after several weeks of investigating sound and microphones on Linux, that that commercial attitude to documentation of nearly two decades ago is alive and well in the open source community ... I had thought better things were likely.

The user guide to an Acer Aspire One is 29Mb and 1454 pages long, in over 20 languages, looks beautiful, but is sheer technical fluff that says almost nothing about how the unit works. Our open source sound documentation is little better. Regrettably I have to conclude the situation as 'doing a microsoft.' I am disappointed.