search for: nb_subfram

...would be with the SH[RL]32 and ADD32 functions. Nice call. The culprit is SHRL32. This is not used in many places, and in most of those, the operand comes from EXTEND32. The only really suspicious instances is in lsp.c (lsp_interpolate): spx_word16_t tmp = DIV32_16(SHL32(1 + subframe,14),nb_subframes); (subframe is an int) > I just checked in changes that may fix some bad behavior on 16-bit > architectures. You might want to try if it fixes the problem. As I said, > it's not clear yet whether the problem is in fixed_generic.h or if it's > somewhere else and Stuart's...

Hi Felicia, A few comments: > - /* CELT can only support up to 20 ms */ > subframe_size = st->Fs/50; > - nb_subframes = frame_size > st->Fs/25 ? 3 : 2; > + nb_subframes = frame_size/subframe_size; This will use six 20ms frames to make a 120ms packet, even for SILK-only mode where frames can be up to 60ms. For SILK, two 60ms frames would be a more efficient way to encode a 120ms packet. Also FEC...

...ts. > > On Sun, Jun 12, 2016 at 6:34 AM Mark Harris <mark.hsj at gmail.com> wrote: > >> Hi Felicia, >> >> A few comments: >> >> > - /* CELT can only support up to 20 ms */ >> > subframe_size = st->Fs/50; >> > - nb_subframes = frame_size > st->Fs/25 ? 3 : 2; >> > + nb_subframes = frame_size/subframe_size; >> >> This will use six 20ms frames to make a 120ms packet, even for >> SILK-only mode where frames can be up to 60ms. For SILK, two 60ms >> frames would be a more effic...

...t gmail.com> wrote: > >> > >>> Hi Felicia, > >>> > >>> A few comments: > >>> > >>> > - /* CELT can only support up to 20 ms */ > >>> > subframe_size = st->Fs/50; > >>> > - nb_subframes = frame_size > st->Fs/25 ? 3 : 2; > >>> > + nb_subframes = frame_size/subframe_size; > >>> > >>> This will use six 20ms frames to make a 120ms packet, even for > >>> SILK-only mode where frames can be up to 60ms. For SILK, two 60ms &...

...Mark, Jean-Marc, Thanks for your comments. On Sun, Jun 12, 2016 at 6:34 AM Mark Harris <mark.hsj at gmail.com> wrote: > Hi Felicia, > > A few comments: > > > - /* CELT can only support up to 20 ms */ > > subframe_size = st->Fs/50; > > - nb_subframes = frame_size > st->Fs/25 ? 3 : 2; > > + nb_subframes = frame_size/subframe_size; > > This will use six 20ms frames to make a 120ms packet, even for > SILK-only mode where frames can be up to 60ms. For SILK, two 60ms > frames would be a more efficient way to encode a...

...16 at 6:34 AM Mark Harris <mark.hsj at gmail.com> wrote: >> >>> Hi Felicia, >>> >>> A few comments: >>> >>> > - /* CELT can only support up to 20 ms */ >>> > subframe_size = st->Fs/50; >>> > - nb_subframes = frame_size > st->Fs/25 ? 3 : 2; >>> > + nb_subframes = frame_size/subframe_size; >>> >>> This will use six 20ms frames to make a 120ms packet, even for >>> SILK-only mode where frames can be up to 60ms. For SILK, two 60ms >>> frames w...

Hi, I wondered if are there any further thoughts on these patches? Thanks, Felicia On Thu, Jun 2, 2016 at 2:13 PM Felicia Lim <flim at google.com> wrote: > OK, I've amended the second patch and also added 80 and 100 ms. > > Thanks, > Felicia > > > On Thu, Jun 2, 2016 at 7:20 AM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > >> On 06/01/2016 02:06

> Nice call. The culprit is SHRL32. This is not used in many places, and in > most of those, the operand comes from EXTEND32. The only really suspicious > instances is in lsp.c (lsp_interpolate): > > spx_word16_t tmp = DIV32_16(SHL32(1 + subframe,14),nb_subframes); > (subframe is an int) > ... > I see that your changes include adding an EXTEND32 to the line above. I > made ONLY this change to the 1.1.8 base that I am working from, and the > problem is gone. Good. So I guess you are still having your low MIPS count, right? How much is t...

...e call. The culprit is SHRL32. This is not used in many places, and >> in >> most of those, the operand comes from EXTEND32. The only really >> suspicious >> instances is in lsp.c (lsp_interpolate): >> >> spx_word16_t tmp = DIV32_16(SHL32(1 + subframe,14),nb_subframes); >> (subframe is an int) >> ... >> I see that your changes include adding an EXTEND32 to the line above. I >> made ONLY this change to the 1.1.8 base that I am working from, and the >> problem is gone. > > Good. So I guess you are still having your low MIPS c...

Jean-Marc, >> I incorporated Stuarts fixed_c55x.h file, and that eliminated the >> artifacts, >> at the expense of a ~30% increase in MIPs. Now the male.wav file through >> encoder/decoder produces a bit-exact match with the C64x test that I did >> earlier. I will do some more testing to isolate the, but it may be a few >> days before I get to this task. As