diff options
Diffstat (limited to 'doc/timing.txt')
| -rw-r--r-- | doc/timing.txt | 90 |
1 files changed, 90 insertions, 0 deletions
diff --git a/doc/timing.txt b/doc/timing.txt new file mode 100644 index 000000000..21da71cfe --- /dev/null +++ b/doc/timing.txt @@ -0,0 +1,90 @@ +Asterisk Timing Interfaces +------------------------------------- +In the past, if internal timing were desired for an Asterisk system, then the +only source acceptable was from DAHDI. Beginning with Asterisk 1.6.1, a new +timing API was introduced which allows for various timing modules to be used. +Included with Asterisk are the following timing modules: + +res_timing_pthread.so +res_timing_dahdi.so +res_timing_timerfd.so (Beginning with Asterisk 1.6.2) + +res_timing_pthread uses the POSIX pthreads library in order to provide timing. +Since the code uses a commonly-implemented set of functions, res_timing_pthread +is portable to many types of systems. In fact, this is the only timing source +currently usable on a non-Linux system. Due to the fact that a single userspace +thread is used to provide timing for all users of the timer, res_timing_pthread +is also the least efficient of the timing sources and has been known to lose +its effectiveness in a heavily-loaded environment. + +res_timing_dahdi uses timing mechanisms provided by DAHDI. This method of +timing was previously the only means by which Asterisk could receive timing. It +has the benefit of being efficient, and if a system is already going to use +DAHDI hardware, then it makes good sense to use this timing source. If, +however, there is no need for DAHDI other than as a timing source, this timing +source may seem unattractive. For people who are upgrading from 1.4 and are used +to the old ztdummy timing interface, res_timing_dahdi provides the interface +to dahdi_dummy, which is ztdummy's replacement. + +res_timing_timerfd uses a timing mechanism provided directly by the Linux +kernel. This timing interface is only available on Linux systems using a kernel +version at least 2.6.25 and a glibc version at least 2.8. This interface has +the benefit of being very efficient, but at the time this is being written, +it is a relatively new feature on Linux, meaning that its availability is not +widespread. + +What Asterisk does with the Timing Interfaces +--------------------------------------------- +By default, Asterisk will build and load all of the timing interfaces. These +timing interfaces are "ordered" based on a hard-coded priority number defined +in each of the modules. As of the time of this writing, the preferences for the +modules is the following: res_timing_timerfd.so, res_timing_dahdi.so, +res_timing_pthread.so. + +The only functionality that requires internal timing is IAX2 trunking. It may +also be used when generating audio for playback, such as from a file. Even +though internal timing is not a requirement for most Asterisk functionality, +it may be advantageous to use it since the alternative is to use timing based +on incoming frames of audio. If there are no incoming frames or if the incoming +frames of audio are from an unreliable or jittery source, then the +corresponding outgoing audio will also be unreliable, or even worse, +nonexistent. Using internal timing prevents such unreliability. + +Customizations/Troubleshooting +--------------------------------------------- +Now that you know Asterisk's default preferences for timing modules, you may +decide that you have a different preference. Maybe you're on a timerfd-capable +system but you would prefer to get your timing from DAHDI since you already are +using DAHDI to drive your hardware. + +Alternatively, you may have been directed to this document due to an error you +are currently experiencing with Asterisk. If you receive an error message +regarding timing not working correctly, then you can use one of the following +suggestions to disable a faulty timing module. + +1. Don't build the timing modules you know you will not use. You can disable +the compilation of any of the timing modules using menuselect. The modules are +listed in the "Resource Modules" section. Note that if you have already built +Asterisk and have received an error about a timing module not working properly, +it is not sufficient to disable it from being built. You will need to remove +the module from your modules directory (by default, /usr/lib/asterisk/modules) +to make sure that it does not get loaded again. + +2. Build, but do not load the timing modules you know you will not use. You can +edit modules.conf using "noload" lines to disable the loading of specific +timing modules by default. Based on the note in the section above, you may +realize that your Asterisk setup does not require internal timing at all. If +this is the case, you can safely noload all timing modules. + +Important Notes +---------------------------------------------- +Some confusion has arisen regarding the fact that non-DAHDI timing interfaces +are available now. One common misconception which has arisen is that since +timing can be provided elsewhere, DAHDI is no longer required for using the +MeetMe application. Unfortunately, this is not the case. In addition to +providing timing, DAHDI also provides a conferencing engine which the MeetMe +application requires. + +Starting with Asterisk 1.6.2, however, there will be a new application, +ConfBridge, which will be capable of conference bridging without the use +of DAHDI's built-in mixing engine. |