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

[Dennis Guse]

Since all patches are now merged, this will be the last eMail from me on
this thread.
Here are just the steps to setup the binaural synthesis and the required
stereo-capable OPUS module:

```
git clone http://gerrit.asterisk.org/asterisk
git clone  https://github.com/SteakConferencing/asterisk-opus

cp asterisk-opus/codec/* asterisk/codec

cd asterisk

./configure

make menuconfig
#Enable "Bridging modules"/binaural_rendering_in_bridge_softmix
#Enable "Codec Translators"/codec_opus_open_source
#Disable "Channel Drivers"/chan_sip - might avoid some issues if WebRTC is
desired ;)

make
```

Tested with Asterisk (comit-id 00d1c7ddd28557aa845c3522956852a60310df96).

Enjoy!
---
Dennis Guse

On Fri, Dec 23, 2016 at 12:42 PM, Dennis Guse <
dennis.guse at alumni.tu-berlin.de> wrote:
>
> 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/20170302/2b68bf6f/attachment.html>