GNOME Bugzilla – Bug 388579
Failure to open Intel ICH sound card
Last modified: 2007-01-15 08:27:47 UTC
Please describe the problem: Ekiga fails to open an intel8x0 sound card (Intel ICH [NVidia CK8]), producing a very unhelpful "couldn't open audio device" error message. On further investigation this appears that Ekiga is expecting to open the device in mono mode and this hardware only provides stereo support. Looks similar to http://bugzilla.gnome.org/show_bug.cgi?id=340246 except in my case, using aplay and arecord with ALSA's plughw device works fine so it appears that Ekiga may not be using plughw. e.g. this works fine: arecord -c 1 -f S16_LE -D plughw:1,0 > /dev/null Creating an .asoundrc which sets pcm.!default to go through plughw and then setting Ekiga to use the default device causes it to work fine. However, this isn't a solution since this is a secondary sound device and therefore doesn't want to be set as the default ALSA device. Steps to reproduce: 1. Try to use Intel ICH sound card for input/output. Actual results: Ekiga pops up a dialogue box saying "couldn't open audio device". Expected results: Ekiga should have no problem opening the plughw sound device. If there is a failure, a more helpful error message should be produced (the current message looks like a typical Windows "Umm, something broke be I'm not going to tell you what" error). Does this happen every time? Yes Other information: I'm running Fedora Core 6 - all the packages (Ekiga, Gnome, ALSA, Kernel, etc) are standard packages from the distribution.
This definitely looks like an alsa configuration problem and not an ekiga bug.
How is this an ALSA problem? Opening plughw:1,0 or default:1 in single channel mode in other software such as aplay and arecord works fine (whilest hw:1,0 fails, which is the correct behaviour).
Does this work: Try to see on both sides if : arecord -D plughw:0,0 -c 1 -r 8000 -f S16_LE - | aplay -D plughw:0,0 -c 1 -r 8000 -f S16_LE - and arecord -D plughw:0,0 -c 1 -r 16000 -f S16_LE - | aplay -D plughw:0,0 -c 1 -r 8000 -f S16_LE -
Both commands seem to work fine (except I am using plughw:1,0 since this is the second sound card in the machine)
Then I have unfortunately no idea why Ekiga complains if you are 100% sure the device is not already used by another application. I'm however sure it is not a bug, otherwise we would have many more bug reports like this one.
I wonder if it is not the same problem as Bug 340246.
I've finally had some chance to do some debugging on this. It looks like the snd_pcm_open() call is trying to open the wrong device: [pid 27188] open("/dev/snd/pcmC1D3p", O_RDWR|O_NONBLOCK) = -1 ENOENT (No such file or directory) whereas the same call from aplay does: open("/dev/snd/pcmC0D0p", O_RDWR|O_NONBLOCK) = 4 So it kinda looks like it might be an ALSA problem, but I can't see why aplay and Ekiga try to open different devices. Changing the "plughw:" references in pwlib to "default:" seems to work around the problem, although I haven't successfully got the microphone working (but I think that's a different problem). I have filed a bug against ALSA at https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2728
My mistake - I had the aplay command line wrong. When told to use plughw:1 aplay fails in the same way.
I've just realised it's using plughw:1 instead of plughw:1,0 - is that right? (aplay also breaks with plughw:1 but works with plughw:1,0)
Yes, doing so it is supposed to open the correct device on multichannel devices. aplay -D plughw:0 /usr/share/sounds/ekiga/ring.wav Playing WAVE '/usr/share/sounds/ekiga/ring.wav' : Signed 16 bit Little Endian, Rate 8000 Hz, Mono works here.
Can we conclude it is an ALSA bug or not ? What do you think ?
Certainly looks like an ALSA bug (although I'm not entirely sure we should be using plughw:1 instead of default:1). Closing for now.
Ekiga will use plughw:1 if you choose to access the soundcard, and default:1 if you choose the "Default" device in the preferences.