similar to: New experimental branch

Alright, I've made the changes to the enum and flag usage. I'm don't see the difference with respect to "disabling blocks of code", since the compiler should completely elide the blocks that are conditioned on a constant 0. If there were compiler errors in the experimental code there could be a difference, but I'm hoping that is not the case on any platform! Either way I

Thank you. Very helpful. > On Jan 27, 2017, at 12:40 PM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > > On 27/01/17 12:29 PM, Jon Lederman wrote: >> Thank you. Yes, we do need both channels independent. So, if we >> encode each channel separately, we will be sacrificing the >> compression ratio we would achieve with stereo encoding, correct? > > Not

On 09/12/2007, Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> wrote: > > The full source for CELT is available at: > http://downloads.us.xiph.org/releases/celt/celt-0.0.1.tar.gz > or through git at http://git.xiph.org/celt.git It seems the current version of celt in git has an experimental Ogg mapping ... I've written up the bos page at

Sounds good, I'll make those changes. Thanks for pointing out the make differences. Do you mind if I add an #ifndef, #define to the top of the file for the experiment flag? The code becomes significantly more nasty with #ifdefs everywhere and it would only get worse in subsequent patches. On May 23, 2016 21:28, "Jean-Marc Valin" <jmvalin at jmvalin.ca> wrote: > On

Hi Drew, On 11/13/2017 03:34 PM, Drew Allen wrote: > Does your encoder support ch253/254? Not at this point. Only families 0 and 1 are supported. I think adding family 2 shouldn't be relatively straightforward, but adding family 3 would require some thought. Cheers, Jean-Marc > Cheers, > Drew > On Mon, Nov 13, 2017 at 12:33 PM Jean-Marc Valin <jmvalin at jmvalin.ca >

On 27/01/17 12:29 PM, Jon Lederman wrote: > Thank you. Yes, we do need both channels independent. So, if we > encode each channel separately, we will be sacrificing the > compression ratio we would achieve with stereo encoding, correct? Not necessarily. Stereo makes two assumptions: 1) It assumes the two channels are somehow correlated 2) It assumes the two channels are meant to be

Hi Jean-Marc, On Jun 15, 2013, at 2:23 AMEDT, Jean-Marc Valin wrote: >> I'm looking at how to run Opus at 44.1K. I have flexibility in the >> frame sizes of the unencoded audio, and packet sizes on the RF link. > > You should probably consider resampling. It's not that expensive and it > would make things easy. But otherwise, see below. Yes, considering your and

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 20 ms */ > > subframe_size = st->Fs/50; > > - nb_subframes = frame_size > st->Fs/25 ? 3 : 2; > > + nb_subframes =

Hi Marcello, Actually, we were careful to avoid the undefined behaviour here. In fact, we are specifically running a clang test detecting undefined behaviour. If you look at the silk_SMLABB_ovflw() macro, you will see it is based on silk_ADD32_ovflw(), which is defined as: #define silk_ADD32_ovflw(a, b) ((opus_int32)((opus_uint32)(a) + (opus_uint32)(b))) By casting to unsigned, all the cases

Hi everyone, I've just made the first public release of some new *experimental* codec work I've been doing (part of the vague Ghost project) with help from Monty and Timothy. This is mainly intended with developers with DSP knowledge, not for doing anything useful with it (but it does encode and decode already). Also, the main idea is *not* to replace either Speex or Vorbis, but to code

Hi everyone, I've just made the first public release of some new *experimental* codec work I've been doing (part of the vague Ghost project) with help from Monty and Timothy. This is mainly intended with developers with DSP knowledge, not for doing anything useful with it (but it does encode and decode already). Also, the main idea is *not* to replace either Speex or Vorbis, but to code

Hi everyone, I've just made the first public release of some new *experimental* codec work I've been doing (part of the vague Ghost project) with help from Monty and Timothy. This is mainly intended with developers with DSP knowledge, not for doing anything useful with it (but it does encode and decode already). Also, the main idea is *not* to replace either Speex or Vorbis, but to code

Hi everyone, I've just made the first public release of some new *experimental* codec work I've been doing (part of the vague Ghost project) with help from Monty and Timothy. This is mainly intended with developers with DSP knowledge, not for doing anything useful with it (but it does encode and decode already). Also, the main idea is *not* to replace either Speex or Vorbis, but to code

Thanks for all the amazing work with ambisonics Drew et al. We're looking forward to the 1.3 final release and have already been successfully using the ambisonic work in production code. Varun -- Engineering Manager Facebook Audio ---------------------------------------------------------------------- Message: 1 Date: Sun, 3 Jun 2018 13:02:18 +0100 From: Peter Robinson

I wasn't implying that anyone do anything about it, just that's it a real problem. Unfortunately, most of the crappy sound cards are the ones that ship with your typical PC, so it's just something that people should be aware of. The solution is pretty straightforward -- just resample the audio data in real time using a reference clock. -----Original Message----- From: Jean-Marc

Hey Jean-Marc, sorry about that... extra lines... was it whitespace? If so, sorry about that. Thanks! Cheers, Drew Cheers, Drew On Fri, Apr 28, 2017 at 2:43 PM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Oops, looks like we both should have been more careful. The patch had > some extra lines that shouldn't have been there. > > Jean-Marc > > On

This is a very real problem though.. I've encountered many sound cards that use different clocks for input and output (even on the same card!) Also, if you open up a sound device on windows at 8kHz, the microphone is often around 8100Hz, while the output is 8000Hz.. I'm not sure if there's a bug somewhere in some of the OS resampling algorithms, but I've seen that on many machines.

Hi Marcello, Thanks for the info and the proposed fixes. I'm currently investigating what's going on here before deciding on the best way to fix the problem. Have you been able to figure out why it doesn't work for rshifts >= 3? Cheers, Jean-Marc On 13/06/14 12:28 PM, Marcello Caramma (mcaramma) wrote: > Hi Jean Marc, > > please find attached the audio file (mono

We have found that it is possible to achieve a 30 to 50% reduction in MHz requirement for implementation of OPUS on Cortex M4 compared to the public version (v1.3 beta/v1.2.1). For the CELT configuration you mention (complexity 0, 16kHz, mono, 20ms) we are measuring a 4ms encode time and a 3ms decode time for that platform (32kbit/s). An important issue that I haven't seen much discussion

Right, there shouldn't be a problem with undefined behavior. That said, a 64 bit implementation will work very well - in fact that's how it was done originally. The reason for the current implementation is to minimize 64-bit operations in order to improve performance on limited-width architectures. This functions gets used extensively, and I think the current implementation is faster on