[Asterisk-Dev] meetme enhancements to improve efficiency

Kevin P. Fleming kpfleming at digium.com
Fri Dec 2 09:13:18 MST 2005


Steve Kann wrote:

> Actually, they other three aren't getting any mixing in this case, they 
> just directly get the frames from the speaker.  (they're not decoded and 
> recoded at all, just send straight along).    This means:
> 
> (1) that they get exactly the same audio quality as if they were 
> directly bridged, with no generational loss.
> (2) There is zero transcoding happening.

OK, my example was a poor choice then. However, I see what you are doing 
now... in the normal case where only one person is speaking, you don't 
'mix' at all, since there is nothing to mix. Granted, this dependent on 
the quality of your 'talk detection' algorithm, but we are already doing 
that successfully :-)

It also works primarily only for VOIP channels; bringing Zap channels 
into the conference will necessitate mixing again.

> Right.   app_conference breaks the rule that we must always transmit 
> encoded audio to participants which come from the same encoder.    In 
> practice, with all of the codecs we've done this with (which is really 
> just GSM and speex that I've done this extensively with, but it should 
> be fine with others), this doesn't lead to any noticable negative 
> effects.  This is because in practice:
> 
> 1) This generally happens when both encoder states are starting from a 
> "silence" state, so they're pretty much the same, or
> 2) It's happening when there's multiple speakers speaking at the same 
> time, in which case with all the crosstalk, you don't really notice 
> anything.

Understood. It would be interesting to try this with G.729 as well, 
although I doubt it will be any more state-sensitive than Speex.

In any case, this is a very different architecture than app_meetme, and 
I don't think there's a reasonable way to merge the two together. It 
could certainly be possible to optimize the mixed audio -> encoded audio 
path by using a single encoder for all non-speakers (and 'break the 
rules' as you say), but the other optimizations would be harder to work 
into app_meetme, since it is very much based around mixing all the 
streams through Zaptel.



More information about the asterisk-dev mailing list