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 <rmudg...@digium.com> wrote: > > > On Wed, Nov 30, 2016 at 8:04 AM, Joshua Colp <jc...@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 >
-- _____________________________________________________________________ -- 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
