[prev in list] [next in list] [prev in thread] [next in thread]
List: asterisk-dev
Subject: Re: [asterisk-dev] Asterisk goes Spatial Conferencing: the STEAK project
From: Dennis Guse <dennis.guse () alumni ! tu-berlin ! de>
Date: 2016-12-23 11:42:49
Message-ID: CAEeULf2eFnfHP-_2W8oM8LPJH-ZbKAWWA4cciZ6aTh8xdKb3sQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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@digium.com>
wrote:
>
>
> On Wed, Nov 30, 2016 at 8:04 AM, Joshua Colp <jcolp@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
>
[Attachment #5 (text/html)]
<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>
--
_____________________________________________________________________
-- 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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic