[asterisk-dev] Asterisk goes Spatial Conferencing: the STEAK project

[Dennis Guse]

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 <leif at 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 <path
to
> 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 <jcolp at 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 XXXX_,
>>> 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 <review>), 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, 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
>
>
>
>
> --
> Leif Madsen
> http://www.oreilly.com/catalog/asterisk
> http://www.leifmadsen.com
>
> --
> _____________________________________________________________________
> -- 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20161025/9c6e111a/attachment.html>