I know that Asterisk on virtual machine require a timing source. What would you suggest to use for timing? We will plan to use only SIP and IAX2.
If you’re on a newish kernel (something later than v2.6.22), can use app_confbridge instead of app_meetme, and do not need app_page
(unless you can can join the beta / wait for Asterisk 11) you can simply use res_timining_timerfd. This will free you from any kernel module dependencies.
If that won’t work for you, you can still use DAHDI in a virtual machine and it will provide timing for your Asterisk process via kernel timers. If you’re using app_meetme, change DAHDI_CHUNKSIZE
from 8 (1ms) to 80 (10ms). There isn’t anything to be gained from a
1ms mixing chunk if you have no need to bridge audio from one card to another when audio is being delivered to the kernel modules in
20ms chunks. This can have a big impact on reducing the load on the CPU.
2012/9/13 Shaun Ruffell
How do you specify this ?
Passing options when compiling asterisk from source ?
It should build by default if your platform supports it.
In menuconfig, check that the module is enabled:
“Resource Modules” : [*] res_timing_timerfd
Ensure that res_timing_timerfd.so is loaded in
noload => res_timing_dahdi.so
noload => res_timing_pthread.so
load => res_timing_timerfd.so
And you can ensure you have a timing source in asterisk with timing test, which will also show which timing source you’re using:
*CLI> timing test
Attempting to test a timer with 50 ticks per second.
Using the ‘timerfd’ timing module for this test.
It has been 1000 milliseconds, and we got 50 timer ticks
You may also want to read over this wiki page:
Thanks Shaun. Very usefully head-up.
I did some research on this subject and still do not understand. Why we use modules if asterisk can obtain timing directly from kernel?
Probably longer than it needs to be but…
Asterisk needs timing information via a kernel file descriptor that can be passed into to the poll()  or select() system calls. This allows Asterisk to sleep while waiting for either a network packet to come in or one of several time intervals to expire in the same system call which is very efficient.
DAHDI historically provided this service via /dev/dahdi/timer. DAHDI was a good choice to provide a timing service since Asterisk typically wanted VOIP traffic synchronized with any telephony hardware installed. If there was not telephony hardware DAHDI could use internal kernel interfaces to find the best source of timing for Asterisk (generic kernel timers, Real-Time Clock, High Resolution timers, etc..).
Using DAHDI was (and is) a natural choice but updating kernels can be more difficult since DAHDI must be recompiled every time the kernel is updated. This unnecessarily increases the administration burden when there is not any telephony hardware to synchronize with.
To reduce the dependency on DAHDI, res_timing_pthread was created in Asterisk version 1.6.1 . This implementation could provide timing via file descriptors without requiring DAHDI to be installed. It uses a pipe() and a thread. The thread will sleep for a period of time and then write to one end of the pipe when the timer fires. res_timing_pthread is more system intensive–creates a thread that must be scheduled, the scheduling of that thread determines the timeliness of the timer firing, and the extra system calls required to accomplish the same task–and I believe it is advisable to avoid res_timing_pthread unless you have no other choice.
It was not until kernel version 2.6.25 that Linux provided a standard interface for configuring timers that signaled via file descriptors, the timerfd interface . Now Asterisk had a standard kernel interface which provided essentially the same service that DAHDI’s /dev/dahdi/timer did without needing to install DAHDI or creating a separate thread which wrote to a pipe and res_timing_timerfd was first release in Asterisk 1.6.2 . The problem is that timerfd_create() is not available on all platforms Asterisk must support. Also, if you have telephony hardware installed it is still generally best to synchronize to the clock on the telephony hardware to minimize audio problems caused by mismatches in clock rates. But if available and you don’t have any other dependency on DAHDI (app_meetme, app_page, etc…), timerfd should be your first choice for timing source.
So given these different methods of obtaining timing, Asterisk needed a way to abstract them so that other parts of the system had a standard way to get a file descriptor which could be configured to fire at certain intervals. That is why the timing interface  and various timing modules were created. It allows the Asterisk administrator to use the timing source that works best for them.
That’s why, to the best of my knowledge, Asterisk uses modules even though it can now obtain timing directly from the kernel.