similar to: Initial implementation of ch.mapping 253/3

Thanks for looking over this, Mark! I'm travelling this week but when I'm back I'll address all of your concerns and send,out another patch. :) On Jun 7, 2017 9:56 AM, "Mark Harris" <mark.hsj at gmail.com> wrote: > On Tue, May 30, 2017 at 3:13 PM, Drew Allen <bitllama at google.com> wrote: > > Hello all, > > > > Attached is the initial

apologies, this is the correct patch I meant to send: On Mon, Jun 12, 2017 at 9:19 AM Drew Allen <bitllama at google.com> wrote: > Thanks again Mark for taking a look and pointing out the issues that > previous patch had. I've addressed your concerns. The tests should no > longer give any warnings or errors regarding usage or c89. I've ensured the > memory issues have

Hi Mark, Attached are corrections based on your comments. I will extend these to the patch I recently submitted to fix memory issues once that is resolved as well. Cheers, Drew On Sat, Nov 18, 2017 at 5:48 PM Mark Harris <mark.hsj at gmail.com> wrote: > Hi Drew, > > Some additional comments on your mapping family 253 changes: > > 1) mapping_matrix_get_data: The computed

On Tue, May 30, 2017 at 3:13 PM, Drew Allen <bitllama at google.com> wrote: > Hello all, > > Attached is the initial proposed implementation for ch.mapping 253/3, based > on the IETF proposal: > https://tools.ietf.org/html/draft-ietf-codec-ambisonics-03 > > A brief overview of the patch, as it is slightly lengthy: > After discussion with Jean-Marc, we determined that

Thanks again Mark for taking a look and pointing out the issues that previous patch had. I've addressed your concerns. The tests should no longer give any warnings or errors regarding usage or c89. I've ensured the memory issues have also been addressed. Please let me know any and all other concerns as well. :) Attached is the new proposed patch. Cheers, Drew On Wed, Jun 7, 2017 at

Hi Drew, Thanks for the fixes. See below for a couple of remaining issues. On Mon, Nov 20, 2017 at 5:57 PM, Drew Allen <bitllama at google.com> wrote: > On Sat, Nov 18, 2017 at 5:48 PM Mark Harris <mark.hsj at gmail.com> wrote: >> >> 5) opus_projection_decoder_init: demixing_matrix_size_in_bytes >> doesn't include the MappingMatrix struct or alignment but

thanks for all your feedback. here's the revised patch: On Wed, Oct 11, 2017 at 2:20 PM Timothy B. Terriberry <tterribe at xiph.org> wrote: > Jean-Marc Valin wrote: > > I think you'll want something like: > > (opus_int16)((unsigned)demixing_matrix[2*i+1] << 8) > > (though you might want to check it too) > > FWIW, we use the construct > int s =

Hi Jean-Marc, Thanks so much for your review. Attached are my comments and an updated patch. On Mon, Oct 30, 2017 at 5:48 PM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Hi Drew, > > I've had some time to dig more deeply into your patch. Here's some more > in-depth comments: > > 1) I note that your OpusMSEncoder struct in private.h adds a > subframe_mem[]

Hi Drew, I think the libopusenc patch is better, but there's still a few issues left: 1) The static MAX_PACKET_BUFFER_SIZE value is still problematic because if you link libopusenc with a new version of libopus that supports higher order projection or just more projection channels for order 3, then you will overflow the buffer. I think what you'd want is a _ope_opus_header_get_size() call

Here's another one. On Thu, Nov 2, 2017 at 9:54 AM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Hi Drew, > > We're getting there... Some minor comments: > > 1) The public header file should not have an > #ifdef ENABLE_EXPERIMENTAL_AMBISONICS > since that would require the user code to define it. > > Done > 2) Why do you have #define

Sure, ill send that asap On Wed, Nov 8, 2017 at 4:44 PM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Hi Drew, > > Your ambisonics patch is already merged. Can you send a patch that > applies to master? > > Jean-Marc > > On 11/08/2017 07:05 PM, Drew Allen wrote: > > Hey Jean-Marc, > > > > I found a bug regarding exporting the matrix that

On Mon, Jul 9, 2018 at 9:39 PM, Joshua Bowman <silverbacknet at gmail.com> wrote: > Most projects don't even bother to include *.vcxproj.filters, relying on > cmake or default behavior, but since it'd be referenced in there, sure, I > think so. Want an updated patch? Sure, preferably in "git format-patch" format. - Mark

Hi Drew, Here's some comments on your patch (in no particular order): 1) I see that it's adding an #include of stdarg.h to opus_multistream.h Is that left over from the previous version? 2) Someone on this list might know better than I do on that one, but for the new _ctl_va_list() calls, I believe the convention is for va_start() and va_end() to appear in the caller rather than in in

Hi Drew, On 10/10/17 02:29 PM, Drew Allen wrote: > 2) Someone on this list might know better than I do on that one, but for > the new _ctl_va_list() calls, I believe the convention is for va_start() > and va_end() to appear in the caller rather than in in the va_list() > function itself. > > *My understanding is that it's impossible to pass ellipsis to another >

Hello, Attached is a patch to resolve a memory issue using the Projection API when compiling using a psuedo-stack / limited memory. Please let me any ?s you might have. Cheers, Drew -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/20171120/84e36e1b/attachment-0001.html> -------------- next part --------------

Friendly ping for supporting ambisonics in opus-tools & opusfile Please LMK any ?s you might have. Cheers, Drew -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/20180410/fd4a3709/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name:

Hi Jean-Marc, Here's my responses: 1) I didn't change how multistream_decode_float works in the argument list... I noticed it changes it's arguments depending on whether FIXED_POINT is used. I copied this style for the projection API as well. If this isn't desired, we should make those changes separately. 2) See above. 3) I only zero out initially. For the matrix_multiply_out

Hey Jean-Marc, Thanks again! To your first point, I was only trying to copy how _multistream_'s c files function in this way, possibly that's worth refactoring as well (as a separate patch). I made the other changes you suggested. Cheers, Drew On Thu, Nov 23, 2017 at 9:02 AM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > On 11/22/2017 06:23 PM, Drew Allen wrote: >

Hello all, Attached is an up-to-date patch for supporting channel mapping 253. Please advise and Thank you for your time. Cheers, Drew -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/20170919/055d9034/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name:

got it. actually that patch i sent you has something wrong with the mapping_matrix_multiply_short_out... let me fix that and will send you another patch soon. Cheers, Drew On Thu, Nov 23, 2017 at 10:34 AM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > On 11/23/2017 01:28 PM, Drew Allen wrote: > > To your first point, I was only trying to copy how _multistream_'s c > >