Changes between Version 47 and Version 48 of FAQ

Timestamp:

Jun 30, 2008 8:55:17 AM (16 years ago)

Author:

bennylp

Comment:

--

FAQ

@@ -208 +208 @@
 ==== Choosing lower audio frame length ====
 
-Ticket #393 (release 0.7.1) added a new media setting {{{pjsua_media_config.audio_frame_ptime}}}, or in older PJSUA-LIB, this setting is hard-coded in {{{PTIME}}} macro in {{{pjsua_media.c}}}. This setting specifies the length of audio frame in milliseconds, to be set to both the sound device and to the conference bridge.
-
-The previous default value is 20 milliseconds, while the default value is now set to 10 milliseconds. Changing this value from 20 to 10 milliseconds will reduce sound device latency by about 100 milliseconds and end-to-end audio latency by about 200 milliseconds.
+ Older pjsip::
+ Ticket #393 (release 0.7.1) added a new media setting {{{pjsua_media_config.audio_frame_ptime}}}, or in older PJSUA-LIB, this setting is hard-coded in {{{PTIME}}} macro in {{{pjsua_media.c}}}. This setting specifies the length of audio frame in milliseconds, to be set to both the sound device and to the conference bridge.
+
+ The previous default value is 20 milliseconds, while the default value is now set to 10 milliseconds. Changing this value from 20 to 10 milliseconds will reduce sound device latency by about 100 milliseconds and end-to-end audio latency by about 200 milliseconds.
+
+ pjsip version 0.9 and later::
+ The default value is now 20ms, and changing this to 10ms will only reduce latency slightly.
 
 ==== Choose PJMEDIA_SOUND_BUFFER_COUNT carefully ====
 
-The {{{PJMEDIA_SOUND_BUFFER_COUNT}}} in {{{pjmedia/config.h}}} specifies the number of audio frames in the conference bridge buffer. Larger number is better for sound stability and to accommodate sound devices that are unable to send frames in timely manner, however it would probably cause more audio delay.
-
-The default value was 16, and this has been changed to 6 by ticket #394 (release 0.7.1).
+ Older pjsip: ::
+ The {{{PJMEDIA_SOUND_BUFFER_COUNT}}} in {{{pjmedia/config.h}}} specifies the number of audio frames in the conference bridge buffer. Larger number is better for sound stability and to accommodate sound devices that are unable to send frames in timely manner, however it would probably cause more audio delay.
+
+ The default value was 16, and this has been changed to 6 by ticket #394 (release 0.7.1).
+
+ pjsip version 0.9 and later: ::
+ PJSIP now uses adaptive delay buffer to automatically learn the amount of buffers required to handle the burst. The semantic of PJMEDIA_SOUND_BUFFER_COUNT has been changed, and rather now it means the maximum amount of buffering that will be handled by the delay buffer. Lowering the value will not affect latency, and may cause unnecessary WSOLA processing (to discard the excessive frames because the buffer is full) and may even produce audio impairments, hence it's no longer recommended.
+
 
 ==== Optimizing Sound Device Latency ====
 
-On Windows with !PortAudio backend (the default sound driver backend), with the default setting !DirectSound does have lower latency than WMME, but !DirectSound has more erratic timing. This bad timing causes additional delay in the processing of packets in the jitter buffer; there can be up to 150ms delay between packet arrival time and the time when the frame is actually picked up from the jitter buffer, regardless of jitter buffer setting.
-
-Release 0.7.1 has been tuned to provide better latency, with providing these settings:
- - ticket #384 gives the ability for application to choose !DirectSound over WMME. Default is no
- - ticket #395 adds a configuration to control the maximum buffer latency for WMME, with default value is 60 (milliseconds). For similar setting for !DirectSound, application needs to set {{{PA_MIN_LATENCY_MSEC}}} environment variable.
-
-With default WMME backend and 60 milliseconds buffering, application should have much better latency than with using !DirectSound.
+ Older pjsip: ::
+ On Windows with !PortAudio backend (the default sound driver backend), with the default setting !DirectSound does have lower latency than WMME, but !DirectSound has more erratic timing. This bad timing causes additional delay in the processing of packets in the jitter buffer; there can be up to 150ms delay between packet arrival time and the time when the frame is actually picked up from the jitter buffer, regardless of jitter buffer setting.
+
+ Release 0.7.1 has been tuned to provide better latency, with providing these settings:
+   - ticket #384 gives the ability for application to choose !DirectSound over WMME. Default is no
+   - ticket #395 adds a configuration to control the maximum buffer latency for WMME, with default value is 60 (milliseconds). For similar setting for !DirectSound, application needs to set {{{PA_MIN_LATENCY_MSEC}}} environment variable.
+
+  With default WMME backend and 60 milliseconds buffering, application should have much better latency than with using !DirectSound.
+
+ pjsip version 0.9 and later: ::
+ The maximum buffer latency setting above has been deprecated, and instead we introduced two pjmedia settings to control the sound device buffer size/latency value: {{{PJMEDIA_SND_DEFAULT_REC_LATENCY}}} and {{{PJMEDIA_SND_DEFAULT_PLAY_LATENCY}}}. The default values for both settings are 100 ms. Application can also change the latency at run-time by calling {{{pjmedia_snd_set_latency()}}} '''before''' opening the sound device.
+
+ Setting the latency to lower value will affect the audio stability (it will make it more sensitive to CPU disruptions), so choose the value carefully.
+
 
 ==== Optimizing Jitter Buffer Latency ====
 
-The jitter buffer parameters are specified in {{{pjsua_media_config}}}, with the relevant fields are:
- - '''jb_min_pre''' - Jitter buffer minimum prefetch delay in msec. With the default settings, it will use the hard-coded value in {{{stream.c}}}, that is '''60''' ms.
- - '''jb_max_pre''' - Jitter buffer maximum prefetch delay in msec. With the default settings, it will use the hard-coded value in {{{stream.c}}}, that is '''240''' ms.
- - '''jb_max''' - Set maximum delay that can be accomodated by the jitter buffer msec. The default value is also hard-coded  in {{{stream.c}}}, that is '''360''' ms.
+ Older pjsip: ::
+ The jitter buffer parameters are specified in {{{pjsua_media_config}}}, with the relevant fields are:
+   - '''jb_min_pre''' - Jitter buffer minimum prefetch delay in msec. With the default settings, it will use the hard-coded value in {{{stream.c}}}, that is '''60''' ms.
+   - '''jb_max_pre''' - Jitter buffer maximum prefetch delay in msec. With the default settings, it will use the hard-coded value in {{{stream.c}}}, that is '''240''' ms.
+   - '''jb_max''' - Set maximum delay that can be accomodated by the jitter buffer msec. The default value is also hard-coded  in {{{stream.c}}}, that is '''360''' ms.
+
+ pjsip version 0.9 and later: ::
+ The jitter buffer implementation has been modified and it should reduce latency significantly. 
+
 
 === How to run PJSUA without sound device? === #no-snd-dev
@@ -253 +274 @@
 === I didn't hear ringing tones when I make a call, why? === #ringtone
 
-''pjsua'' does not play any ring tones when the call gets 180/Ringing, since it's just a simple application for demonstration purpose. When you're building your own application, you can add this feature yourself. You can play a ringing tone by using the tone generator as described above (but connecting the tone generator to the sound device instead of to the call), or you can play your own WAV file instead.
+ older pjsip: ::
+ ''pjsua'' does not play any ring tones when the call gets 180/Ringing, since it's just a simple application for demonstration purpose. When you're building your own application, you can add this feature yourself. You can play a ringing tone by using the tone generator as described above (but connecting the tone generator to the sound device instead of to the call), or you can play your own WAV file instead.
+
+ pjsip version 0.9 and later: ::
+ pjsua now supports generating local ringback tones!