<div dir="ltr">The final three patches are now on Gerrit:<div>* <a href="https://gerrit.asterisk.org/#/c/4654/" target="_blank">https://gerrit.asterisk.org/<wbr>#/c/4654/</a></div><div>* <a href="https://gerrit.asterisk.org/#/c/3524/" target="_blank">https://gerrit.asterisk.org/<wbr>#/c/3524/</a></div><div>* <a href="https://gerrit.asterisk.org/#/c/3525/" target="_blank">https://gerrit.asterisk.org/<wbr>#/c/3525/</a></div><div><br></div><div>4654 fails to build as it requires libsndfile (which is not present to anonymous coward9.</div><div><br></div><div>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></div><div><br></div><div>Happy X-mas.</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature">---<br>Dennis Guse</div></div>
<br><div class="gmail_quote">On Wed, Nov 30, 2016 at 10:20 PM, Richard Mudgett <span dir="ltr"><<a href="mailto:rmudgett@digium.com" target="_blank">rmudgett@digium.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Wed, Nov 30, 2016 at 8:04 AM, Joshua Colp <span dir="ltr"><<a href="mailto:jcolp@digium.com" target="_blank">jcolp@digium.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_-4230389112293293843gmail-">On Fri, Nov 25, 2016, at 10:20 AM, Dennis Guse wrote:<br>
</span><span class="m_-4230389112293293843gmail-">> Hey guys,<br>
><br>
> we continued working on our largest changeset: <a href="https://gerrit" rel="noreferrer" target="_blank">https://gerrit</a>.<br>
> <a href="http://asterisk.org/#/c/3524/" rel="noreferrer" target="_blank">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>
</span>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></blockquote><div><br></div></div></div><div>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></div><div>then you initialize the binarual data as you do currently.<br></div><div><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></div><div>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.<span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><br><div>Richard<br></div></font></span></div><br></div></div>
<br>--<br>
______________________________<wbr>______________________________<wbr>_________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">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" rel="noreferrer" target="_blank">http://lists.digium.com/<wbr>mailman/listinfo/asterisk-dev</a><br></blockquote></div><br></div>