[asterisk-dev] Asterisk goes Spatial Conferencing: the STEAK project

[Richard Mudgett]

On Wed, Nov 30, 2016 at 8:04 AM, Joshua Colp <jcolp at digium.com> wrote:

> On Fri, Nov 25, 2016, at 10:20 AM, Dennis Guse wrote:
> > Hey guys,
> >
> > we continued working on our largest changeset: https://gerrit.
> > asterisk.org/#/c/3524/
> > Besides the copyright of HRTFs (still under investigation from our side),
> > the only issue on our side is the introduced `settings_lock` (defined in
> > bridge.h:254).
> > This lock is used in addition to the bridge-lock in bridge_softmix:1093.
> >
> > The issue the settings_lock solves is that during bridge startup
> > (actually
> > `softmix_mixing_thread()`) we need to know the configuration parameters
> > (is
> > binaural active or not?).
> > Since the startup of the mixing thread and parsing the configuration is
> > asynchronous (at least our understanding: we saw race conditions), we use
> > the 2nd lock to wait until configuration information is available before
> > really starting the mixing thread.
> > We could avoid introducing the settings_lock by repeatedly checking in
> > the
> > mixing loop.
> > However, this doesn't sound like a good idea...
> > Thus, a bridge now has two locks (ast_bridge_lock and the settings_lock),
> > which is some overengineering.
> >
> > Is there a better solution to addressing this issue?
>
> Without changing things such that settings and attributes could be
> passed in during the bridge creation or making bridge creation a two
> stage process (both of which are larger changes than I'd like to see) I
> don't see a way to do this during bridge creation. Is it possible to
> check in the bridge loop to see that binaural has been enabled but not
> set up and set it up? This should not impact the mixing loop a large
> amount during normal operation and overcomes the problem that the
> settings_lock has right now. It would also allow API control to toggle
> binaural on/off at a bridge level.
>

The new settings lock is not necessary.  You can simply defer the binarual
initialization to when the first channel enters the bridge.  The confbridge
bridge
is created and the binarual active option is set before any channels could
possibly enter the bridge.  The softmix_mixing_thread() will either not have
started yet or be waiting for the first channel to join.

If the first channel has joined before the softmix_mixing_thread() has
started
then you initialize the binarual data as you do currently.

If the softmix_mixing_thread() is waiting for the first channel to join
then it
is in the ast_cond_wait() because bridge->num_active is zero.

You just need to protect against initializing more than once.  The
protection
can be done completely inside the bridge_softmix technology using the
technology's private data to remember it.

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20161130/0e7acdbd/attachment.html>