GNOME Bugzilla – Bug 329609
USB headset fails with Ekiga, works with Skype
Last modified: 2006-02-08 19:06:13 UTC
Please describe the problem: I can't use my USB headset (Logitech USB 2.0 headset connected via a USB 2.0 hub) with Ekiga for both input and output. I could use it for input, but the output needs to go to the on-board sound card, which is not a good solution. Steps to reproduce: 1. Select the "Logitech USB Headset" for both input and output in the druid page 7/10 (assuming you do have a Logitech USB headset ;) 2. Click "Test Settings" Actual results: After a few seconds, a window opens which reads: Cannot use the audio device The selected audio device (Logitech USB Headset) was successfully opened but it is impossible to write data to this device. Please check your audio setup. At the same time the window opens, the shell where I started Ekiga shows: Cannot set parameters Broken pipe and dmesg shows: cannot submit datapipe for urb 0, err = -28 Expected results: Obviously, I would expect the test to pass Does this happen every time? Yes Other information: Please note that the headset does work with Skype, so this might not be a "simple" USB driver issue. Hard to tell... Also, as mentioned above, the headset works as an input device for Ekiga, when I select "Intel ICH5" as output device. I'm using a Debian system, basically Etch, with a 2.6.15 kernel from Sid. This kernel already has CONFIG_USB_BANDWIDTH disabled. (Just checked /usr/src/linux/.config, and yes, it is not set) I'm using Ekiga from http://snapshots.gnomemeeting.net/debian/ etch main
Yes, the fact that it works for ekiga separately for input and output shows that there is no permission issue or things like this. And if it works with skype but not for us, it is annoying. Something that would be worth checking : - ekiga accesses the audio devices using ALSA - I think skype access them using OSS emulation ==> try to install the libpt-cvs-plugins-oss package, and test if things get better using the OSS plugin. Perhaps OSS-emulation does something that works around a bug in the pure-ALSA driver ?
I tried it with OSS as you suggested, but it gives the same error as ALSA. From the strace output I produced, let's make a wild guess: Does Ekiga access the headset through a single file-descriptor for both input and output? (in case they are the same) If this is true, could it be changed to use separate FDs? (Well, this is really a *wild* guess and I may be completly wrong here as I haven't looked at the source yet and I have no idea how it works). Just an idea, as this might be something that Skype could easily do different. This might also explain why I can here the ring-sounds, etc. in the headset, it just fails when it is set up to do full-duplex. Also, the test in the druid page doesn't fail when I start it, it fails in the exact moment when the first echos should be send back. Is there anything else I could do? Any ideas? BTW: I also upgraded ekiga/libpt a few hours ago, but the problem with the headset remains. The good news is, that the network is now detected correctly (Port restricted NAT) and now works with STUN.
I think it is an ALSA problem. Skype doesn't necessarily use the same parameters than Ekiga. Can you test this : arecord -D plughw:0,0 -c 1 -r 8000 -f S16_LE - | aplay -D plughw:0,0 -c 1 -r 8000 -f S16_LE - Does it work? Then try with -r 16000 instead. Does it work?
Seems like you are on the right track. I replaced plughw:0,0 with plughw:1,0 and got: daniel@nemesis:~$ arecord -D plughw:1,0 -c 1 -r 8000 -f S16_LE - | aplay -D plughw:1,0 -c 1 -r 8000 -f S16_LE Recording WAVE 'stdout' : Signed 16 bit Little Endian, Rate 8000 Hz, Mono Playing WAVE 'stdin' : Signed 16 bit Little Endian, Rate 8000 Hz, Mono aplay: set_params:949: Unable to install hw params: ACCESS: RW_INTERLEAVED FORMAT: S16_LE SUBFORMAT: STD SAMPLE_BITS: 16 FRAME_BITS: 16 CHANNELS: 1 RATE: 8000 PERIOD_TIME: 125000 PERIOD_SIZE: 1000 PERIOD_BYTES: 2000 PERIODS: 4 BUFFER_TIME: 500000 BUFFER_SIZE: 4000 BUFFER_BYTES: 8000 TICK_TIME: 1000 daniel@nemesis:~$ also, dmesg gives me the 'cannot submit datapipe for urb 0, err = -28' when I tried it with -r 8000. The same test with -r 16000 (aborted after a few seconds by Ctrl-C) produces: daniel@nemesis:~$ arecord -D plughw:1,0 -c 1 -r 16000 -f S16_LE - | aplay -D plughw:1,0 -c 1 -r 16000 -f S16_LE Recording WAVE 'stdout' : Signed 16 bit Little Endian, Rate 16000 Hz, Mono Playing WAVE 'stdin' : Signed 16 bit Little Endian, Rate 16000 Hz, Mono Aborted by signal Interrupt... Aborted by signal Interrupt... daniel@nemesis:~$ and works fine, I can hear my own voice with a very short delay. Anything else I could do to help?
That means that your USB headset works with sample rate of 16000 and not of 8000. Skype always uses 16000. SIP providers and H.323 providers are always using 8000 for now. So, Ekiga to Ekiga calls will work, in most of the cases because Ekiga is able to do calls with a sample rate of 16000. Ekiga to other SIP phones calls will not work, because they do not support anything else than 8000 in general. Ekiga to SIP providers calls will not work, because they are always using codecs sampled at a rate of 8000. I would report the problem on the ALSA mailing list, because it is an ALSA bug. If you are using hw:1,0, then there is no guarantee that the requested parameters will work with your device and driver, but when using plughw, ALSA should internally make the required conversions so that it works. Please report a bug to them and keep us updated. I will leave the bug OPEN for NOW, but it is not an Ekiga bug or limitation but an ALSA problem. Thanks for your debugging and time!
I sent a mail to alsa-devel, to verify that it's an ALSA problem before opening a bug report. Let's see what happens, I will report the results here. Thanks for your help (both of you) and thanks for Ekiga!
It's a strange ALSA/USB-Bug, the Headset works on the root hub's ports, but not at the LCD's hub. Anyway, it not Ekiga's problem, so I close this. Again, thanks for your help.