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

[Joshua Colp]

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.

-- 
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org