On Mon, Jul 28, 2008 at 4:12 AM, Gang Liu <gangban.lau at gmail.com> wrote: > 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 > > Actually I don't see too much burst there. That pretty much looks like my test result here, i.e. max of 30ms audio burst. So probably the high latency is in the sound device itself? More below. 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. > > Okay then 300ms sounds within reason. > >> 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. > > Actually in 0.9.0 we already use adaptive delay buffer in the conference bridge, so enabling another delay buffer with PJMEDIA_SOUND_USE_DELAYBUF probably wouldn't help. Also in this case, it also will not make the burst RTP transmission disappear either, as that's not how the adaptive delay buffer is used in both conference.c or sound_port.c. The delay buffer only makes the bursty audio sounds good rather than make the burst disappear. >> 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. > > >> Please have a look at this (new) wiki on how to measure latency with pjsua: http://trac.pjsip.org/repos/wiki/MeasuringSoundLatency I would very much want to see your results to find out where the latency comes from. Cheers Benny -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20080728/f83bb06d/attachment.html
