[sip-comm-dev] Strange voice delay on eee-PC with SIP video call


#1

Hi,

today I did some testing to get sc working on my eee PC 901 (first generation Atom 1GB RAM, nothing special)

I called another machine using SIP and established a video call. As soon as I turn on the camera at the eee side, the sound gets delayed by ages (>5 sec) while still at good quality (no crackling, drop outs, whatsoever)

The image is fine. The other way around (from the stronger machine to the eee) the sound comes in with quite good latency

What's wrong?
a) the eee is underpowered (don't believe that) and video encoding eats up all the processing power.
b) the WLAN card is strange and there is an UDP jam of outgoing packets (I remember, having problems with conferencing on Linphone via WLAN - update to Karmic solved it)
c) video gets preference over voice and voice packets queue up
d) something even more strange

Any ideas?

Thank you for help
Conrad

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

a) the eee is underpowered (don't believe that) and video encoding eats up all the processing power.

It doesn't sound impossible to me. Wikipedia says "901 features an
Intel Atom Diamondville CPU clocked at 1.6 GHz". The H.264 encoding is
quite CPU intensive so I wouldn't be surprised if it starves the audio
capture and encoding threads. When you turn on the video on the
stronger machine and it gets displayed on the Eee PC, does the sound
from the Eee PC get delayed as well? The H.264 decoding shouldn't be
as strenuous on the CPU as the encoding.

Anyway, I don't really have such hardware at my disposal so I'm not
sure about a possible time frame to look into the issue.

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

The H.264 encoding is quite CPU intensive so I wouldn't be surprised if it starves the audio capture and encoding threads.

Fot that reason I disabled h264 and tried h263 - with the same result. :frowning:

When you turn on the video on the stronger machine and it gets displayed on the Eee PC, does the sound from the Eee PC get delayed as well?

No, it doesn't. Even if both cams are enabled.

Anyway, I don't really have such hardware at my disposal so I'm not sure about a possible time frame to look into the issue.

What a pity, but maybe I can help you. How would one find out where the constrains are? Are there ways to debug this? Could one give voice priority over video? Would it be possible to drop frames if processing power gets tight?

A 1.6 GHz machine is not that weak. Ok, probably here in Germany - it is old stuff, bot definitely not overseas. One of my conference partners is in Colombia. They tend to use their hardware much longer than we do (in many parts of the world - Eastern Europe, Latin America, Asia - it's the same, I guess)

Linphone is fine on these machines. It is based on ffmpeg for encoding/decoding as well. (as far as I know sc uses a native lib based on ffmpeg for (en)coding - or is it Java??)

However Linphone usually uses a smaller video resolution (it should be CIF). At least a linphone calling SC results in a much smaller video image than a SC to SC call. But quality is quite acceptable when enlarged.

What about beeing able to adjust video size at the sending end? A smaller resolution might get better results with thinner lines (such as EDGE or crowded cable modems) ? Or maybe it's enough to lower the frame rate. (or both)

Another question: What is the minimal hardware requirements for a simple video call? Maybe anyone in the forum has experience to share.

Thank you

Greetings
Conrad

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

The H.264 encoding is quite CPU intensive so I wouldn't be surprised if it starves the audio capture and encoding threads.

Fot that reason I disabled h264 and tried h263 - with the same result. :frowning:

H.263 in SIP Communicator is new. We also expected it to be much less
CPU intensive so we're going to take another look at it for possible
optimizations.

When you turn on the video on the stronger machine and it gets displayed on the Eee PC, does the sound from the Eee PC get delayed as well?

No, it doesn't. Even if both cams are enabled.

What do you mean by "Even if both cams are enabled"? If both cams are
enabled, doesn't that mean that the cam of the Eee PC is enabled i.e.
its audio is delayed?

Could one give voice priority over video?

Damian Minkov may be able to provide insight into adjusting the
priorities of the threads involved into audio and video.

Would it be possible to drop frames if processing power gets tight?

It should be possible. Since x264 is implemented to use as much of the
CPU as possible, I guess one should rather drop frames depending on
how badly the audio is affected.

What about beeing able to adjust video size at the sending end? A smaller resolution might get better results with thinner lines (such as EDGE or crowded cable modems) ?

We are open to suggestions and, more importantly, contributions so we
should be able to help by discussing possible approaches and reviewing
patches.

···

On Sat, Nov 20, 2010 at 4:09 PM, Conrad Beckert <conrad_videokonferenz@gmx.de> wrote:

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

What do you mean by "Even if both cams are enabled"? If both cams are

enabled, doesn't that mean that the cam of the Eee PC is enabled i.e.
its audio is delayed?<<
I had the following setup:
- eee
- Acer (stronger CPU)
Established Video call between the two machines and enabled both cameras.
- Video is OK and with little delay
- say something in the eee's mike --> delay
- say something in the Acer's mike --> no delay

i.e. there is no delay at the recieving end even if the eee's camera is enabled and sc is encoding and sending Video.

That's strange isn't it as it contradicts with 'encoding blocks voice' - probably it means: video encoding blocks audio encoding? (Audio was GSM and later G711) Could it be a strange race condition in the ffmpeg which only doesn't hit at the Acer's side as the Acer has a Dual Core processor and the eee doesn't?

Greetings
Conrad

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

Today I connected my machines (still the same, eee PC and Acer 5720) directly on the same LAN using Jingle.

I observed the same effect I had before on SIP (then with the camera). But now I had a closer look at the eee: When I say something into the microphone - there is no reaction at all. The VU-bar stays "silent". It takes a couple of seconds and the VU indicates sound which almost instantly comes out the speakers at the Acer side.

There is no need to activate the camera. This delay is reproducable with voice only.

My OS is Ubuntu (Karmic (eee) and Maverick (Acer)). Both use Pulse Audio for sound i/o. It doesn't help to change the Audio device to /dev/dsp. (probably emulated by Pulse Audio anyway)

So I suspect anything in the sound recording chain rather than in encoding.

Yesterday I had a nasty delay of the same kind in the Acer as well (Acer -> NAT -> Internet -> Asterisk -> Linphone). It was not reproducable later (I switched to Linphone to save the nerves)

So anything wrong with Pulse Audio or an issue with Ubuntu? Are there other Ubunteros around to verify/falsify that? Probably people with rather weak hardware?

Thank you for help
Conrad

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#7

Hi,

this weekend I had a chance to test one eee PC making a video call,
initially I was using google talk plugin, and I have seen the delay
you are talking about. The other side was my notebook which has enough
power, and when I say something on the side with powerful CPU I can
hear it on the side of EEE PC after 7 or 8 seconds, this is during
video call. During normal audio call everything seems normal with
almost no delay. So it seems to me that this type of machine lack CPU
power to do video encoding/decoding.

I made a few more tests. When the computer is using the battery its in
"Power save mode" and if you don't move and stay still on the video
that is captured on the eee-PC I heard now delay initially but later
the delay grows, during the call I put it on AC power and I switch it
to "Super performance mode" or something like that and for a few
seconds the delay disappeared and the call continue normally with now
delay. So it seems that the CPU settings matter and if you are in mode
where CPU is in lower mode to save battery video encoding is not
usable.

Later I made the same tests with SIP Communicator and I cannot
reproduce the same results, when It was in "Power saving mode" or was
it called "Battery mode" there was delay but wasn't as big as 7 or 8
seconds, it was no more than a second. The thing that I saw was that
the decoding of the video wasn't so good at the eee-PC side when using
it in battery mode. On the other side the video was ok (means that the
encoded video seems fine).

That were my all test results for now on this kind of machine and I
wanted to share them with you :slight_smile:

Regards
damencho

···

On Sun, Nov 21, 2010 at 5:50 PM, Conrad Beckert <conrad_videokonferenz@gmx.de> wrote:

What do you mean by "Even if both cams are enabled"? If both cams are

enabled, doesn't that mean that the cam of the Eee PC is enabled i.e.
its audio is delayed?<<
I had the following setup:
- eee
- Acer (stronger CPU)
Established Video call between the two machines and enabled both cameras.
- Video is OK and with little delay
- say something in the eee's mike --> delay
- say something in the Acer's mike --> no delay

i.e. there is no delay at the recieving end even if the eee's camera is enabled and sc is encoding and sending Video.

That's strange isn't it as it contradicts with 'encoding blocks voice' - probably it means: video encoding blocks audio encoding? (Audio was GSM and later G711) Could it be a strange race condition in the ffmpeg which only doesn't hit at the Acer's side as the Acer has a Dual Core processor and the eee doesn't?

Greetings
Conrad

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#8

That were my all test results for now on this kind of machine and I
wanted to share them with you :slight_smile:

Thank you - let's me feel less abandoned with my "obsolete" Hardware.

I did further testing and I discovered that the cause might be somewhere in the audio chain (I created issue 881 for that)

It's interesting to see, that the VU meter of SC's microphone reflect the delay: I say something and the VU meter doesn't react. A couple of seconds later the bar indicates sound and almost immediately it comes out of the speakers at the other end.

This behavior is independent of whether I encode video or not. (which is strange because I could swear, that in my first tests a couple of Nightly Builds before I had no delay when there was no video encoding.)

Did you test on Windows or Linux? I use Ubuntu Lucid on the eee.

Greetings
Conrad

PS: I should test the performance vs. power saving mode as well, probably next week.

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#9

Hi,

all my tests were on windows (the machine was not mine, I couldn't
reinstall it :slight_smile: )

damencho

···

On Sun, Nov 28, 2010 at 3:08 PM, Conrad Beckert <conrad_videokonferenz@gmx.de> wrote:

That were my all test results for now on this kind of machine and I
wanted to share them with you :slight_smile:

Thank you - let's me feel less abandoned with my "obsolete" Hardware.

I did further testing and I discovered that the cause might be somewhere in the audio chain (I created issue 881 for that)

It's interesting to see, that the VU meter of SC's microphone reflect the delay: I say something and the VU meter doesn't react. A couple of seconds later the bar indicates sound and almost immediately it comes out of the speakers at the other end.

This behavior is independent of whether I encode video or not. (which is strange because I could swear, that in my first tests a couple of Nightly Builds before I had no delay when there was no video encoding.)

Did you test on Windows or Linux? I use Ubuntu Lucid on the eee.

Greetings
Conrad

PS: I should test the performance vs. power saving mode as well, probably next week.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#10

-------- Original-Nachricht --------

···

Datum: Sun, 28 Nov 2010 14:21:19 +0100
Von: Stefan Sayer <stefan.sayer@googlemail.com>
An: conrad_videokonferenz@gmx.de
Betreff: Re: [sip-comm-dev] Strange voice delay on eee-PC with SIP video call

Conrad Beckert wrote:
Did you test on Windows or Linux? I use Ubuntu Lucid on the eee.
are you using pulse audio? have you tried setting
resample-method=trivial in /etc/pulse/daemon.conf ? I had
speex-float-1 there, and already an audio only sc call took way too
much processing power.

Stefan

>
> Greetings
> Conrad
>
> PS: I should test the performance vs. power saving mode as well,
probably next week.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
> For additional commands, e-mail: dev-help@sip-communicator.dev.java.net
>
>

--
Stefan Sayer
VoIP Services Consulting and Development

Warschauer Str. 24
10243 Berlin

tel:+491621366449
sip:sayer@iptel.org
email/xmpp:stefan.sayer@gmail.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net