search for: jmvalin

I think you just attached the wrong (previous) version of the patch. Jean-Marc On 11/28/2017 12:24 PM, Drew Allen wrote: > Done! > > On Tue, Nov 28, 2017 at 12:12 AM Jean-Marc Valin <jmvalin at jmvalin.ca > <mailto:jmvalin at jmvalin.ca>> wrote: > > I only had a quick look, but your patch looks good except for the: >   output[output_rows * i] = (1/(32768.f*128.f))*tmp; > > For floating point, you shouldn't do the >>7 either. Just remov...

...t to commit the changes before creating that last > patch. Yes, some in-house control would be good, I agree. I'll ensure my > future patches are verified internally before submitting anything new. > > Cheers, > Drew > > On Wed, Nov 29, 2017 at 9:04 AM Jean-Marc Valin <jmvalin at jmvalin.ca > <mailto:jmvalin at jmvalin.ca>> wrote: > > On 11/29/2017 03:23 AM, Ulrich Windl wrote: > > Following the thread from outside, I think Drew should work on > in-house quality assurance ;-) > > Happens to everyone, myself (definitely)...

...w Allen <bitllama at google.com > <mailto:bitllama at google.com>> wrote: > > Aha good point! Im travelling this weekend but will submit another > patch Monday morning. > > Cheers, > Drew > On Fri, Nov 24, 2017 at 9:15 AM Jean-Marc Valin <jmvalin at jmvalin.ca > <mailto:jmvalin at jmvalin.ca>> wrote: > > Hi Drew, > > I noticed you reverted the > output[output_rows * i] = (tmp + 16384) >> 15; > from the previous patch. That's still good. What should have been >...

..., I think Drew should work on in-house quality assurance ;-) > I think you just attached the wrong (previous) version of the patch. > > Jean-Marc > > On 11/28/2017 12:24 PM, Drew Allen wrote: >> Done! >> >> On Tue, Nov 28, 2017 at 12:12 AM Jean-Marc Valin <jmvalin at jmvalin.ca >> <mailto:jmvalin at jmvalin.ca>> wrote: >> >> I only had a quick look, but your patch looks good except for the: >> output[output_rows * i] = (1/(32768.f*128.f))*tmp; >> >> For floating point, you shouldn't do the &gt...

I've solely addressed this concern here. Cheers, Drew On Fri, Nov 24, 2017 at 9:15 AM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Hi Drew, > > I noticed you reverted the > output[output_rows * i] = (tmp + 16384) >> 15; > from the previous patch. That's still good. What should have been > changed is the float version: > output[output_rows * i] = (1/32768.f) * ((tmp + 1...

Aha good point! Im travelling this weekend but will submit another patch Monday morning. Cheers, Drew On Fri, Nov 24, 2017 at 9:15 AM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Hi Drew, > > I noticed you reverted the > output[output_rows * i] = (tmp + 16384) >> 15; > from the previous patch. That's still good. What should have been > changed is the float version: > output[output_rows * i] = (1/32768.f) * ((tmp + 1...

...patch (attached). Can you confirm you're OK with those and I haven't missed anything? Cheers, Jean-Marc On 12/04/2017 06:34 PM, Drew Allen wrote: > I've solely addressed this concern here. > > Cheers, > Drew > > On Fri, Nov 24, 2017 at 9:15 AM Jean-Marc Valin <jmvalin at jmvalin.ca > <mailto:jmvalin at jmvalin.ca>> wrote: > > Hi Drew, > > I noticed you reverted the > output[output_rows * i] = (tmp + 16384) >> 15; > from the previous patch. That's still good. What should have been > changed is the f...

Done! On Tue, Nov 28, 2017 at 12:12 AM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > I only had a quick look, but your patch looks good except for the: > output[output_rows * i] = (1/(32768.f*128.f))*tmp; > > For floating point, you shouldn't do the >>7 either. Just remove the >>8 > from the floating-point calculation of...

...n-Marc, Attached is an updated patch. I had to include some of Mark's suggestions in order to get the tests to work correctly. I will still submit a separate patch for him for a few other concerns he had after this one clears. Cheers, Drew On Thu, Nov 23, 2017 at 10:42 AM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Actually, there's also something wrong with the in_short() function. For > floating point (#else case), you shouldn't need shifting since you're > already doing the scaling through a float multiply. > > Jean-Marc > > On 11/23/2017...

Red Hat Enterprise Linux Server release 6.4 (Santiago) gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) We see the issue in all our Intel based Linux servers. Thanks Suresh On 21 April 2015 at 12:41, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Still can't reproduce. What OS and compiler version? > > Jean-Marc > > On 21/04/15 02:48 AM, Suresh Thiriveedi wrote: > > Hi, > > > > There is no change in the compiler flags. I'm using as it is from the > > original...

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

...had to include some of Mark's > suggestions in order to get the tests to work correctly. I will still > submit a separate patch for him for a few other concerns he had after > this one clears. > > Cheers, > Drew > > On Thu, Nov 23, 2017 at 10:42 AM Jean-Marc Valin <jmvalin at jmvalin.ca > <mailto:jmvalin at jmvalin.ca>> wrote: > > Actually, there's also something wrong with the in_short() function. For > floating point (#else case), you shouldn't need shifting since you're > already doing the scaling through a float mu...

...over the weekend. Cheers, Drew On Fri, Nov 24, 2017 at 10:08 AM Drew Allen <bitllama at google.com> wrote: > Aha good point! Im travelling this weekend but will submit another patch > Monday morning. > > Cheers, > Drew > On Fri, Nov 24, 2017 at 9:15 AM Jean-Marc Valin <jmvalin at jmvalin.ca> > wrote: > >> Hi Drew, >> >> I noticed you reverted the >> output[output_rows * i] = (tmp + 16384) >> 15; >> from the previous patch. That's still good. What should have been >> changed is the float version: >> output[outpu...

...nb_output_streams ? Cheers, Jean-Marc > Cheers, > Drew > > On Wed, Nov 8, 2017 at 4:44 PM Drew Allen <bitllama at google.com > <mailto:bitllama at google.com>> wrote: > > Sure, ill send that asap > On Wed, Nov 8, 2017 at 4:44 PM Jean-Marc Valin <jmvalin at jmvalin.ca > <mailto: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, Dr...

...also crashed (same). Do I need to change any Makefile setting based on my system configuration? What is your system config? *This is my system config:* model name :* Intel(R) *Core(TM) i3 CPU 540 @ 3.07GHz Thanks Suresh On 21 April 2015 at 07:45, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > I just tried decoding with v1.1: > ./opus_demo -d 48000 2 opus_encoded_crash.opus out.pcm > > and I see no issue (including with valgrind). Does the same command-line > create problems for you? What compile flags did you use? fixed-point or > float, any...

...em config? > > *This is my system config:* > model name :*Intel(R) *Core(TM) i3 CPU 540 @ 3.07GHz > > > Thanks > Suresh > > > > > > > > > > > > > > > > On 21 April 2015 at 07:45, Jean-Marc Valin <jmvalin at jmvalin.ca > <mailto:jmvalin at jmvalin.ca>> wrote: > > I just tried decoding with v1.1: > ./opus_demo -d 48000 2 opus_encoded_crash.opus out.pcm > > and I see no issue (including with valgrind). Does the same command-line > create problems for you...

...l.com> wrote: > > Red Hat Enterprise Linux Server release 6.4 (Santiago) > gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) > > We see the issue in all our Intel based Linux servers. > > Thanks > Suresh > > > > On 21 April 2015 at 12:41, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > >> Still can't reproduce. What OS and compiler version? >> >> Jean-Marc >> >> On 21/04/15 02:48 AM, Suresh Thiriveedi wrote: >> > Hi, >> > >> > There is no change in the compiler flags. I'm using...

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 > > files function in this way, possibly that's worth refactoring as well > > (as a separate patch). > > Well, the opus_m...

...n Tue, Nov 7, 2017 at 3:04 PM Drew Allen <bitllama at google.com > <mailto:bitllama at google.com>> wrote: > > Awesome!!!! Ill think about a strategy for that soon. Glad it could > finally make it in. > > On Tue, Nov 7, 2017 at 3:01 PM Jean-Marc Valin <jmvalin at jmvalin.ca > <mailto:jmvalin at jmvalin.ca>> wrote: > > Hi Drew, > > Thanks for the update. Your patch is now in master. Now, it would be > good if you could think of a way to reduce the stack usage as we > discussed. > >...

Hi all, Attached is a quick patch that addresses a bug when exporting the matrix from the encoder. Cheers, Drew On Wed, Nov 8, 2017 at 4:44 PM Drew Allen <bitllama at google.com> wrote: > 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, >> >...