After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 329609 - USB headset fails with Ekiga, works with Skype
USB headset fails with Ekiga, works with Skype
Status: RESOLVED NOTGNOME
Product: ekiga
Classification: Applications
Component: general
GIT master
Other All
: Normal normal
: ---
Assigned To: Snark
Ekiga maintainers
Depends on:
Blocks:
 
 
Reported: 2006-02-02 13:27 UTC by Daniel Frey
Modified: 2006-02-08 19:06 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10



Description Daniel Frey 2006-02-02 13:27:17 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
Comment 1 Snark 2006-02-02 19:50:51 UTC
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 ?
Comment 2 Daniel Frey 2006-02-03 08:38:26 UTC
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.
Comment 3 Damien Sandras 2006-02-03 11:14:02 UTC
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?
Comment 4 Daniel Frey 2006-02-03 12:17:10 UTC
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?
Comment 5 Damien Sandras 2006-02-03 17:00:43 UTC
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!
Comment 6 Daniel Frey 2006-02-03 17:35:46 UTC
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!
Comment 7 Daniel Frey 2006-02-08 19:06:13 UTC
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.