search for: flim

...the package LocFit to follow the example given in an Introductory note of C Loader concerning density estimation. It involves the "geyser" dataset (107 observations on durations, inlc in the package). I have tried the following (using the latest version of R): fit.of <- locfit(~geyser,flim=c(1,6),alpha=c(0.15,0.9)) plot(fit.of,get.data=T,mpv=200) This produces a plot (after several warnings). My question is: how can I get the plot to cover the range: 1 - 6 ? for durations. The plot covers the observed data range only. It appears there is a problem with flim=c(1,6) flim is not actu...

...(One issue might be that clang’s address sanitizer isn’t smart enough to > know that PMOVSXWD only loads 8 bytes, despite _mm_cvtepi16_epi32’s > argument being an __mm128i; I’ve seen it trigger incorrect out-of-bounds > read errors.) > > On Aug 18, 2017, at 12:34 PM, Felicia Lim <flim at google.com> wrote: > > Hi, > > Please find attached a patch to fix alignment exceptions. Without this > change, we were seeing occasional alignment faults when using this with > clang. > > Thanks, > Felicia > > <e5c277c.diff>_____________________________...

...- > > I wonder whether it wouldn't be better style to convert argv[ args + 1 ] > to a number once and then use a switch/case statements to test for > individual numbers. Or is it expected to be non-numerical once? > > Regards, > Ulrich > > >>> Felicia Lim <flim at google.com> schrieb am 27.06.2016 um 15:05 in > Nachricht > <CAJ0LFHW97AJ0J4EsaV2yO+EjJKnz8F47w1Te6_0y4tLA6xAmsw at mail.gmail.com>: > > Attached is the amended second patch. It now extends the multistream API > as > > well to 80/100/120 ms and incorporates changes...

Attached is the amended second patch. It now extends the multistream API as well to 80/100/120 ms and incorporates changes based on Mark's comments. Thanks, Felicia On Mon, Jun 13, 2016 at 4:21 PM Felicia Lim <flim at google.com> wrote: > Hi 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...

..., %xmm3 pmullw %xmm1, %xmm2 --- 73,80 ---- cmpl $4, %eax jl .LBB0_8 # BB#7: ! movq (%edx,%edi,2), %xmm2 # xmm2 = mem[0],zero ! movq (%esi,%edi,2), %xmm1 # xmm1 = mem[0],zero addl $4, %edi movdqa %xmm2, %xmm3 pmullw %xmm1, %xmm2 On Fri, Aug 18, 2017 at 12:11 PM, Felicia Lim <flim at google.com<mailto:flim at google.com>> wrote: We see the MOVQ instruction but this patch deliberately uses it rather than MOVQDA (load 128-bits aligned). We were seeing that with the trace below, the final invocation is not 128-bit aligned but MOVQDA insists on it (the calling function...

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 PM, Felicia Lim wrote: >> >...

On 06/01/2016 02:06 PM, Felicia Lim wrote: > That was my intention with refactoring out the subframe encoding and > repacketizing bit. Or do you mean I should merge the explicit check for > 120 ms frame and the existing checks for 40/60 ms wideband? What I mean is that this line in opus_encoder.c: if (frame_size > st->Fs/50 && (st->mode == MODE_CELT_ONLY ||

...th limited links having a gross (physical) bit rates of 10kbps per channel. Decades ago I calculated with figure (for AMR-NB but the same holds for Opus). https://www.tkn.tu-berlin.de/fileadmin/fg112/Hard_Software_Components/Software/hoene_07_2004_paper.pdf Von: Felicia Lim [mailto:flim at google.com] Gesendet: Freitag, 10. Juni 2016 16:59 An: Christian Hoene <christian.hoene at symonics.com> Betreff: Re: [opus] Patches for adding 120 ms encoding Yes, that's right. In that case, a longer frame size means that we can reduce header overhead. On Fri, Jun 10, 2016 a...

...frame_size = 6*sampling_rate/50; -- I wonder whether it wouldn't be better style to convert argv[ args + 1 ] to a number once and then use a switch/case statements to test for individual numbers. Or is it expected to be non-numerical once? Regards, Ulrich >>> Felicia Lim <flim at google.com> schrieb am 27.06.2016 um 15:05 in Nachricht <CAJ0LFHW97AJ0J4EsaV2yO+EjJKnz8F47w1Te6_0y4tLA6xAmsw at mail.gmail.com>: > Attached is the amended second patch. It now extends the multistream API as > well to 80/100/120 ms and incorporates changes based on Mark's comme...

Hi, Please find attached a patch to fix alignment exceptions. Without this change, we were seeing occasional alignment faults when using this with clang. Thanks, Felicia -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/20170818/e0d6bb06/attachment.html> -------------- next part -------------- A non-text

...ms encoding > > Cheers, > > Jean-Marc > > > On 06/10/2016 10:19 AM, Felicia Lim wrote: >> 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 >> <mailto: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...

Hi all, We (WebRTC/Google) would like to extend Opus to natively support 120 ms encoding instead of relying on repacketization as a post processing step. This is to ensure that a valid 120 ms packet is always available. I've attached a couple of patches to add this to opus_encoder(), based on the internal repacketization process carried out by 60 ms CELT. We intend to extend this later for

..., %xmm3 pmullw %xmm1, %xmm2 --- 73,80 ---- cmpl $4, %eax jl .LBB0_8 # BB#7: ! movq (%edx,%edi,2), %xmm2 # xmm2 = mem[0],zero ! movq (%esi,%edi,2), %xmm1 # xmm1 = mem[0],zero addl $4, %edi movdqa %xmm2, %xmm3 pmullw %xmm1, %xmm2 On Fri, Aug 18, 2017 at 12:11 PM, Felicia Lim <flim at google.com> wrote: > We see the MOVQ instruction but this patch deliberately uses it rather > than MOVQDA (load 128-bits aligned). We were seeing that with the trace > below, the final invocation is not 128-bit aligned but MOVQDA insists on it > (the calling function was pitch_ss...

...API. 2) You might want to check that CBR works for >60 ms encoding Cheers, Jean-Marc On 06/10/2016 10:19 AM, Felicia Lim wrote: > 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 > <mailto: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 > <mai...

Hi all, The attached patch adds/fixes a few null argument checks in the multistream API. Do these changes make sense? Thanks, Felicia -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/20170324/1afee1e1/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name:

|frame_size_enum| in tests/test_opus_encode.cl:117 is flagged as potentially uninitialized but get_frame_size_enum() will fail anyway if a valid value is not found. --- tests/test_opus_common.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tests/test_opus_common.h b/tests/test_opus_common.h index ff7f0142..8b878607 100644 --- a/tests/test_opus_common.h +++ b/tests/test_opus_common.h @@

r+ with James' fix. On 12/07/17 02:01 PM, James Zern wrote: > On Wed, Jul 12, 2017 at 10:58 AM, Felicia Lim <flim at google.com> wrote: >> |frame_size_enum| in tests/test_opus_encode.cl:117 is flagged as potentially >> uninitialized but get_frame_size_enum() will fail anyway if a valid value is >> not found. >> --- >> tests/test_opus_common.h | 2 ++ >> 1 file changed, 2...

...he issue you’re seeing? (One issue might be that clang’s address sanitizer isn’t smart enough to know that PMOVSXWD only loads 8 bytes, despite _mm_cvtepi16_epi32’s argument being an __mm128i; I’ve seen it trigger incorrect out-of-bounds read errors.) On Aug 18, 2017, at 12:34 PM, Felicia Lim <flim at google.com<mailto:flim at google.com>> wrote: Hi, Please find attached a patch to fix alignment exceptions. Without this change, we were seeing occasional alignment faults when using this with clang. Thanks, Felicia <e5c277c.diff>_______________________________________________...

...s frame. I believe that the logic and threshold > values for making these decisions are still valid for 120 ms, but I > might be missing something? Please find my updated patches attached. > > Thanks, > Felicia > > > > On Tue, May 31, 2016 at 7:05 PM Felicia Lim <flim at google.com > <mailto:flim at google.com>> wrote: > > Hi all, > > We (WebRTC/Google) would like to extend Opus to natively support 120 > ms encoding instead of relying on repacketization as a post > processing step. This is to ensure that a valid 12...

Good afternoon, My name is Thiago. I'm?a graduate student?and affiliated to an Anuran Bioacustic and Systematics Laboratory at UFU (Federal University of Uberl?ndia)?in Brazil.?The professor in charge of the?lab (Dr. Ariovaldo Antonio Giaretta) and I?have recently been?making use?of R, specially the packages Sound and Seewave so as to analize?anuran recordings. This software is just