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

[Dennis Guse]

The final three patches are now on Gerrit:
* https://gerrit.asterisk.org/#/c/4654/
* https://gerrit.asterisk.org/#/c/3524/
* https://gerrit.asterisk.org/#/c/3525/

4654 fails to build as it requires libsndfile (which is not present to
anonymous coward9.

Finally, we will port our opus changes (ie. stereo) to
https://github.com/traud/asterisk-opus

Happy X-mas.




---
Dennis Guse

On Wed, Nov 30, 2016 at 10:20 PM, Richard Mudgett <rmudgett at digium.com>
wrote:

>
>
> 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
>
>
> --
> _____________________________________________________________________
> -- 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/20161223/c1781376/attachment.html>