A couple of years ago the microphone on my headset (regular, not USB) stopped working. I had used it with Skype briefly. I guessed it was a problem with the headset. A while ago I bought a new headset, and that microphone didn’t work either. Then I knew that it was a software problem with Ubuntu/Linux. I have two new headsets now so I am really really sure.
Today, I was trying to get either Skype or Ekiga working between two computers on my local network, and I still can’t fix it. The laptop is using a USB microphone built in to a webcam, and that works fine. But I can’t get the headset to work with my desktop PC. Here are some screenshot to express my frustration.
System-wide Sound Preferences
The Sound Preferences control panel forces me to choose from a huge list of meaningless device names, none of which work. Here are the basic settings (in Ubuntu Hardy, but this hasn’t worked in Gutsy or Feisty, at least). The test button doesn’t echo any sound to me with any of the choices. Some of the choices show a dialog with a gstreamer pipeline error, which then hangs the control panel.
And here are the volume preferences (strangely only available from the panel applet), to show that the microphone is not muted:
Also, the Sound Recorder application refuses to start, saying “Your audio capture settings are invalid. Please correct them in the Multimedia settings.”, whatever device I choose in the Sound Preferences. Strangely, Jokosher’s wave graph shows that some input is being received when I speak, but I don’t hear anything when I play it back. It’s nice that Jokosher has no microphone preferences of its own, by the way.
Update: Juerg Billeter pointed out that there’s also a preferences window in the Volume Control, via the Edit menu. It has some obscure check boxes that I can select. None of them seem to help. So now there are yet more things that I can break while looking for the one thing that I need to change to fix the problem, so that one thing probably won’t fix the problem anymore when I find it.
Application-Specific Sound Preferences
Ekiga asks me to choose one of these devices:
Skype asks me to choose from this huge list:
And what’s with those “default” device choices in both the sound input and output? Neither actually work, though both are offered (and sometimes, but not always, chosen by default) by applications such as Ekiga.
The useless “your audio capture settings are invalid” message emitted by gnome-sound-recorder has a bug associated with it in launchpad:
https://bugs.launchpad.net/ubuntu/+source/gnome-media/+bug/61211
Have you also checked the capture tab of the “Volume Control” window? There is usually a separate mute / capture volume for the microphone (in contrast to the microphone playback volume in the screenshot). You should be able to enable the capture devices in the preferences.
You can read this blog about someone having the same issue. You will noticed that most of the time, this is a kernel/ALSA issues fixed eventually in latest.
However it seems that even latest Ubuntu pre-version doesn’t work whereas latest fedora and Mandriva preversion are working fine.
http://beranger.org/index.php?page=diary&2008/03/14/14/35/36-acer-tm-5310-the-mike-the-mixer-
http://beranger.org/index.php?page=diary&2008/03/12/13/12/34-confirming-a-sound-hardy-bug-upd
GNOME Sound settings capplet seems to be most sane, but it still has dublicates (four entries of build in sound card?! come on!) and USB Audio don’t give a clue for user what it actually means (I am sure that HAL/D-Bus can deliver such info). Problem is that ALSA report multiple PCMs, and libs convert them as is, not taking care about dublications. Report a bug and someone should work on this. I am not so sure about Ekiga, because previously it used it’s own access to ALSA. I also don’t believe in PA, because it adds confusion for now, not help anything. But let’s see how it goes.
Thanks, Juerg, but that did not seem to help.
Doesn’t checking “microphone capture” in the preferences give you a new checkbox on one of the tabs? Checking that and microphone select and/or microphone boost usually results in a usable mic.
Patrys, both “microphone” and “microphone capture” seem to control whether I have the same “microphone” column on the Playback tab. It’s rather weird – unchecking one can make that column disappear even though the other one is still checked, but checking only one (when none are checked) makes the column appear. It doesn’t seem to help – and I already the microphone column before.
I have tried playing with the microphone select and microphone boost settings too, without success.
murrayc:
Playback tab is useless for your intended use as it only makes your speakers play whatever comes from your mic. Try checking and unchecking all the options in preferences until you get an option (checkbox) on one of the other tabs (not playback, usually “recording”).
This sounds insane but it seems currently alsa can’t do any better when translating what hardware provides to what driver supports to what user sees (some cards also report mic as “AUX capture” or “external input” or something similar, don’t quote me on these names).
As partially noted above, these apps are doing ALSA and users a terrible disservice in their display of “available devices”.
ALSA offers access to both real h/w devices (apps using these must honor the capabilities of the h/w), and also “software” devices which abstract any particulars of the h/w devices away so that apps can be more flexible). On any given system, there may be only 1 or 2 h/w devices, but a dozen s/w ones. Applications (especially desktop-oriented apps) need to stop showing every device that ALSA offers, and show users a subset of them. With some audio APIs (e.g. gstreamer) its not even necessary to show the devices since the user is expected to configure device preferences in a dedicated utility.
Not that excuses the lamentable state of affairs that you are facing.
Thanks again, Patrys, but no amount of checking/unchecking gives me a Recording tab so far. Maybe someone could confirm exactly what the tab is called.
Here’s a screenie of expected behavior:
http://www.flickr.com/photos/patrys/2345096925/sizes/o/
Patrys, no, I can’t get anything that looks like that here. Oh well. At least we know what we are looking for now.
You get no sound because PulseAudio is using the default sound card, which does not support hardware mixing. (The default card is, on a fresh installation, an ALSA link to hw:0).
There are two workarounds: kill PulseAudio (or use pasuspender to run your ALSA-only applications), or set the default sound card to PulseAudio. This latter does not always work, but is less invasive. Check out http://pulseaudio.org/wiki/PerfectSetup#ALSAApplications if you are interested.
(By the way, I believe the gnome-sound-settings dialog only mucks about with GStreamer settings, but that may be wrong)
Until we get OSS4 and kernel-level software mixing, we will always have this problem. Bring on OSS! That and OSS4 has a much nicer API :)
Oh, and see https://bugs.launchpad.net/bugs/198453
Toby Smithe: kernel level software mixing is not going to happen any time soon – it violates the kernel developers maxim about the kernel not providing policy. In addition, its hard (though certainly not impossible) to do software mixing properly without using floating point math, which is forbidden in the kernel. JACK and PulseAudio have already established that we can do user-space software mixing with no impact on latency, and the arrival or working user-space filesystem redirection means that this can be done without actually requiring client/server architectures if desired.
As for OSS(4), it has a much *simpler* API than ALSA, and thats for some very easy to understand reasons. These also happen to be the reasons why ALSA was developed in the first place. Most audio “gurus” at this point accept that user-space filesystem redirects are the way that OSS back-compatibilty is going to be best supported, which is why RedHat is paying Monty from Xiph to get this done properly, and in addition, there is widespread acceptance that Pulse and not ALSA nor OSS is a more appropriate example of the kind of API desktop applications should be using for audio. Both ALSA and OSS are fundamentally hardware abstraction layers, and do not offer the level of functionality required/desired by most developers. There is a good reason why even pro-audio and music-creation apps on Linux generally do not use ALSA or OSS either (they use JACK, which can interoperate with Pulse and several other higher level APIs including gstreamer).
Paul Davis, that’s very interesting. I think I’m going to do some research into “the reasons why ALSA was developed in the first place”, and the work that RedHat is doing, as I didn’t quite follow those parts. I’ve got two questions further: why can’t the kernel provide “policy”? (What is “policy”?) And why is floating point maths forbidden?
ALSA was developed because of several severe shortcomings in the OSS API (as a result of which 4Front changed the API, but years later). The ones I remember (I was there) include: lack of thread safety, inability to deal efficiently with multichannel cards, inability to deal with non-interleaved data formats, lack of any user-space API which prevents any library from interposing between the app and the driver (i.e. the app calls open/read/write/close, not oss_open/oss_read/oss_write/oss_close, so anytime you want the apps to do something slightly different, you’re stuck), the lack of any common code shared across drivers (in ALSA, a large chunk of the code in the “driver” is shared between all drivers), and several more. ALSA was a great idea. It got slightly derailed by a few key decisions, but when viewed as a hardware abstraction layer and not an audio API, its still pretty great.
Floating point is not allowed in the kernel because the kernel does not save the FP registers when saving its own context. This was decision made by Linus long ago. If you try to do FP math in the kernel, the chances are excellent that you will crash the machine.
In general, linux kernel developers want the kernel to provide mechanism so that things can happen in user space, where they can be experimented with, developed, extended, multiply-implemented and refined, rather than providing actual policies in kernel space, where any decisions are essentially final. There are plenty of exceptions to this general rule, and kernels modules do make it easier to take a more flexible approach to kernel design, but the point remains.
I need help with my sound too. I have a custom built Diplomat on Xp home edition. Handicap, I use microphone with Dragon software to type for me.
I got the new version and now the mike won’t work. I need to get it working badly.
Headset came with the program. Nothing special.
Settings are fine, looks like it is working but doesn’t hear me when I talk. I can hear me in my head, but it doesn’t get to the computer.
Any ideas?
thematrix777
I used to be a software engineer before the illness, so I’m not a newbie to computers. Just disabled with no hands.
Makes it very hard to diagnose stuff.
thematrix777
thematrix777, not only is this not a help forum, but the article was about Linux, not Windows.
I’m sorry I misunderstood. I was doing a general query on help and this came up with the exact words I typed in. I didn’t know it was different.
I apologize if I bothered anyone. I not like a spammer or anything like that. Just a person with a problem.
thematrix777