|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Constant for NULL sound backend.
Constant for PortAudio sound backend.
Constant for Win32 DirectSound sound backend.
Constant for Win32 MME sound backend.
When this is set, pjmedia will not provide any sound device backend. Application will have to provide its own sound device backend and link the application with it.
Unless specified otherwise, sound device uses PortAudio implementation by default.
Specify whether we prefer to use DirectSound on Windows. Default: 0
Specify sound device latency default, in milisecond.
Specify whether delay buffer is used for sound device. When delay buffer is enabled, the sound device callback will be called one after another evenly. The delay buffer also performs the best delay calculation for the sound device, and will try to limit the delay caused by uneven callback calls to this delay. When this setting is enabled, the PJMEDIA_SOUND_BUFFER_COUNT macro will specify the maximum size of the delay buffer.
This denotes implementation of WSOLA using null algorithm. Expansion will generate zero frames, and compression will just discard some samples from the input. This type of implementation may be used as it requires the least processing power.
This denotes implementation of WSOLA using fixed or floating point WSOLA algorithm. This implementation provides the best quality of the result, at the expense of one frame delay and intensive processing power requirement.
This denotes implementation of WSOLA algorithm with faster waveform similarity calculation. This implementation provides fair quality of the result with the main advantage of low processing power requirement.
Specify type of Waveform based Similarity Overlap and Add (WSOLA) backend implementation to be used. WSOLA is an algorithm to expand and/or compress audio frames without changing the pitch, and used by the delaybuf and as PLC backend algorithm. Default is PJMEDIA_WSOLA_IMP_WSOLA
Specify number of sound buffers. 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 (and definitely will take more memory). One individual buffer is normally 10ms or 20 ms long, depending on ptime settings (samples_per_frame value). The setting here currently is used by the conference bridge, the splitter combiner port, and dsound.c. Default: 6
Specify which A-law/U-law conversion algorithm to use. By default the conversion algorithm uses A-law/U-law table which gives the best performance, at the expense of 33 KBytes of static data. If this option is disabled, a smaller but slower algorithm will be used.
Unless specified otherwise, G711 codec is included by default.
No resampling.
Sample rate conversion using libresample.
Sample rate conversion using Speex.
Sample rate conversion using libsamplerate (a.k.a Secret Rabbit Code)
Select which resample implementation to use. Currently pjmedia supports:
Default is PJMEDIA_RESAMPLE_LIBRESAMPLE
Specify whether libsamplerate, when used, should be linked statically into the application. This option is only useful for Visual Studio projects, and when this static linking is enabled Default file player/writer buffer size.
Maximum frame duration (in msec) to be supported. This (among other thing) will affect the size of buffers to be allocated for outgoing packets.
Max packet size to support.
DTMF/telephone-event duration, in timestamp.
Number of packets received from different source IP address from the remote address required to make the stream switch transmission to the source address.
Specify whether RTCP should be advertised in SDP. This setting would affect whether RTCP candidate will be added in SDP when ICE is used. Application might want to disable RTCP advertisement in SDP to reduce the message size. Default: 1 (yes)
Interval to send RTCP packets, in msec
Tell RTCP to ignore the first N packets when calculating the jitter statistics. From experimentation, the first few packets (25 or so) have relatively big jitter, possibly because during this time, the program is also busy setting up the signaling, so they make the average jitter big. Default: 25.
Specify whether RTCP XR support should be built into PJMEDIA. Disabling this feature will reduce footprint slightly. Note that even when this setting is enabled, RTCP XR processing will only be performed in stream if it is enabled on run-time on per stream basis. See PJMEDIA_STREAM_ENABLE_XR setting for more info. Default: 1 (yes).
The RTCP XR feature is activated and used by stream if enable_rtcp_xr field of pjmedia_stream_info structure is non-zero. This setting controls the default value of this field. Default: 0 (disabled)
Specify how long (in miliseconds) the stream should suspend the silence detector/voice activity detector (VAD) during the initial period of the session. This feature is useful to open bindings in all NAT routers between local and remote endpoint since most NATs do not allow incoming packet to get in before local endpoint sends outgoing packets. Specify zero to disable this feature. Default: 600 msec (which gives good probability that some RTP packets will reach the destination, but without filling up the jitter buffer on the remote end).
Specify the maximum duration of silence period in the codec, in msec. This is useful for example to keep NAT binding open in the firewall and to prevent server from disconnecting the call because no RTP packet is received. This only applies to codecs that use PJMEDIA's VAD (pretty much everything including iLBC, except Speex, which has its own DTX mechanism). Use (-1) to disable this feature. Default: 5000 ms
Suggested or default threshold to be set for fixed silence detection or as starting threshold for adaptive silence detection. The threshold has the range from zero to 255.
Maximum silence threshold in the silence detector. The silence detector will not cut the audio transmission if the audio level is above this level. Default: 25
Speex Accoustic Echo Cancellation (AEC). By default is enabled.
This specifies the behavior of the SDP negotiator when responding to an offer, whether it should rather use the codec preference as set by remote, or should it rather use the codec preference as specified by local endpoint. For example, suppose incoming call has codec order "8 0 3", while local codec order is "3 0 8". If remote codec order is preferable, the selected codec will be 8, while if local codec order is preferable, the selected codec will be 3. If set to non-zero, the negotiator will use the codec order as specified by remote in the offer. Note that this behavior can be changed during run-time by calling pjmedia_sdp_neg_set_prefer_remote_codec_order(). Default is 1 (to maintain backward compatibility)
Support for sending and decoding RTCP port in SDP (RFC 3605). Default is equal to PJMEDIA_ADVERTISE_RTCP setting.
This macro controls whether pjmedia should include SDP rtpmap attribute for static payload types. SDP rtpmap for static payload types are optional, although they are normally included for interoperability reason. Note that there is also a run-time variable to turn this setting on or off, defined in endpoint.c. To access this variable, use the following construct
extern pj_bool_t pjmedia_add_rtpmap_for_static_pt;
// Do not include rtpmap for static payload types (<96)
pjmedia_add_rtpmap_for_static_pt = PJ_FALSE;
Default: 1 (yes)
This macro declares the payload type for telephone-event that is advertised by PJMEDIA for outgoing SDP. If this macro is set to zero, telephone events would not be advertised nor supported. If this value is changed to other number, please update the PJMEDIA_RTP_PT_TELEPHONE_EVENTS_STR too.
Macro to get the string representation of the telephone-event payload type.
Maximum tones/digits that can be enqueued in the tone generator.
The math's sine(), floating point. This has very good precision but it's the slowest and requires floating point support and linking with the math library.
Floating point approximation of sine(). This has relatively good precision and much faster than plain sine(), but it requires floating- point support and linking with the math library.
Fixed point using sine signal generated by Cordic algorithm. This algorithm can be tuned to provide balance between precision and performance by tuning the PJMEDIA_TONEGEN_FIXED_POINT_CORDIC_LOOP setting, and may be suitable for platforms that lack floating-point support.
Fast fixed point using some approximation to generate sine waves. The tone generated by this algorithm is not very precise, however the algorithm is very fast.
Specify the tone generator algorithm to be used. Please see http://trac.pjsip.org/repos/wiki/Tone_Generator for the performance analysis results of the various tone generator algorithms. Default value:
Specify the number of calculation loops to generate the tone, when PJMEDIA_TONEGEN_FIXED_POINT_CORDIC algorithm is used. With more calculation loops, the tone signal gets more precise, but this will add more processing. Valid values are 1 to 28. Default value: 10
Enable high quality of tone generation, the better quality will cost more CPU load. This is only applied to floating point enabled machines. By default it is enabled when PJ_HAS_FLOATING_POINT is set. This macro has been deprecated in version 1.0-rc3. Fade-in duration for the tone, in milliseconds. Set to zero to disable this feature. Default: 1 (msec)
Fade-out duration for the tone, in milliseconds. Set to zero to disable this feature. Default: 2 (msec)
The default tone generator amplitude (1-32767). Default value: 12288
Enable support for SRTP media transport. This will require linking with libsrtp from the third_party directory. By default it is enabled. Enable support to handle codecs with inconsistent clock rate between clock rate in SDP/RTP & the clock rate that is actually used. This happens for example with G.722 and MPEG audio codecs. See:
Also when this feature is enabled, some handling will be performed to deal with clock rate incompatibilities of some phones. By default it is enabled.
Transport info (pjmedia_transport_info) contains a socket info and list of transport specific info, since transports can be chained together (for example, SRTP transport uses UDP transport as the underlying transport). This constant specifies maximum number of transport specific infos that can be held in a transport info.
Maximum size in bytes of storage buffer of a transport specific info.
(C)2003-2008 Benny Prijono
| |