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.g...@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 <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