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 <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 <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 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
-- _____________________________________________________________________ -- 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