Hi benny,
We tested two sound devices, one is Realtek HD Audio, the other is
C-Media USB.
First, we did calling between two ua using pjsip.
After that we did calling between one pjsip ua and one linksys ipphone.
Both case testers said latency is high.
After I changed config_site.h and recompile, they said much better.
########### Realtek HD ##############################
10:33:05.046 sndtest.c Testing playback device Realtek HD Audio output
10:33:05.046 sndtest.c Testing capture device Realtek HD Audio Input
10:33:05.250 sndtest.c Please wait while test is in progress (~11
secs)..
10:33:16.359 sndtest.c Dumping results:
10:33:16.359 sndtest.c Parameters: clock rate=8000Hz, 80
samples/frame
10:33:16.359 sndtest.c Playback stream report:
10:33:16.359 sndtest.c Duration: 9s.990
10:33:16.359 sndtest.c Frame interval: min=0.003ms, max=34.437ms
10:33:16.359 sndtest.c Jitter: min=9.985ms, avg=23.309ms,
max=34.433ms
10:33:16.359 sndtest.c Capture stream report:
10:33:16.359 sndtest.c Duration: 9s.960
10:33:16.359 sndtest.c Frame interval: min=0.002ms, max=68.573ms
10:33:16.359 sndtest.c Jitter: min=9.925ms, avg=25.771ms,
max=68.569ms
10:33:16.359 sndtest.c Checking for clock drifts:
10:33:16.359 sndtest.c Sound capture is 240 samples faster than
playbac
at the end of the test (average is 24 samples per second)
10:33:16.359 sndtest.c Test completed with some warnings
############### C-Media USB ###################################
10:37:45.000 sndtest.c Testing playback device C-Media USB Headphone
Set
10:37:45.000 sndtest.c Testing capture device C-Media USB Headphone Set
10:37:45.203 sndtest.c Please wait while test is in progress (~11
secs)..
10:37:56.312 sndtest.c Dumping results:
10:37:56.328 sndtest.c Parameters: clock rate=8000Hz, 80
samples/frame
10:37:56.328 sndtest.c Playback stream report:
10:37:56.328 sndtest.c Duration: 10s.110
10:37:56.328 sndtest.c Frame interval: min=0.003ms, max=30.224ms
10:37:56.328 sndtest.c Jitter: min=9.958ms, avg=23.069ms,
max=30.220ms
10:37:56.328 sndtest.c Capture stream report:
10:37:56.328 sndtest.c Duration: 10s.110
10:37:56.328 sndtest.c Frame interval: min=0.002ms, max=30.317ms
10:37:56.328 sndtest.c Jitter: min=9.984ms, avg=23.070ms,
max=30.313ms
10:37:56.328 sndtest.c Checking for clock drifts:
10:37:56.328 sndtest.c No clock drifts is detected
10:37:56.328 sndtest.c Test completed with some warnings
reply inline.
regards,
Gang
On Tue, Jul 22, 2008 at 9:44 PM, Benny Prijono <bennylp at pjsip.org> wrote:
> On Fri, Jul 18, 2008 at 9:21 AM, Gang Liu <gangban.lau at gmail.com> wrote:
>
>> Hi nanang
>> Thanks for your link.
>> I had do some testing this week. But at my testing(local LAN), the
>> latency is high when both calling and callee use conf bridge for normal call
>> handling.
>>
>
> Sorry for the late reply. Nanang has been feeling a bit under the weather
> recently so he's been mostly away from computers.
>
:-)
>
>
>> I know default value of sound device record/playback latency is 100ms.
>> If conf bridge don't add more latency, I think total
>> latency wouldn't reach 300 ms for one way conversion at my local LAN.
>>
>
> 300ms seems high for LAN and without the conference bridge. How did you
> test this?
>
I always used conference bridge at both end.Say 1, 2, 3, 4, 5.And the guys
said latency is high.
>
>
>
>
>> But at my testing we found latency is high. There must
>> be somewhere add more latency besides sound device.
>>
>>
>
> That will be the buffering in conference bridge and in the jitter buffer.
>
>
>
>
>> So I reduce sound device and conf bridge ptime to 10ms, and change
>> sound device record/play back latency to 40 ms.
>> PJMEDIA_SOUND_BUFFER_COUNT still 6. The reduce of latency is quite
>> obvious. I thought there maybe some latency caused by
>> bridge.If this isn't true, why only 120 ms latency reduced by sound
>> device will let us see impressed result.
>> Yes, the best answer is to learn conference bridge source code. But
>> there will be helpful advice from your experts to make it clear.
>>
>
> IMO the main culprit is with the audio burst from your sound device. If
> your sound device is sending N burst frames at a time, then it will add up
> to 2*N*ptime of additional latency end to end. This is because the
> conference bridge is buffering N*ptime before transmittign the frame from
> conference (due to how conference.c works), and also the burst will be
> counted as jitter on the receiver end as well, so the jitter buffer will
> also buffer N*ptime, giving it the total of 2*N*ptime of additional latency.
>
I understand now. For pjsip 0.9.0 and later, the conference bridge uses
adaptive delay buffer, the latency of bridge is reduced to N * ptime which N
is sound device burst frames. PJMEDIA_SOUND_BUFFER_COUNT is maximum amount
of buffering.
Is it useful If I enable PJMEDIA_SOUND_USE_DELAYBUF to reduce conference
bridge and jitter buffer on the receiver?
Because sounde device already do burst frames buffering, I think conference
bridge maybe reduce its buffer into 1. And it don't cause network jitter
anymore.
It will reduce latency to N*ptime if above is right.
>
> You can see the audio burst characteristic of your sound device from
> sndtest.exe output. For example in my computer:
>
> Dumping results:
> Parameters: clock rate=8000Hz, 80 samples/frame
> ...
> Capture stream report:
> Duration: 10s.110
> Frame interval: min=0.004ms, max=30.255ms
>
> The test above shows audio ptime is set to 10ms (80 samples @8KHz sample
> rate), and burst value of at least 3 frames at a time (see max frame
> interval of 30ms, which counts as 3 frames). In real conversation, the
> actual burst can be higher than that due to other activities in your
> computer, it can be up to two frames higher.
>
> With this, the end-to-end audio latency here (from mouth to ear, with
> conference bridge) is around 250ms, which is not too shabby.
>
How do you get this value 250ms?
burst value is 3 frames. So 2*N*ptime = 60 ms. plus sound device latency 40
ms at both side, only get total 140 ms.
>
> So I would be interested to know what's the sound burst value in your
> system, to see if my assumptions above were right.
>
> Btw, we look forward to modify the conference bridge to remove the N*ptime
> buffering in the next release, so stay tuned for further latency reductions
> (and also APS for those working on Symbian which would also cut latency
> significantly). :)
>
> Cheers
> Benny
>
>
>
>
>>
>> ------ config_site.h ------------
>> #define PJMEDIA_SOUND_IMPLEMENTATION PJMEDIA_SOUND_PORTAUDIO_SOUND
>> #define PJMEDIA_PREFER_DIRECT_SOUND 0
>>
>> #define PJMEDIA_SND_DEFAULT_REC_LATENCY 40
>> #define PJMEDIA_SND_DEFAULT_PLAY_LATENCY 40
>>
>> #define PJMEDIA_SOUND_USE_DELAYBUF 0
>>
>> #define PJMEDIA_SOUND_BUFFER_COUNT 6
>>
>> At all testing, we are using G729 codec at ptime 20ms. OS is windows
>> XP. And VS 2005.
>>
>> regards,
>> Gang
>>
>>
>> On Fri, Jul 18, 2008 at 12:30 AM, Nanang Izzuddin <nanang at pjsip.org>
>> wrote:
>>
>>> Hi Gang Lau,
>>>
>>>
>>> 2008/7/17 Gang Lau <gangban.lau at gmail.com>:
>>> > Hi,
>>> > I have some questions about conference bridge when play with
>>> pjsipua.
>>> >
>>> > If we want to create a four party audio conference, is it needed to
>>> > connect all channels each other?
>>> >
>>> > connect(0, 1);
>>> > connect(0, 2);
>>> > connect(0, 3);
>>> > connect(1, 0);
>>> > ...
>>> > connect(1,3);
>>> > connect(2,0);
>>> > ...
>>> > connect(2,3);
>>> > ...
>>> > connect(3,2);
>>> >
>>> > or just all the ports connected to port zero and port zero
>>> connected to
>>> > all ports is enough.
>>>
>>> You have to connect all channels each other. Port zero is just a
>>> participant as the other stream ports, it doesn't do the mixing, the
>>> conference bridge does.
>>>
>>> >
>>> > And it seems pjsipua create conference bridge by default, even for
>>> a
>>> > simple call.
>>>
>>> Yes, assumed you are using PJSUA, there is no pjsipua.
>>>
>>> > The conference bridge has 120ms(buffer size 6 * ptime 20 ms)
>>> latency.A
>>> > simple call will be total 240ms latency caused by
>>> > both side bridge. Is it true?
>>> > How could I reduce latency for pjsipua?
>>> >
>>>
>>> No, it isn't true :)
>>> The buffer size you point there should be PJMEDIA_SOUND_BUFFER_COUNT.
>>> Please see please see
>>> http://trac.pjsip.org/repos/wiki/FAQ#audio-latency about buffer size
>>> meaning. The link also gives info about how to reduce latency.
>>>
>>> Regards,
>>> nanang
>>>
>>> _______________________________________________
>>> Visit our blog: http://blog.pjsip.org
>>>
>>> pjsip mailing list
>>> pjsip at lists.pjsip.org
>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>
>>
>>
>> _______________________________________________
>> Visit our blog: http://blog.pjsip.org
>>
>> pjsip mailing list
>> pjsip at lists.pjsip.org
>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>
>>
>
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
>
> pjsip mailing list
> pjsip at lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20080728/cb87fcbe/attachment-0001.html
