[asterisk-dev] Asterisk goes Spatial Conferencing: the STEAK project
Dennis Guse
dennis.guse at alumni.tu-berlin.de
Fri Nov 25 08:20:18 CST 2016
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?
---
Dennis Guse
---
Dennis Guse
On Tue, Oct 25, 2016 at 5:31 PM, Joshua Colp <jcolp at digium.com> wrote:
> Dennis Guse wrote:
>
>> Thanks Joshua,
>>
>> just to be clear that I understood it correctly.
>> 1. We would extend ast_format [2] with the additional field `uint
>> channel_count:1`
>> 2. We would modify `opus_parse_sdp_fmtp` [1] to set
>> `cloned->channel_count=2`on the `ast_format` to be returned.
>>
>> Would this be acceptable or is this conceptually an issue?
>>
>
> The format structure is opaque so you will need to use set and get
> functions on the format, but that is acceptable.
>
>
> --
> 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
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20161125/92e6e55f/attachment.html>
More information about the asterisk-dev
mailing list