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 358043 - extremely scratchy sound when talking with ekiga
extremely scratchy sound when talking with ekiga
Status: RESOLVED INCOMPLETE
Product: ekiga
Classification: Applications
Component: general
2.0.x
Other All
: Normal major
: ---
Assigned To: Ekiga maintainers
Ekiga maintainers
Depends on:
Blocks:
 
 
Reported: 2006-09-27 22:21 UTC by Samir van de Sand
Modified: 2006-12-26 19:49 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14



Description Samir van de Sand 2006-09-27 22:21:48 UTC
Please describe the problem:
When I use Ekiga for voice-chatting the sound is extremely scratchy. (other voip-applications like Skype 1.3 Beta work fine).

Steps to reproduce:
1. setup an SIP account (for example at Ekiga.net)
2. dial a test sip number like 500@ekiga.net


Actual results:
I hear what my conversion partner is saying, but the sound is very scratchy. When dialing the 500@ekiga.net test number, I speak into the microphone and also hear my voice but it's returned scratchy too. 

Expected results:
I expect to hear clear sound.

Does this happen every time?
Yes

Other information:
I'm using Ubuntu Dapper with manually integrated Alsa v1.0.13rc drivers.

This is my hardware http://vaio.sony-europe.com/view/ShowProduct.action?product=VGN-FE11H&site=ite_en_GB&pageType=Overview&category=PM+FE+Series

This is my relevant lspci -v output:
0000:00:1b.0 0403: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)
        Subsystem: Sony Corporation: Unknown device 81ef
        Flags: bus master, fast devsel, latency 0, IRQ 82
        Memory at d2300000 (64-bit, non-prefetchable) [size=16K]
        Capabilities: [50] Power Management version 2
        Capabilities: [60] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable+
        Capabilities: [70] #10 [0091]
Comment 1 Jan Schampera 2006-09-27 22:55:22 UTC
- which codecs are involved during the call?
- which sounds system do you use?
- is the bandwidth very limited (e.g. p2p filetransfers)?
- is the CPU load very high?
- anything on stderr output of Ekiga?
Comment 2 Samir van de Sand 2006-09-27 23:31:20 UTC
(In reply to comment #1)
> - which codecs are involved during the call?

PCMA

> - which sounds system do you use?

Do you mean this Alsa & OSS stuff? If that's what you mean, I use like I said Alsa v1.0.13rc. (my ekiga is using Alsa too)

> - is the bandwidth very limited (e.g. p2p filetransfers)?

No, absolutely not.

> - is the CPU load very high?

No.

> - anything on stderr output of Ekiga?

Do you mean my console output ? There's nothing at all.


Another thing I want to mention is that sound test of the Ekiga Configuration druid worked flawlessly.
Comment 3 Damien Sandras 2006-09-28 11:29:16 UTC
It is an ALSA setup issue. See :
http://wiki.ekiga.org/index.php/Getting_several_applications_using_the_sound_card_at_the_same_time_%3F

See TroubleShooting.

Also, during a call, what is the jitter buffer value in the statistics panel?
Comment 4 Samir van de Sand 2006-09-28 14:54:15 UTC
Are you sure this is an Alsa issue ? I think, if this were an Alsa issue, Skype would have the same problems.

About the jitter buffer value, it's around 100ms during the call ...
Comment 5 Damien Sandras 2006-09-28 15:04:32 UTC
100ms is good.

Yes I'm sure it is an ALSA issue, or a setup problem or a problem due to the environment.

Skype is using OSS btw, and not ncessarily the same parameters than Ekiga.

Does this command give good results :
arecord -D plughw:0,0 -c 1 -r 8000 -f S16_LE - | aplay -D plughw:0,0 -c
1 -r 8000 -f S16_LE -
Comment 6 Samir van de Sand 2006-09-28 15:18:41 UTC
I tested it with Skype 1.3 Beta, which uses Alsa.

I tested the command you stat under 2 situations.
1. While no other audio playbacks were active the command worked fine.
2. While I was playing an MP3 with totem-gstreamer I got the following return message:
Recording WAVE 'stdout' : Signed 16 bit Little Endian, Rate 8000 Hz, Mono
aplay: main:544: audio open error: Device or resource busy
Comment 7 Damien Sandras 2006-09-28 15:49:41 UTC
And how is the quality when talking in the microphone while running this command?

You can try those 2 commands :
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 default -c 1 -r 8000 -f S16_LE - | aplay -D default -c
1 -r 8000 -f S16_LE -
Comment 8 Samir van de Sand 2006-09-28 16:26:57 UTC
The quality of all commands is perfectly fine.
Comment 9 Samir van de Sand 2006-10-05 18:11:56 UTC
Hey, is there somebody on this bug ?
I'd appreciate any kind of help to find out where the problem resides.

regards Samir
Comment 10 Snark 2006-10-05 18:55:22 UTC
Damien seems to think it's an ALSA issue... the fact that the commands run with perfect quality is strange... what is your bandwith ?
Comment 11 Samir van de Sand 2006-10-05 19:11:58 UTC
It's definitely not an bandwith issue. I don't really know how much bandwith I got, since I live in a student residental. It's some sort of fiber optical dedicated line ...
Comment 12 Snark 2006-10-06 07:29:29 UTC
You keep repeating your bandwith isn't an issue, but :
1) we checked your devices were working, and
2) the problems appear only when you go on the network

So please check your real bandwith, especially the *upload*.
Comment 13 Samir van de Sand 2006-10-06 10:59:52 UTC
Ok, when downloading with bittorrent, I achieve download and upload rates around 2-3 mbyte/s (keep in mind it's byte not bit). I think this should be more than enough ...
Comment 14 Damien Sandras 2006-10-06 11:15:23 UTC
That doesn't mean that the latency is good.

What's the jitter value during a call?
Comment 15 Samir van de Sand 2006-10-06 11:37:07 UTC
My latency, is good. When I ping a site or play games I've a ping around 5ms. We've already measured the jitter value during a call. It was around 100ms (see comment #4).
Comment 16 Damien Sandras 2006-10-06 11:39:57 UTC
OK, then obviously it is not a network problem, I can confirm it.
However, the configuration assistant audio test gives good quality, as well as both aplay and arecord commands, so it can not be an ALSA problem.

If it is not a bandwidth problem, nor an ALSA problem, I do not see what it can be, unfortunately.
Comment 17 Damien Sandras 2006-10-06 11:44:17 UTC
Would you be able to recompile the ALSA plugin with storedPeriods=3?
Comment 18 Damien Sandras 2006-10-06 12:26:24 UTC
Actually it could be a DUP of #358338 (http://bugzilla.gnome.org/show_bug.cgi?id=358338).

Can you try with PWLIB, OPAL and EKIGA from HEAD?

thanks,