Re: [asterisk-dev] Regarding realtime audio streaming from mixmonitor
Hi Mani,
just out of curiosity: what is your actual goal?
Do you need to create the transcriptions live or afterwards?
Best,
Dennis
On Fri, 2018-07-06 at 13:28 +0530, Mani Kanta Gadde wrote:
> Hi,
> We are trying to stream audio coming from calls to an NLP engine to get the
> text transcription, for this we created a socket in app_mixmonitor.c and we
> are writing audio frames to socket descriptor.
> We have tried with TCP(SOCK_STREAM) and UDP(SOCK_DGRAM) protocols to send the
> audio frames to the socket server.
>
> We are using latest asterisk complied from GitHub source code (asterisk repo).
>
> Here are some of the suggestions I found on asterisk forums
> http://forums.asterisk.org/viewtopic.php?f=13=89365#p196720
> on this thread, it was suggested to use CHANSPY, but we have edited
> mixmonitor code to both record and stream in realtime, which has sufficed our
> needs.
>
> Here is the socket code we used inside the mixmonitor_thread function in
> app_mixmonitor.c file.
>
> +
> + int sockfd;
> + char buffer[1024];
> + char *hello = "Hello from client";
> + struct sockaddr_in servaddr;
> +
> + // Creating socket file descriptor
> + if ( (sockfd = socket(AF_INET, SOCK_STREAM, 0)) < 0 ) {
> + ast_log(LOG_NOTICE, "socket creation failed");
> +// exit(EXIT_FAILURE);
> + }
> +
> + memset(, 0, sizeof(servaddr));
> +
> + // Filling server information
> + servaddr.sin_family = AF_INET;
> + servaddr.sin_port = htons(8080);
> + servaddr.sin_addr.s_addr = INADDR_ANY;
> +
> + if (connect(sockfd,(struct sockaddr *) ,sizeof(servaddr)) < 0)
> + ast_log(LOG_ERROR, "ERROR connecting\n");
> + ast_log(LOG_NOTICE, "socket connected with server \n");
> +
> + //socket code ends here
>
> and here is the code of writing audio frames to the socket.
>
> for (cur = fr; cur; cur = AST_LIST_NEXT(cur, frame_list)) {
> ast_writestream(*fs, cur);
> + // writing to socket
> + write(sockfd, cur->data.ptr,
> cur->datalen);
> }
>
>
> And we were able to see the frames on the other side of the socket.
>
> We want to ask you if there is any other better approach to stream audio in
> real time.
>
> Thanks & Regards
> Manikanta
> Zemoso Technologies
>
--
Dennis Guse
--
_
-- 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
Re: [asterisk-dev] Asterisk goes Spatial Conferencing: the STEAK project
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
Re: [asterisk-dev] Asterisk goes Spatial Conferencing: the STEAK project
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
Re: [asterisk-dev] Asterisk goes Spatial Conferencing: the STEAK project
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? --- Dennis Guse --- Dennis Guse On Tue, Oct 25, 2016 at 5:31 PM, Joshua Colp <jc...@digium.com> wrote: > Dennis Guse wrote: > >> Thanks Joshua, >> >> just to be clear that I understood it correctly. >> 1. We would extend ast_format [2] with the additional field `uint >> channel_count:1` >> 2. We would modify `opus_parse_sdp_fmtp` [1] to set >> `cloned->channel_count=2`on the `ast_format` to be returned. >> >> Would this be acceptable or is this conceptually an issue? >> > > The format structure is opaque so you will need to use set and get > functions on the format, but that is acceptable. > > > -- > Joshua Colp > Digium, Inc. | Senior Software Developer > 445 Jan Davis Drive NW - Huntsville, AL 35806 - US > Check us out at: www.digium.com & www.asterisk.org > > > -- > _ > -- 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
Re: [asterisk-dev] Asterisk goes Spatial Conferencing: the STEAK project
Thanks Joshua,
just to be clear that I understood it correctly.
1. We would extend ast_format [2] with the additional field `uint
channel_count:1`
2. We would modify `opus_parse_sdp_fmtp` [1] to set
`cloned->channel_count=2`on the `ast_format` to be returned.
Would this be acceptable or is this conceptually an issue?
[1]
https://github.com/asterisk/asterisk/blob/master/res/res_format_attr_opus.c#L129
[2] http://doxygen.asterisk.org/trunk/d0/d98/structast__format.html
---
Dennis Guse
On Tue, Oct 25, 2016 at 12:33 PM, Joshua Colp <jc...@digium.com> wrote:
> Dennis Guse wrote:
>>
>> Hey,
>>
>> last week we started reworking the major patch [1] and could not solve
>> one issue.
>> At the moment, the softmix_bridge determines if interleaved stereo can
>> be written by querying ast_format's attribute data if OPUS is used ([2]):
>>
>> ```
>> struct opus_attr *attr = ast_format_get_attribute_data(format);
>> if (attr != NULL) {
>>if (attr->stereo == 1) {
>> *sample_rate = attr->maxplayrate;
>> return 1;
>>}
>> }
>> ```
>>
>> In fact, this approach is conceptually flawed as it introduces a direct
>> dependency between softmix_bridge and opus.
>> To remove this dependency, we tried to attach this information to
>> ast_codec (channel_count uint; default 1), but did not find a useful and
>> working method to write the newly introduced field.
>> We tried to set it in the res/res_format_attr_opus, ie, while parsing
>> the fmtp for OPUS.
>> Here, the ast_codec is const and we thus cannot be change.
>>
>> Any suggestions?
>> Are we approaching the issue from a "correct" perspective?
>
>
> The structure that is actually editable is the format (despite it being
> const in the format attribute module - this was done because it was never
> envisioned that a format attribute module would set anything directly on the
> format), this data would need to be there. The codec structure is an
> immutable structure which is shared by EVERY instance of a format that uses
> the codec. That is why you can't edit it.
>
>
> --
> Joshua Colp
> Digium, Inc. | Senior Software Developer
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US
> Check us out at: www.digium.com & www.asterisk.org
>
>
> --
> _
> -- 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
Re: [asterisk-dev] Asterisk goes Spatial Conferencing: the STEAK project
Hey,
last week we started reworking the major patch [1] and could not solve one
issue.
At the moment, the softmix_bridge determines if interleaved stereo can be
written by querying ast_format's attribute data if OPUS is used ([2]):
```
struct opus_attr *attr = ast_format_get_attribute_data(format);
if (attr != NULL) {
if (attr->stereo == 1) {
*sample_rate = attr->maxplayrate;
return 1;
}
}
```
In fact, this approach is conceptually flawed as it introduces a direct
dependency between softmix_bridge and opus.
To remove this dependency, we tried to attach this information to ast_codec
(channel_count uint; default 1), but did not find a useful and working
method to write the newly introduced field.
We tried to set it in the res/res_format_attr_opus, ie, while parsing the
fmtp for OPUS.
Here, the ast_codec is const and we thus cannot be change.
Any suggestions?
Are we approaching the issue from a "correct" perspective?
[1] https://gerrit.asterisk.org/#/c/3524/3
[2]
https://github.com/frahaase/Asterisk_Binaural/blob/master/asterisk_modifications/include/asterisk/interleaved_stereo.h
---
Dennis Guse
On Sun, Sep 18, 2016 at 6:27 AM, Leif Madsen <l...@leifmadsen.com> wrote:
> This is getting to be an old thread, but the "magic" for adding multiple
> changes is as follows:
>
> * use your working branch
> * make changes
> * git commit -a --amend
> * save...
> * git review
>
> This way, the same branch, with the initial commit, will be preserved
along
> with the same change ID.
>
> If you want to build upon an initial review, then you can do:
>
> * git checkout -b intial_changes
> * ...make changes and git review...
> * git checkout -b secondary_changes
> * ...make changes, git commit, git review...
>
> This will provide a second review, based upon the first one.
>
> If you need to change the first review, then that's fine. Follow the
initial
> procedure with making changes, and then git commit -a --amend, along with
> git review.
>
> If upstream (master) changes, and you need to rebase, that's fine too.
>
> * git checkout master
> * git fetch upstream (assuming you've run a git remote add upstream upstream Asterisk master>)
> * git rebase upstream/master
> * git review
>
> Then if you need to rebase the secondary patch, after rebasing your
> initial_changes branch, just rebase against origin/initial_changes, and
run
> your git review again.
>
> This way, you can chain changes, and not have to duplicate work. As the
> reviews happen and you make changes, you just keep committing against the
> same change ID (which happens when you git commit -a --amend; git review),
> and eventually things get merged down from the initial branch to your
> secondary, tertiary, etc branches.
>
> Hope that helps. Let me know if you need any additional help...
>
> Leif.
>
> On Tue, Aug 23, 2016 at 5:45 AM, Joshua Colp <jc...@digium.com> wrote:
>>
>> Dennis Guse wrote:
>>>
>>> Hey,
>>>
>>> we adjusted the patch set (fftw3 is now a ifdef-ed).
>>> Precisely, these two commits have been modified (basically adding
>>> HAVE_FFTW3)
>>>
>>> https://gerrit.asterisk.org/#/c/3522/
>>> https://gerrit.asterisk.org/#/c/3524/
>>>
>>> Two questions:
>>> 1. It seems that we were working outside the commit tree by adjusting
>>> 3522 and 3524 - we pulled each one down using _git review -d _,
>>> applied the modifications, and submitted using _git review_
>>> Is it necessary to also "re-commit" the subsequent patches (or does
>>> gerrit this automatically)?
>>> And if so, how?
>>> At the moment Gerrit does not try to rebuild the subsequent patches
>>> (i.e., 3523 and 3525).
>>
>>
>> Gerrit does not automatically do this, it's up to you to rebase the
>> patches so that a review is rebased on the latest version of the one it
is
>> dependent on. You can either do this from the web interface using the
Rebase
>> button (if it will cleanly rebase) or you have to build up a patch
series on
>> your system. This can be done by creating a local branch and pulling down
>> each patch into it using (git review -x ), making any changes
>> needed, committing, and doing git review again. This provides the
dependency
>> information to Gerrit it needs.
>>
>>> 2. How can we withdraw the OPUS patch from the patch set?
>>> https://gerrit.asterisk.org/#/c/3526/
>>
>>
>> You can click "Abandon" from the web interface and it will abandon that
>> specific review.
>>
>> Cheers,
>>
>> --
>> Joshua Colp
>> Digium
Re: [asterisk-dev] Asterisk goes Spatial Conferencing: the STEAK project
Hey, we adjusted the patch set (fftw3 is now a ifdef-ed). Precisely, these two commits have been modified (basically adding HAVE_FFTW3) https://gerrit.asterisk.org/#/c/3522/ https://gerrit.asterisk.org/#/c/3524/ Two questions: 1. It seems that we were working outside the commit tree by adjusting 3522 and 3524 - we pulled each one down using _git review -d _, applied the modifications, and submitted using _git review_ Is it necessary to also "re-commit" the subsequent patches (or does gerrit this automatically)? And if so, how? At the moment Gerrit does not try to rebuild the subsequent patches (i.e., 3523 and 3525). 2. How can we withdraw the OPUS patch from the patch set? https://gerrit.asterisk.org/#/c/3526/ Best, Dennis --- Dennis Guse --- Dennis Guse On Tue, Aug 16, 2016 at 11:41 AM, Dennis Guse <dennis.g...@alumni.tu-berlin.de> wrote: > Hello, > > the cleanup and splitting up into individual patches took some time, > but those are now submitted: Asterisk-26292 [1]. > The issue with this patch set is that it _requires_ libfftw3. > We just figured out, how the dependency system works and will adjust > the fftw-related patch by using appropriate #ifdefs defined by the > xml-based dependency configuration system. > > Two questions came up. > First, how is the submission procedure to Gerrit for _changed_ commits > and resubmission? > We submitted the patch set as branch ASTERISK-26292 to Gerrit > referencing the bug report. > To keep this, we, we would now need either to delete the branch (how?) > or create a new branch (ASTERISK-26292-v2)? > What is the preferred option? > > Second, we would like to package OPUS as a library (ie., codec_opus.so). > Is it sufficient to include all c-files that we included into Asterisk > and compile it as shared library, so it can be added to Asterisk > without linking it during build time? > Are there any known pitfalls or is this straight forward? > And in which folders does Asterisk search for codec modules? > > Best, > Dennis > > [1] https://issues.asterisk.org/jira/browse/ASTERISK-26292 > --- > Dennis Guse > > > On Fri, Aug 5, 2016 at 5:19 PM, Matthew Jordan <mjor...@digium.com> wrote: >> Hi Dennis: >> >> Apologies for not responding quicker to your e-mail - I've been on >> vacation the last week and a half. Some comments inline below. >> >> On Sat, Jul 23, 2016 at 3:50 AM, Dennis Guse >> <dennis.g...@alumni.tu-berlin.de> wrote: >>> Then lets get started. >>> Due to the relatively large number of changes, we will split them up >>> into individual patches: >> >> Individual patches are great! Smaller changes are always easier to review. >> >>> 1) Support for interleaved stereo (mainly softmix and struct channel) >>> 2) Extension of confbridge with binaural synthesis via convolution (if >>> channel supports stereo) >>> >>> For the patches, we will remove the hard dependency to OPUS (although >>> we will stick to using it) and also enable L16 with stereo. >>> >>> Nevertheless, there are still some open questions: >>> >>> 1. Storage and description of HRTFs >>> Impulse responses are at the moment compiled into Asterisk as a header file. >>> This header file is generated using a custom C-program converting a >>> multi-channel wave file into a float-array - hrirs_fabian.wav was >>> taken from the SoundScapeRenderer >>> https://github.com/SoundScapeRenderer/ssr/tree/master/data/impulse_responses/hrirs >>> >>> For positioning a sound source, the HRTFs for the left and for the >>> right ear need to be selected according to the desired angle. >>> This information is at the moment hard-coded as we use a 720-channel >>> wave (interleaved: left, right) to cover 360 degrees completely. >>> >>> Would you prefer to compile the HRTFs into Asterisk (incl. the >>> hard-coded description) or rather make this configurable? >>> For the second option, we would need some support in terms of how to >>> add configuration options. >> >> For an initial implementation, I would recommend hard-coding it. If a >> different data set is needed for different listeners, that would be an >> improvement that someone could make at a latter time. >> >>> 2. Configuration of positioning of conference participants >>> The positioning of individual participants is at the moment hard-coded >>> (compiled via header-file). >>> This is basically an array containing the angles at which participant >>> _n_ is going to be seated. >>> This could also be made configurable via configuration
Re: [asterisk-dev] Asterisk goes Spatial Conferencing: the STEAK project
Hello, the cleanup and splitting up into individual patches took some time, but those are now submitted: Asterisk-26292 [1]. The issue with this patch set is that it _requires_ libfftw3. We just figured out, how the dependency system works and will adjust the fftw-related patch by using appropriate #ifdefs defined by the xml-based dependency configuration system. Two questions came up. First, how is the submission procedure to Gerrit for _changed_ commits and resubmission? We submitted the patch set as branch ASTERISK-26292 to Gerrit referencing the bug report. To keep this, we, we would now need either to delete the branch (how?) or create a new branch (ASTERISK-26292-v2)? What is the preferred option? Second, we would like to package OPUS as a library (ie., codec_opus.so). Is it sufficient to include all c-files that we included into Asterisk and compile it as shared library, so it can be added to Asterisk without linking it during build time? Are there any known pitfalls or is this straight forward? And in which folders does Asterisk search for codec modules? Best, Dennis [1] https://issues.asterisk.org/jira/browse/ASTERISK-26292 --- Dennis Guse On Fri, Aug 5, 2016 at 5:19 PM, Matthew Jordan <mjor...@digium.com> wrote: > Hi Dennis: > > Apologies for not responding quicker to your e-mail - I've been on > vacation the last week and a half. Some comments inline below. > > On Sat, Jul 23, 2016 at 3:50 AM, Dennis Guse > <dennis.g...@alumni.tu-berlin.de> wrote: >> Then lets get started. >> Due to the relatively large number of changes, we will split them up >> into individual patches: > > Individual patches are great! Smaller changes are always easier to review. > >> 1) Support for interleaved stereo (mainly softmix and struct channel) >> 2) Extension of confbridge with binaural synthesis via convolution (if >> channel supports stereo) >> >> For the patches, we will remove the hard dependency to OPUS (although >> we will stick to using it) and also enable L16 with stereo. >> >> Nevertheless, there are still some open questions: >> >> 1. Storage and description of HRTFs >> Impulse responses are at the moment compiled into Asterisk as a header file. >> This header file is generated using a custom C-program converting a >> multi-channel wave file into a float-array - hrirs_fabian.wav was >> taken from the SoundScapeRenderer >> https://github.com/SoundScapeRenderer/ssr/tree/master/data/impulse_responses/hrirs >> >> For positioning a sound source, the HRTFs for the left and for the >> right ear need to be selected according to the desired angle. >> This information is at the moment hard-coded as we use a 720-channel >> wave (interleaved: left, right) to cover 360 degrees completely. >> >> Would you prefer to compile the HRTFs into Asterisk (incl. the >> hard-coded description) or rather make this configurable? >> For the second option, we would need some support in terms of how to >> add configuration options. > > For an initial implementation, I would recommend hard-coding it. If a > different data set is needed for different listeners, that would be an > improvement that someone could make at a latter time. > >> 2. Configuration of positioning of conference participants >> The positioning of individual participants is at the moment hard-coded >> (compiled via header-file). >> This is basically an array containing the angles at which participant >> _n_ is going to be seated. >> This could also be made configurable via configuration file. >> >> Furthermore, all participants of a conference receive the _same_ >> acoustical environment (i.e., participant 1 always sits in front of >> the listener etc.). >> This limits the computational requirements while individual listeners >> cannot configure their desired seating order. >> In fact, the own signal of a participant is subtracted after rendering >> the whole environment before sending the signals back. > > Again, I would punt on making this configurable. If the default > experience is "good enough", effort put into making this configurable > will be wasted. If it is not "good enough", then effort could be > expended into making it configurable. > >> 3. Internal sampling rate of Confbridge >> The binaural synthesis is at the moment conducted at 48kHz. >> This is actually due to our use of OPUS, which always uses 48kHz for >> the decoded signals. >> Is this ok? > > I'm not sure I have a good answer to this. I think it depends on what > the experience is like if a lower sampling rate is used. What happens > if the sampling rate used in the conference is 8kHz or 16kHz? > >
Re: [asterisk-dev] Asterisk goes Spatial Conferencing: the STEAK project
Then lets get started. Due to the relatively large number of changes, we will split them up into individual patches: 1) Support for interleaved stereo (mainly softmix and struct channel) 2) Extension of confbridge with binaural synthesis via convolution (if channel supports stereo) For the patches, we will remove the hard dependency to OPUS (although we will stick to using it) and also enable L16 with stereo. Nevertheless, there are still some open questions: 1. Storage and description of HRTFs Impulse responses are at the moment compiled into Asterisk as a header file. This header file is generated using a custom C-program converting a multi-channel wave file into a float-array - hrirs_fabian.wav was taken from the SoundScapeRenderer https://github.com/SoundScapeRenderer/ssr/tree/master/data/impulse_responses/hrirs For positioning a sound source, the HRTFs for the left and for the right ear need to be selected according to the desired angle. This information is at the moment hard-coded as we use a 720-channel wave (interleaved: left, right) to cover 360 degrees completely. Would you prefer to compile the HRTFs into Asterisk (incl. the hard-coded description) or rather make this configurable? For the second option, we would need some support in terms of how to add configuration options. 2. Configuration of positioning of conference participants The positioning of individual participants is at the moment hard-coded (compiled via header-file). This is basically an array containing the angles at which participant _n_ is going to be seated. This could also be made configurable via configuration file. Furthermore, all participants of a conference receive the _same_ acoustical environment (i.e., participant 1 always sits in front of the listener etc.). This limits the computational requirements while individual listeners cannot configure their desired seating order. In fact, the own signal of a participant is subtracted after rendering the whole environment before sending the signals back. 3. Internal sampling rate of Confbridge The binaural synthesis is at the moment conducted at 48kHz. This is actually due to our use of OPUS, which always uses 48kHz for the decoded signals. Is this ok? 4. Is the dependency to libfftw3 an issue? We look forward to your feedback and will spent some time preparing the patches. --- Dennis Guse On Wed, Jul 20, 2016 at 3:53 PM, Matthew Jordan <mjor...@digium.com> wrote: > > > On Tue, Jul 19, 2016 at 4:59 PM, Matt Fredrickson <cres...@digium.com> > wrote: >> >> On Tue, Jul 19, 2016 at 12:59 PM, Sean Bright <sean.bri...@gmail.com> >> wrote: >> > On 7/19/2016 10:35 AM, Matt Fredrickson wrote: >> >> >> >> Response below. >> >> >> >> On Mon, Jul 18, 2016 at 7:18 AM, Dennis Guse >> >> <dennis.g...@alumni.tu-berlin.de> wrote: >> >>> >> >>> Technical Details (at the moment the modifications are based upon >> >>> 13.6.0): >> >>> * Enabled OPUS (with incoming stereo and outgoing stereo >> >>> [interleaved]) >> >>> * Extended softmix for stereo support (downmixing) >> >>> * Extended the default confbridge (basically added a convolution >> >>> engine) >> > >> > >> > If Opus is a required part of the implementation - and from reading the >> > description of the work being done it appears to be - wouldn't that make >> > this ineligible for inclusion? >> >> My hope is that there is a large amount of core Asterisk work which >> does not explicitly require Opus for it to be merged. I'm hoping that >> our current Opus legal impasses will not go on forever, but until >> things clear up with regards to it, this is the best response I can >> give. >> > > The only thing that we can't include at this time is the codec module > itself, which - if implemented correctly - should be a separate shared > object library. That means that all the rest can be put up for code review, > and anyone who wants to take advantage of the new feature(s) can simply load > an externally available codec_opus. > > So - if you're interested - please do contribute the patches back upstream. > > -- > Matthew Jordan > Digium, Inc. | CTO > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > Check us out at: http://digium.com & http://asterisk.org > > -- > _ > -- 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
[asterisk-dev] Asterisk goes Spatial Conferencing: the STEAK project
Hello, spatial audio for telephone conferencing has been proclaimed as a silver bullet for speech-based telephone conferencing. For research, we needed a _production-ready_ system that provides a centralized conferencing bridge being able to provide binaural synthesized spatial audio (i.e., for a pair of headphones). As none was available (except for proprietary solutions), we chose to get our hands dirty and extended Asterisk. Most important, the modifications were required to be complaint to VoIP standards (no fancy protocol extensions). We succeeded and the modifications are now at a stage that makes them suited to be merged back upstream. Or at least start the discussion on this topic. Technical Details (at the moment the modifications are based upon 13.6.0): * Enabled OPUS (with incoming stereo and outgoing stereo [interleaved]) * Extended softmix for stereo support (downmixing) * Extended the default confbridge (basically added a convolution engine) We chose OPUS (beside being used for WebRTC) as it allows to RTP-channels with stereo (L16 or AMR-WB+ are not really alternatives). Convolution was implemented via libfftw3 and the required HRTFs are at the moment compiled into Asterisk. We would now like to bring the changes upstream as we think this is an important feature (that might set Asterisk apart) and is not too hard to maintain. More detailed information are available at our website: http://steakconferening.de and in the source code (branch >>steak-13.6.0<<): https://github.com/steakconferencing/asterisk In addition, we host WebRTC- based demo (the real system): https://demo.steakconferencing.de Best regards, --- Dennis Guse TU Berlin dennis.g...@alumni.tu-berlin.de -- _ -- 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
Re: [asterisk-dev] Original 48kHz versions of the asterisk prompts and addons?
+1 Kind regards Dennis Guse Quality and Usability Lab Telekom Innovation Laboratories TU Berlin Ernst-Reuter-Platz 7 D-10587 Berlin, Germany Tel: +49 30 8353 58874 Fax: +49 30 8353 58409 E-mail: dennis.g...@telekom.de Web: www.qu.tlabs.tu-berlin.de On Fri, Jul 18, 2014 at 8:54 PM, Stephen Davies stephen.l.dav...@gmail.com wrote: Hi, I'm on a mission to build a little demo system that blows past everyone's perceptions of what a VOIP system sounds like. For that system I want to make a set of standard and addon prompts in .sln48. But I don't just want to upsample the existing sln16 since that is only 16kHz sample rate. Is it possible to obtain the original 48kHz recordings; I'll contribute back the sln48 files. Thanks, Steve Davies -- _ -- 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
Re: [asterisk-dev] Question about interface to sound processing library
Hi Rolf, there is a nice option available in Asterisk. Asterisk supports JACK [1], which is basically a virtual local audio routing system that allows to send audio data from one application on the same PC running as the same user. Using a audio processing like Puredata [2] realtime audio processing / manipulation is quite easy. Basically Puredata gives you a graphical programming interface for realtime processing where you can create a small UI to apply or not-apply some degradations. At the moment I have configuration that can to bandpass filtering, white+pinknoise and simulates packet-loss by adding 20ms empty frames (so no PLC). In addition delay is quite easy to add here. With the upcoming release of Asterisk 13, the JACK-interface is extended to support more than 8Khz. Best regards, Dennis Guse PS: To listen in such a call ChanSpy is quite useful. [1] http://jackaudio.org/ [2] http://puredata.info/ Kind regards Dennis Guse Quality and Usability Lab Telekom Innovation Laboratories TU Berlin Ernst-Reuter-Platz 7 D-10587 Berlin, Germany Tel: +49 30 8353 58874 Fax: +49 30 8353 58409 E-mail: dennis.g...@telekom.de Web: www.qu.tlabs.tu-berlin.de On Fri, Jul 18, 2014 at 11:44 AM, Rolf-Werner Eilert eilert-sprac...@t-online.de wrote: Hi folks, I hope I'm right here in this list. Tried to ask this as a general question in forum General first, but there was only a vague answer. Here I expect to find the guys who make the core functions of Asterisk, so I ask my question again. To describe the reason for my question: We are running a school for foreign languages training students for office communication. This includes telephoning in foreign languages. Up to now, we provide a simple one-box unit with a wireless phone for the person that leaves the classroom and a loudspeaker for the class to listen. There was the idea of building a telephone system that allows to simulate telephone calls to far destinations and to cellphones offering kind of simulating distortions typical to such calls (delays, cracks, echos, or scenarios like cellphone at a busy street café :D ). With Asterisk, my phantasy goes to offer the trainer an easy interface (which I could program myself) to choose line quality, scenarios etc. and to have a telephone in every room to call from and to be called. One might even simulate international numbers... My idea is to use some interface to the voice processing modules of Asterisk to be able to let them remodulate the sound stream (e. g. decreasing the sampling rate for 200 ms or so, then going back to normal to simulate typical GSM distortions like organ-like noises) or to mix in pre-recorded noises like from a street etc. Has anyone here ever seen something like this with Asterisk, or are there any plugins/modules you would consider worth taking a look at? I am new to Asterisk, so I don't know what to look for. Let me add this: There is a Linux server running 24/7 and a terminal for the teachers in every classroom. Thanks for reading up to here - and thanks a lot for all your ideas! Rolf -- _ -- 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
Re: [asterisk-dev] [Code Review] 3744: Change the description of codec ADPCM to Dialogic ADCPM.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3744/ --- (Updated July 15, 2014, 6:29 p.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers. Changes --- Committed in revision 418738 Repository: Asterisk Description --- Changes the description of codec ADPCM to Dialogic ADCPM. I know it's nitpicking, but it took me almost 2 hours until I figured out what is meant exactly by the codec named ADPCM by Asterisk as ADPCM is a method applied a several codecs Also changed (non-working) link to the documentation to wikipedia. Diffs - /trunk/main/format.c 418364 /trunk/codecs/codec_adpcm.c 418364 Diff: https://reviewboard.asterisk.org/r/3744/diff/ Testing --- Still compiles. Thanks, Dennis Guse -- _ -- 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
[asterisk-dev] [Code Review] 3744: Change the description of codec ADPCM to Dialogic ADCPM.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3744/ --- Review request for Asterisk Developers. Repository: Asterisk Description --- Changes the description of codec ADPCM to Dialogic ADCPM. I know it's nitpicking, but it took me almost 2 hours until I figured out what is meant exactly by the codec named ADPCM by Asterisk as ADPCM is a method applied a several codecs Also changed (non-working) link to the documentation to wikipedia. Diffs - /trunk/main/format.c 418364 /trunk/codecs/codec_adpcm.c 418364 Diff: https://reviewboard.asterisk.org/r/3744/diff/ Testing --- Still compiles. Thanks, Dennis Guse -- _ -- 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
Re: [asterisk-dev] [Code Review] 3618: App_jack: more than 8Khz
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3618/ --- (Updated June 26, 2014, 7:43 a.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers. Changes --- Committed in revision 417360 Bugs: ASTERISK-20696 and ASTERISK-23836 https://issues.asterisk.org/jira/browse/ASTERISK-20696 https://issues.asterisk.org/jira/browse/ASTERISK-23836 Repository: Asterisk Description --- Target: app_jack.c Enables the jack-audiohook to cope with dynamic sampling rates from and to Asterisk. Information from channel is taken to derive the channel's sampling rate, suiting SLINxx format and frame-datalen. Limitations: * Required information is taken from channel during initialization as audiohook does not provide this information then. Audiohook.internal_sampl_rate(...) is set later, but no callback is available to inform app_jack. * Frame.datalen is computed using rate / 50 assuming a ptime of 20ms. There is no internal API available to determine datalen for a SLINxx. * Ringbuffer size is now dynamic depending frame.datalen (see above) and the number of frames, which are in RINGBUFFER_FRAME_CAPACITY, that need to fit. Diffs - /trunk/apps/app_jack.c 415578 Diff: https://reviewboard.asterisk.org/r/3618/diff/ Testing --- Checked with jackd and puredata using G.711 and G.722 on Ubuntu 14.0.4 64bit using Linphone and Ekiga. Thanks, Dennis Guse -- _ -- 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
Re: [asterisk-dev] [Code Review] 3629: pbx_lua: Remove the problematic and unnecessary AST_MODFLAG_GLOBAL_SYMBOLS from pbx_lua.c
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3629/#review12186 --- Ship it! Thanks George your patch solves the issue. Extension.lua is loaded as expected on startup. Also combining extensions.conf and extensions.lua is working as expected on startup. Patched 11.7.0 on Ubuntu 14.04. - Dennis Guse On June 18, 2014, 11:27 p.m., George Joseph wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3629/ --- (Updated June 18, 2014, 11:27 p.m.) Review request for Asterisk Developers. Bugs: ASTERISK-23818 https://issues.asterisk.org/jira/browse/ASTERISK-23818 Repository: Asterisk Description --- AST_MODFLAG_GLOBAL_SYMBOLS was causing the module to be incorrectly loaded before pbx_config. pbx_config was therefore blowing away contexts that were created by pbx_lua. With AST_MODFLAG_DEFAULT the load order is now correct and contexs are being properly merged. AST_MODFLAG_GLOBAL_SYMBOLS was not needed anyway since no other modules needed its global symbols that early. This patch needs to be merged all the way though trunk. Diffs - branches/1.8/pbx/pbx_lua.c 416661 Diff: https://reviewboard.asterisk.org/r/3629/diff/ Testing --- Checked that contexts created by both pbx_config and pbx_lua were properly merged instead of pbx_config overwriting them. Thanks, George Joseph -- _ -- 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
Re: [asterisk-dev] [Code Review] 3618: App_jack: more than 8Khz
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3618/ --- (Updated June 18, 2014, 8:16 a.m.) Review request for Asterisk Developers. Changes --- Change LOG_WARNING back to LOG_NOTICE Bugs: ASTERISK-20696 and ASTERISK-23836 https://issues.asterisk.org/jira/browse/ASTERISK-20696 https://issues.asterisk.org/jira/browse/ASTERISK-23836 Repository: Asterisk Description --- Target: app_jack.c Enables the jack-audiohook to cope with dynamic sampling rates from and to Asterisk. Information from channel is taken to derive the channel's sampling rate, suiting SLINxx format and frame-datalen. Limitations: * Required information is taken from channel during initialization as audiohook does not provide this information then. Audiohook.internal_sampl_rate(...) is set later, but no callback is available to inform app_jack. * Frame.datalen is computed using rate / 50 assuming a ptime of 20ms. There is no internal API available to determine datalen for a SLINxx. * Ringbuffer size is a DEFINE and thus must be quite big to be able to cope with 16Khz+ Diffs (updated) - /trunk/apps/app_jack.c 415578 Diff: https://reviewboard.asterisk.org/r/3618/diff/ Testing --- Checked with jackd and puredata using G.711 and G.722 on Ubuntu 14.0.4 64bit using Linphone and Ekiga. Thanks, Dennis Guse -- _ -- 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
Re: [asterisk-dev] [Code Review] 3618: App_jack: more than 8Khz
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3618/ --- (Updated June 18, 2014, 10:23 a.m.) Review request for Asterisk Developers. Changes --- Missed to update description of the patch to include dynamic ringbuffer size. Bugs: ASTERISK-20696 and ASTERISK-23836 https://issues.asterisk.org/jira/browse/ASTERISK-20696 https://issues.asterisk.org/jira/browse/ASTERISK-23836 Repository: Asterisk Description (updated) --- Target: app_jack.c Enables the jack-audiohook to cope with dynamic sampling rates from and to Asterisk. Information from channel is taken to derive the channel's sampling rate, suiting SLINxx format and frame-datalen. Limitations: * Required information is taken from channel during initialization as audiohook does not provide this information then. Audiohook.internal_sampl_rate(...) is set later, but no callback is available to inform app_jack. * Frame.datalen is computed using rate / 50 assuming a ptime of 20ms. There is no internal API available to determine datalen for a SLINxx. * Ringbuffer size is now dynamic depending frame.datalen (see above) and the number of frames, which are in RINGBUFFER_FRAME_CAPACITY, that need to fit. Diffs - /trunk/apps/app_jack.c 415578 Diff: https://reviewboard.asterisk.org/r/3618/diff/ Testing --- Checked with jackd and puredata using G.711 and G.722 on Ubuntu 14.0.4 64bit using Linphone and Ekiga. Thanks, Dennis Guse -- _ -- 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
Re: [asterisk-dev] [Code Review] 3618: App_jack: more than 8Khz
On June 13, 2014, 6:28 p.m., Mark Michelson wrote: /trunk/apps/app_jack.c, line 411 https://reviewboard.asterisk.org/r/3618/diff/1/?file=59647#file59647line411 You brought this up as a concern in your description, but considering that app_jack had been using a constant 160 previously, you are not introducing any new incorrect behavior by dividing the rate by 50. I say it's fine to go with that, at least for the time being. I am ok with that - it's just not very beautiful. On June 13, 2014, 6:28 p.m., Mark Michelson wrote: /trunk/apps/app_jack.c, line 190 https://reviewboard.asterisk.org/r/3618/diff/1/?file=59647#file59647line190 There is no reason for this to be an error message. In my case I need to know immediately, if something with the Asterisk-Jack connection is wrong... I would at least provide it as warning. On June 13, 2014, 6:28 p.m., Mark Michelson wrote: /trunk/apps/app_jack.c, line 64 https://reviewboard.asterisk.org/r/3618/diff/1/?file=59647#file59647line64 I saw your comment about requiring a large ringbuffer for dealing with larger sampling rates, but I don't think a 128K allocation is the right way to go here. I think instead, you can start by using a smaller allocation. When you want to write to the ringbuffer, use the jack_ringbuffer_write_space() function to determine if you have room to write the bytes. If you do not, you can free the current ringbuffer and create a new larger one to take its place. This way, the #define value acts as the basis for ringbuffer allocations but does not have to be so large as to dictate a maximum size. I'm not sure if this would result in lost data, though, so feel free to let me know if this idea would not work. Thanks for your review. You are right defining the ringbuffer size in that way is awful. I thought about your proposed solution with re-allocation new ringbuffers. It might work, but is probably very tricky to implement as jack and asterisk are sharing them. And I have no clue, if it will work at all since I have no experience with Jack. I would propose another solution: define number of frames the ringbuffer needs be able to hold. During initialization, when the frame_datalen is available, just use frame_datalen * frame_count. In that way app_jack will be able to cope with higher sampling rates without always allocating such a large buffer. What do you think? - Dennis --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3618/#review12146 --- On June 14, 2014, 10:12 p.m., Dennis Guse wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3618/ --- (Updated June 14, 2014, 10:12 p.m.) Review request for Asterisk Developers. Bugs: ASTERISK-20696 and ASTERISK-23836 https://issues.asterisk.org/jira/browse/ASTERISK-20696 https://issues.asterisk.org/jira/browse/ASTERISK-23836 Repository: Asterisk Description --- Target: app_jack.c Enables the jack-audiohook to cope with dynamic sampling rates from and to Asterisk. Information from channel is taken to derive the channel's sampling rate, suiting SLINxx format and frame-datalen. Limitations: * Required information is taken from channel during initialization as audiohook does not provide this information then. Audiohook.internal_sampl_rate(...) is set later, but no callback is available to inform app_jack. * Frame.datalen is computed using rate / 50 assuming a ptime of 20ms. There is no internal API available to determine datalen for a SLINxx. * Ringbuffer size is a DEFINE and thus must be quite big to be able to cope with 16Khz+ Diffs - /trunk/apps/app_jack.c 415578 Diff: https://reviewboard.asterisk.org/r/3618/diff/ Testing --- Checked with jackd and puredata using G.711 and G.722 on Ubuntu 14.0.4 64bit using Linphone and Ekiga. Thanks, Dennis Guse -- _ -- 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
Re: [asterisk-dev] [Code Review] 3618: App_jack: more than 8Khz
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3618/ --- (Updated June 14, 2014, 10:12 p.m.) Review request for Asterisk Developers. Changes --- Adopted dynamic ringbuffer size depending on the sampling rate. Fixed formatting as suggested by opticron. Bugs: ASTERISK-20696 and ASTERISK-23836 https://issues.asterisk.org/jira/browse/ASTERISK-20696 https://issues.asterisk.org/jira/browse/ASTERISK-23836 Repository: Asterisk Description --- Target: app_jack.c Enables the jack-audiohook to cope with dynamic sampling rates from and to Asterisk. Information from channel is taken to derive the channel's sampling rate, suiting SLINxx format and frame-datalen. Limitations: * Required information is taken from channel during initialization as audiohook does not provide this information then. Audiohook.internal_sampl_rate(...) is set later, but no callback is available to inform app_jack. * Frame.datalen is computed using rate / 50 assuming a ptime of 20ms. There is no internal API available to determine datalen for a SLINxx. * Ringbuffer size is a DEFINE and thus must be quite big to be able to cope with 16Khz+ Diffs (updated) - /trunk/apps/app_jack.c 415578 Diff: https://reviewboard.asterisk.org/r/3618/diff/ Testing --- Checked with jackd and puredata using G.711 and G.722 on Ubuntu 14.0.4 64bit using Linphone and Ekiga. Thanks, Dennis Guse -- _ -- 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
[asterisk-dev] [Code Review] 3618: App_jack: more than 8Khz
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3618/ --- Review request for Asterisk Developers. Bugs: ASTERISK-20696 and ASTERISK-23836 https://issues.asterisk.org/jira/browse/ASTERISK-20696 https://issues.asterisk.org/jira/browse/ASTERISK-23836 Repository: Asterisk Description --- Target: app_jack.c Enables the jack-audiohook to cope with dynamic sampling rates from and to Asterisk. Information from channel is taken to derive the channel's sampling rate, suiting SLINxx format and frame-datalen. Limitations: * Required information is taken from channel during initialization as audiohook does not provide this information then. Audiohook.internal_sampl_rate(...) is set later, but no callback is available to inform app_jack. * Frame.datalen is computed using rate / 50 assuming a ptime of 20ms. There is no internal API available to determine datalen for a SLINxx. * Ringbuffer size is a DEFINE and thus must be quite big to be able to cope with 16Khz+ Diffs - /trunk/channels/chan_sip.c 415578 /trunk/apps/app_jack.c 415578 Diff: https://reviewboard.asterisk.org/r/3618/diff/ Testing --- Checked with jackd and puredata using G.711 and G.722 on Ubuntu 14.0.4 64bit using Linphone and Ekiga. Thanks, Dennis Guse -- _ -- 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
Re: [asterisk-dev] [Code Review] 3618: App_jack: more than 8Khz
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3618/ --- (Updated June 13, 2014, 12:19 p.m.) Review request for Asterisk Developers. Bugs: ASTERISK-20696 and ASTERISK-23836 https://issues.asterisk.org/jira/browse/ASTERISK-20696 https://issues.asterisk.org/jira/browse/ASTERISK-23836 Repository: Asterisk Description --- Target: app_jack.c Enables the jack-audiohook to cope with dynamic sampling rates from and to Asterisk. Information from channel is taken to derive the channel's sampling rate, suiting SLINxx format and frame-datalen. Limitations: * Required information is taken from channel during initialization as audiohook does not provide this information then. Audiohook.internal_sampl_rate(...) is set later, but no callback is available to inform app_jack. * Frame.datalen is computed using rate / 50 assuming a ptime of 20ms. There is no internal API available to determine datalen for a SLINxx. * Ringbuffer size is a DEFINE and thus must be quite big to be able to cope with 16Khz+ Diffs - /trunk/channels/chan_sip.c 415578 /trunk/apps/app_jack.c 415578 Diff: https://reviewboard.asterisk.org/r/3618/diff/ Testing --- Checked with jackd and puredata using G.711 and G.722 on Ubuntu 14.0.4 64bit using Linphone and Ekiga. Thanks, Dennis Guse -- _ -- 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
Re: [asterisk-dev] [Code Review] 3618: App_jack: more than 8Khz
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3618/ --- (Updated June 13, 2014, 12:19 p.m.) Review request for Asterisk Developers. Bugs: ASTERISK-20696 and ASTERISK-23836 https://issues.asterisk.org/jira/browse/ASTERISK-20696 https://issues.asterisk.org/jira/browse/ASTERISK-23836 Repository: Asterisk Description --- Target: app_jack.c Enables the jack-audiohook to cope with dynamic sampling rates from and to Asterisk. Information from channel is taken to derive the channel's sampling rate, suiting SLINxx format and frame-datalen. Limitations: * Required information is taken from channel during initialization as audiohook does not provide this information then. Audiohook.internal_sampl_rate(...) is set later, but no callback is available to inform app_jack. * Frame.datalen is computed using rate / 50 assuming a ptime of 20ms. There is no internal API available to determine datalen for a SLINxx. * Ringbuffer size is a DEFINE and thus must be quite big to be able to cope with 16Khz+ Diffs - /trunk/channels/chan_sip.c 415578 /trunk/apps/app_jack.c 415578 Diff: https://reviewboard.asterisk.org/r/3618/diff/ Testing --- Checked with jackd and puredata using G.711 and G.722 on Ubuntu 14.0.4 64bit using Linphone and Ekiga. Thanks, Dennis Guse -- _ -- 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
Re: [asterisk-dev] dial url with sip
If you are in control of the SIP-Phone, you could pass additional information via SIPAddHeader in your dialplan. On Jun 2, 2014 10:33 AM, James Cloos cl...@jhcloos.com wrote: Looking at app_dial.c and chan_sip.c, I get the impression that the url in a dial string cannot get sent as part of the sip INVITE, yes? (I base that on sip_sendhtml().) Am I reading chan_sip correctly? Will I need to change sip_sendhtml() to send the url as part of the INVITE? A test call shows no url is sent. (I also see that in 12 and trunk chan_pjsip does not have a send_html entry in its chan_pjsip_tech structure, and is therefore less capable.) My understanding is that some sip phones will fetch and display a url when INVITEd, and I'd like to use that to show the callee more data about the incoming call, such as the remote sip proxy/endpoint, the details about the INVITEd number, et cetera. In particular, I want to do this will dials generated as a result of followme, queuesand the like. That will only work if the url is part of the INVITE from ast to the phone. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 0x997A9F17ED7DAEA6 -- _ -- 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
[asterisk-dev] Module pbx_lua not loading extensions.lua on startup
Hi,
using the pbx_lua module for almost everything we have found a little
annoying bug. On Asterisk startup the module is loaded - however the
configuration (extensions.lua) is not loaded and therefore the lua-defined
dialplan is not available. By applying module reload pbx_lua the dialplan
is loaded as expected (lua dialplan is correct).
--
How to reproduce the problem.
Details: Asterisk 11.7 running on Ubuntu 14.04
- Module is loaded on start
# asterisk -fvvv
..SNIP
[1;30m-- [0mRegistered extension context 'default'; registrar: pbx_lua
[1;30m-- [0mIncluding switch 'Lua/' in context 'default'
[1;30m-- [0mRegistered extension context 'parkedcalls'; registrar:
features
[1;30m-- [0mmerging incls/swits/igpats from old(parkedcalls) to
new(parkedcalls) context, registrar = pbx_lua
[1;30m-- [0mAdded extension '700' priority 1 to parkedcalls
[1;30m-- [0mTime to scan old dialplan and merge leftovers back into the
new: 0.43 sec
[1;30m-- [0mTime to restore hints and swap in new dialplan: 0.03 sec
[1;30m-- [0mTime to delete the old dialplan: 0.05 sec
[1;30m-- [0mTotal time merge_contexts_delete: 0.51 sec
[1;30m [0mpbx_lua.so = ( [0;33mLua PBX Switch [0m)
..SNIP
- Module is really loaded and thus fails:
#asterisk -rc module load pbx_lua
- Let the started Asterisk reload pbx_lua
# sudo asterisk -rxv
module reload pbx_lua.so
-- Reloading module 'pbx_lua.so' (Lua PBX Switch)
-- Registered extension context 'default'; registrar: pbx_lua
-- Including switch 'Lua/' in context 'default'
-- Registered extension context 'parkedcalls'; registrar: features
-- merging incls/swits/igpats from old(parkedcalls) to new(parkedcalls)
context, registrar = pbx_lua
-- Added extension '700' priority 1 to parkedcalls
-- Registered extension context 'ael-builtin-h-bubble'; registrar:
pbx_ael
-- merging incls/swits/igpats from old(ael-builtin-h-bubble) to
new(ael-builtin-h-bubble) context, registrar = pbx_lua
-- Added extension 'h' priority 9996 to ael-builtin-h-bubble
-- Added extension 'h' priority 9995 to ael-builtin-h-bubble
-- Added extension 'h' priority 9994 to ael-builtin-h-bubble
-- Added extension 'h' priority 9993 to ael-builtin-h-bubble
-- Added extension 'h' priority 9992 to ael-builtin-h-bubble
-- Added extension 'h' priority 9991 to ael-builtin-h-bubble
-- Added extension 'h' priority 1 to ael-builtin-h-bubble
-- Registered extension context 'ael-default'; registrar: pbx_ael
-- merging incls/swits/igpats from old(ael-default) to new(ael-default)
context, registrar = pbx_lua
-- Including context 'ael-demo' in context 'ael-default'
-- Registered extension context 'ael-demo'; registrar: pbx_ael
-- merging incls/swits/igpats from old(ael-demo) to new(ael-demo)
context, registrar = pbx_lua
...SNIP
Investigation:
I took a look into pbx/pbx_lua.c and actually load identical to reload +
registering the module at Asterisk. Looks neat.
static int reload(void)
{
return load_or_reload_lua_stuff();
}
static int load_module(void)
{
int res;
if ((res = load_or_reload_lua_stuff()))
return res;
if (ast_register_switch(lua_switch)) {
ast_log(LOG_ERROR, Unable to register LUA PBX switch\n);
return AST_MODULE_LOAD_DECLINE;
}
return AST_MODULE_LOAD_SUCCESS;
}
Could it be that the pbx_lua is loaded to early and the dialplan
overwritten by some other dialplan-module that is later loaded?
PS: Work done together with Frank Haase.
Kind regards
Dennis Guse
Quality and Usability Lab
Telekom Innovation Laboratories
TU Berlin
Ernst-Reuter-Platz 7
D-10587 Berlin, Germany
Tel: +49 30 8353 58874
Fax: +49 30 8353 58409
E-mail: dennis.g...@telekom.de
Web: www.qu.tlabs.tu-berlin.de
--
_
-- 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
Re: [asterisk-dev] SIP Presence using SIP SIMPLE: How?
Hi Olle, adding Kamailio is one option, but I must admit that I don't want to complicate the existing setup any more and Asterisk is working quite well. Actually I can live without the feature - it would just make things more nicer ;) About adding this feature - I can only offer some my work time (and one of my co-workers) to implement this feature. We could start this probably in June. But as I am not an experienced Asterisk-Developer it would be great, if you (or somebody else) could help me in finding the best starting point... Cheers, Dennis Kind regards Dennis Guse Quality and Usability Lab Telekom Innovation Laboratories TU Berlin Ernst-Reuter-Platz 7 D-10587 Berlin, Germany Tel: +49 30 8353 58874 Fax: +49 30 8353 58409 E-mail: dennis.g...@telekom.de Web: www.qu.tlabs.tu-berlin.de On Mon, Apr 28, 2014 at 10:26 AM, Olle E. Johansson o...@edvina.net wrote: On 28 Apr 2014, at 10:15, Dennis Guse dennis.g...@qu.tu-berlin.de wrote: Thanks Olle for the explanation. Is such a feature planned, so that the presence status of a hinted extensions can be updated via SIP? Is anybody interested in such a feature? I have an old branch that supports PUBLISH for this. If there's funding, I can plan on working on this later this year. PS: Switching to Kamailio is not an option as there are some required features in Asterisk that I would really miss. You don't have to switch to Kamailio, you have to ADD kamailio to your network and keep Asterisk. /O --- Dennis Guse Kind regards Dennis Guse Quality and Usability Lab Telekom Innovation Laboratories TU Berlin Ernst-Reuter-Platz 7 D-10587 Berlin, Germany Tel: +49 30 8353 58874 Fax: +49 30 8353 58409 E-mail: dennis.g...@telekom.de Web: www.qu.tlabs.tu-berlin.de On Sun, Apr 27, 2014 at 8:50 PM, Olle E. Johansson o...@edvina.net wrote: On 27 Apr 2014, at 20:01, Dennis Guse dennis.g...@qu.tu-berlin.de wrote: Hallo, I have successfully activated hints and those are working (NOTIFY is send by Asterisk on (un)-register to the subscribed clients). And the presence state can be set using CustomPresence, by calling the dialplan function PRESENCE_STATE [1]. However, I have some trouble, if clients are setting there presence state the sip way [2], but using Asterisk as proxy (no P2P presence). The clients do not send there presence updates to Asterisk, because is not subscribing on them (there is no SUBSCRIBE-message from Asterisk to a hinted client). How do I get Asterisk to subscribe on the clients, so Asterisk can the presence update and can relay it? Or is this not implemented? It is not implemented and Asterisk is not a proxy. Use Kamailio if you want full presence. /O Software: Asterisk is 11.7 on an Ubuntu 14.04 The clients we use are based upon PJSIP 2.1. [1] https://wiki.asterisk.org/wiki/display/AST/Presence+State [2] http://www.ietf.org/rfc/rfc3856.txt --- Dennis Guse -- _ -- 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 -- _ -- 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 -- _ -- 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
Re: [asterisk-dev] SIP Presence using SIP SIMPLE: How?
Thanks Olle for the explanation. Is such a feature planned, so that the presence status of a hinted extensions can be updated via SIP? Is anybody interested in such a feature? PS: Switching to Kamailio is not an option as there are some required features in Asterisk that I would really miss. --- Dennis Guse Kind regards Dennis Guse Quality and Usability Lab Telekom Innovation Laboratories TU Berlin Ernst-Reuter-Platz 7 D-10587 Berlin, Germany Tel: +49 30 8353 58874 Fax: +49 30 8353 58409 E-mail: dennis.g...@telekom.de Web: www.qu.tlabs.tu-berlin.de On Sun, Apr 27, 2014 at 8:50 PM, Olle E. Johansson o...@edvina.net wrote: On 27 Apr 2014, at 20:01, Dennis Guse dennis.g...@qu.tu-berlin.de wrote: Hallo, I have successfully activated hints and those are working (NOTIFY is send by Asterisk on (un)-register to the subscribed clients). And the presence state can be set using CustomPresence, by calling the dialplan function PRESENCE_STATE [1]. However, I have some trouble, if clients are setting there presence state the sip way [2], but using Asterisk as proxy (no P2P presence). The clients do not send there presence updates to Asterisk, because is not subscribing on them (there is no SUBSCRIBE-message from Asterisk to a hinted client). How do I get Asterisk to subscribe on the clients, so Asterisk can the presence update and can relay it? Or is this not implemented? It is not implemented and Asterisk is not a proxy. Use Kamailio if you want full presence. /O Software: Asterisk is 11.7 on an Ubuntu 14.04 The clients we use are based upon PJSIP 2.1. [1] https://wiki.asterisk.org/wiki/display/AST/Presence+State [2] http://www.ietf.org/rfc/rfc3856.txt --- Dennis Guse -- _ -- 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 -- _ -- 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
