<div dir="ltr">Since all patches are now merged, this will be the last eMail from me on this thread.<br>Here are just the steps to setup the binaural synthesis and the required stereo-capable OPUS module:<div><br></div><div>```<br>git clone <a href="http://gerrit.asterisk.org/asterisk">http://gerrit.asterisk.org/asterisk</a><br>git clone  <a href="https://github.com/SteakConferencing/asterisk-opus">https://github.com/SteakConferencing/asterisk-opus</a><br><br>cp asterisk-opus/codec/* asterisk/codec<br><br>cd asterisk<br><br>./configure<br><br>make menuconfig<br>#Enable "Bridging modules"/binaural_rendering_in_bridge_softmix<br>#Enable "Codec Translators"/codec_opus_open_source<br>#Disable "Channel Drivers"/chan_sip - might avoid some issues if WebRTC is desired ;)<br><br>make<br>```<br><br>Tested with Asterisk (comit-id 00d1c7ddd28557aa845c3522956852a60310df96).<br><br></div><div>Enjoy!</div><div>---<br>Dennis Guse<br><br>On Fri, Dec 23, 2016 at 12:42 PM, Dennis Guse <<a href="mailto:dennis.guse@alumni.tu-berlin.de">dennis.guse@alumni.tu-berlin.de</a>> wrote:<br>><br>> The final three patches are now on Gerrit:<br>> * <a href="https://gerrit.asterisk.org/#/c/4654/">https://gerrit.asterisk.org/#/c/4654/</a><br>> * <a href="https://gerrit.asterisk.org/#/c/3524/">https://gerrit.asterisk.org/#/c/3524/</a><br>> * <a href="https://gerrit.asterisk.org/#/c/3525/">https://gerrit.asterisk.org/#/c/3525/</a><br>><br>> 4654 fails to build as it requires libsndfile (which is not present to anonymous coward9.<br>><br>> Finally, we will port our opus changes (ie. stereo) to <a href="https://github.com/traud/asterisk-opus">https://github.com/traud/asterisk-opus</a><br>><br>> Happy X-mas.<br>><br>><br>><br>><br>> ---<br>> Dennis Guse<br>><br>> On Wed, Nov 30, 2016 at 10:20 PM, Richard Mudgett <<a href="mailto:rmudgett@digium.com">rmudgett@digium.com</a>> wrote:<br>>><br>>><br>>><br>>> On Wed, Nov 30, 2016 at 8:04 AM, Joshua Colp <<a href="mailto:jcolp@digium.com">jcolp@digium.com</a>> wrote:<br>>>><br>>>> On Fri, Nov 25, 2016, at 10:20 AM, Dennis Guse wrote:<br>>>> > Hey guys,<br>>>> ><br>>>> > we continued working on our largest changeset: <a href="https://gerrit">https://gerrit</a>.<br>>>> > <a href="http://asterisk.org/#/c/3524/">asterisk.org/#/c/3524/</a><br>>>> > Besides the copyright of HRTFs (still under investigation from our side),<br>>>> > the only issue on our side is the introduced `settings_lock` (defined in<br>>>> > bridge.h:254).<br>>>> > This lock is used in addition to the bridge-lock in bridge_softmix:1093.<br>>>> ><br>>>> > The issue the settings_lock solves is that during bridge startup<br>>>> > (actually<br>>>> > `softmix_mixing_thread()`) we need to know the configuration parameters<br>>>> > (is<br>>>> > binaural active or not?).<br>>>> > Since the startup of the mixing thread and parsing the configuration is<br>>>> > asynchronous (at least our understanding: we saw race conditions), we use<br>>>> > the 2nd lock to wait until configuration information is available before<br>>>> > really starting the mixing thread.<br>>>> > We could avoid introducing the settings_lock by repeatedly checking in<br>>>> > the<br>>>> > mixing loop.<br>>>> > However, this doesn't sound like a good idea...<br>>>> > Thus, a bridge now has two locks (ast_bridge_lock and the settings_lock),<br>>>> > which is some overengineering.<br>>>> ><br>>>> > Is there a better solution to addressing this issue?<br>>>><br>>>> Without changing things such that settings and attributes could be<br>>>> passed in during the bridge creation or making bridge creation a two<br>>>> stage process (both of which are larger changes than I'd like to see) I<br>>>> don't see a way to do this during bridge creation. Is it possible to<br>>>> check in the bridge loop to see that binaural has been enabled but not<br>>>> set up and set it up? This should not impact the mixing loop a large<br>>>> amount during normal operation and overcomes the problem that the<br>>>> settings_lock has right now. It would also allow API control to toggle<br>>>> binaural on/off at a bridge level.<br>>><br>>><br>>> The new settings lock is not necessary.  You can simply defer the binarual<br>>> initialization to when the first channel enters the bridge.  The confbridge bridge<br>>> is created and the binarual active option is set before any channels could<br>>> possibly enter the bridge.  The softmix_mixing_thread() will either not have<br>>> started yet or be waiting for the first channel to join.<br>>><br>>> If the first channel has joined before the softmix_mixing_thread() has started<br>>> then you initialize the binarual data as you do currently.<br>>><br>>> If the softmix_mixing_thread() is waiting for the first channel to join then it<br>>> is in the ast_cond_wait() because bridge->num_active is zero.<br>>><br>>> You just need to protect against initializing more than once.  The protection<br>>> can be done completely inside the bridge_softmix technology using the<br>>> technology's private data to remember it.<br>>><br>>> Richard<br>>><br>>><br>>> --<br>>> _____________________________________________________________________<br>>> -- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com">http://www.api-digital.com</a> --<br>>><br>>> asterisk-dev mailing list<br>>> To UNSUBSCRIBE or update options visit:<br>>>    <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br>><br>><br></div></div>