On Mon, Apr 25, 2011 at 10:07:56AM -0500, David Vossel wrote: > On Monday, April 25, 2011 9:49:05 AM, David Backeberg wrote: >> On Mon, Apr 25, 2011 at 10:40 AM, C. Savinovich >>> >>> Does this ConfBridge requires a hardware timing source? >> >> No, and neither does MeetMe with modern DAHDI. >> >>> Will I be able to use this on any virtual server without having the need >>> special changes to the VM setup? ... >> To mix audio, the code takes lots of audio slices and merges them with >> an algorithm. But if the underlying cpu doesn't provide consistent, >> reliable ticks, as potentially happens in virtualization, then good >> luck with what's going to happen to your audio mixing. > > The MeetMe dependency on DAHDI is for the audio mixing. ConfBridge has no > dependency on DAHDI for anything.
In my opinion if you don't have any telephony hardware, eliminating the dependency on DAHDI is a good thing if possible. One less thing to install, compile, update, and worry about. However to clarify, DAHDI by default does not currently rely on a consistent tick when there is not a physical hardware timing source installed. What DAHDI requires is accurate sense of wall time and the ability to run at around 10ms intervals. This allows it to know how much audio to mix each time the timer runs. This change from depending on a reliable tick to having a reliable notion of time is what was required to get DAHDI conferencing to work consistently in virtualized environments. Also, I'm not surprised that a purely userspace solution (again, when not used in conjunction with any real telephony hardware) should offer higher performance because: a) There are two less userspace <-> kernel transitions for each packet to mix. b) I imagine each independent conference is/can be mixed in parallel on SMP systems. DAHDI conferencing currently mixes all channels in the context of either the timer or the "master_span". So with conferencing you are always (currently) limited by what can be done on a single core. c) DAHDI often times perform extra SLIN <-> U/A-law translations when conferencing. Channels queue up audio in the companded form (ulaw or alaw). So if you have a DADHI channel in linear mode, the audio will get companded to ulaw on write, the timer runs and transcodes the audio to signed linear format for mixing, then the mixed audio is transcoded back to ulaw to queue on the channel, then transcoded back to linear when asterisk reads from the channel. It is possible to improve b) and c). The intent is to eventually do so for users who for various reasons must use MeetMe. However that work is still out in the future. Yes...this email is not 100% related to the ConfBridge announcement, but someone out there might find it interesting... Cheers, Shaun -- Shaun Ruffell Digium, Inc. | Linux Kernel Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: www.digium.com & www.asterisk.org -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users