similar to: How to negotiate 'Opus/Celt only'?

Just to make sure, what's the goal here? Is the goal 1) to have a fast Opus implementation or are you 2) looking for an interesting FPGA implementation project? If 1), then an FPGA is most likely not necessary since Opus is not computationally expensive. If 2), then it depends on the desired size of the project and the desired quality. The simplest encoder possible is indeed simpler than the

Hi, We would like to use the OPUS codec @ 16 kHz sampling rate and max 32 kbps. What about implementing an OPUS coder and decoder in an FPGA? Has this been done? Would either coder or decoder more suitable for FPGA implementation? Best regards Fredrik Bonde -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Thu, Nov 14, 2013 at 12:51 AM, Fredrik Bonde <Fredrik.Bonde at ascom.se> wrote: > 1. Is it possible to via SDP force the remote party to send a > specific mode of the 32 different possible modes or to force the remote side > to use CELT only? No, and if you cannot decode opus completely (all modes) your device is not conformant with the Opus specification. I'm

Hello Joshua, I understand. My main aim to first understand the processing overhead when decisions have to be made for a fixed audio in signal, reduce it so that I can then begin making an update to reduce the memory (on chip flash and RAM) footprint. Thanks Amit On Thu, Dec 31, 2015 at 7:58 PM, Joshua Bowman <silverbacknet at gmail.com> wrote: > Opus will always use whatever mode it

Dear all, Sorry for this simple and maybe stupid question, I'm working in the implementation of opus for ARMv7e microcontroller using a library CMSIS/DSP used to calculate the CFFT and MDCT based on the DCT-IV. my question is: In the implementation of Celt you have used a fixed length CFFT equal to 1920, I want to know if there is some issues which can appear if a change that configuration

--- src/opus_private.h | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/src/opus_private.h b/src/opus_private.h index 63338fe..5bbd7dc 100644 --- a/src/opus_private.h +++ b/src/opus_private.h @@ -33,6 +33,8 @@ #include "opus.h" #include "celt.h" +#include <stddef.h> /* offsetof */ + struct OpusRepacketizer { unsigned char

Is there a particular reason why CELT grabs 100KB of stack immediately? Is that really required or can that be trimmed down some/a lot? -a

I'm not aware of an FPGA implementations yet. You could be the first! An encoder implementation would be much easier, because there are almost no rules about encoders. An encoder is free to behave any way it wants, so you could implement a very small subset of Opus and still have a compliant (and useful) encoder. A decoder implementation would be much harder, because decoders are required

Hello All. Could anybody help me with one question about CELT? I develop one project based on ARM7TDMI or Cortex C3 core. Can i use CELT with 32kHz and 48kB on these fixed point cores? Or it`s need to transfer project to Blackfin core (but it isn`t convenient to me)? With best regards, Alexey Voroshen.

-- Joshua Bowman Silverback Networks (559) 305-3770 silverbacknet at gmail.com www.silverbacknetworks.net -------------- next part -------------- src/analysis.c | 6 +++--- src/mlp.c | 3 +++ src/opus.vcxproj | 5 +++++ src/opus.vcxproj.filters | 15 +++++++++++++++ src/opus_demo.vcxproj | 4 ++++ src/opus_demo.vcxproj.filters |

Hello, We have been trying to add asterisk to our Ascom Ascotel 2050 PBX. We have a AVM Fritz!PCI Card connected to an S0 bus extension from the PBX. The fritz card is configured to use chan_capi, and we can make calls SIP->SIP SIP->PBX extension PBX extension->SIP all successfully, we have assigned more than one PBX extension number to the S0 port in the Ascom PBX (it has 8 positions)

Hello Opus community, I'd like to ask you for advice and recommendations. WebRTC uses Opus, and I noticed https://webrtc-codereview.appspot.com/5549004 started referring to currently internal Opus headers. This is possible because for Chromium the Opus sources are just checked in, so any header can be #included. I detected this when trying to package Chromium for Linux distributions with

I tracked down the bug to an incorrect use of restrict. I would not consider this a compiler bug: we are lying to the optimizer by telling it that a pointer is restrict when in fact it isn't. This can be fixed like so: diff --git a/celt/mdct.c b/celt/mdct.c index 1634e8e..fa5098c 100644 --- a/celt/mdct.c +++ b/celt/mdct.c @@ -276,8 +276,8 @@ void clt_mdct_backward(const mdct_lookup *l,

Hello All, I extended the libNE10 optimizations for float towards mdct_backwards/opus_ifft. I am able to get about 14.26% improvement for Decode use case now on my Beaglebone Black. Please see [1] for measurements. Questions 1. Since this patch needs to go in after Encode [2] patch) should I submit this as patch series? 2. Since Jonathan Lennox posted intrinsics cleanup [3] patch, should

Changes from RFC PATCH v1: - passing arch parameter explicitly - reduced stack usage by ~3.5K by using scaled NE10 fft version - moved all optimization array functions to arm_celt_map.c - Other cleanups pointed out by Timothy Phil, As you mentioned earlier, could you please address all compile and linker errors/warnings coming out of Ne10 library? You can find my working Ne10 repo at [1] You

Changes from RFC PATCH v2 - fixed compile issue when just compiling for --enable-intrinsics for ARMv7 without NE10 - Notes for NE10: - All compile/link warnings are now in upstream NE10 - Only patch pending upstream in NE10 is the one that needs to add -funsafe-math-optimizations for ARMv7 targets. - Phil Wang @ ARM is working on getting this fixed. - Note that even without

Changes from RFC PATCH v3 - Just rebased on tip - For all else, please see notes from RFC PATCH v3 at http://lists.xiph.org/pipermail/opus/2015-March/002902.html - latest wip opus tree/branch https://git.linaro.org/people/viswanath.puttagunta/Ne10.git branch: rfcv4_final_fft_ne10 Viswanath Puttagunta (1): armv7(float): Optimize encode usecase using NE10 library Makefile.am

After a few experiments, I found that both alternatives are very similar, and 2~5% slower compared to the following: diff --git a/celt/mdct.c b/celt/mdct.c index 1634e8e..e490c3b 100644 --- a/celt/mdct.c +++ b/celt/mdct.c @@ -277,7 +277,7 @@ void clt_mdct_backward(const mdct_lookup *l, kiss_fft_scalar *in, kiss_fft_scala it in-place. */ { kiss_fft_scalar * OPUS_RESTRICT yp0 =

Hello opus-dev, I've been cooking up this patchset to integrate NE10 library into opus. Current patchset focuses on encode use case mainly effecting performance of clt_mdct_forward() and opus_fft() (for float only) Glad to report the following on Encode use case: (Measured on my Beaglebone Black Cortex-A8 board) - Performance improvement for encode use case ~= 12.34% (Based on time -p

Hi, Apologies if this is a known issue, but running make on revision e3187444692195957eb66989622c7b1ad8448b06 fails one of the tests when using fixed point configuration (floating point is ok) on my linux x86. Note that libopus1.1, as extracted from the tar ball, is OK. Specifically, the tests that fail are in celt/tests/test_unit_mdct: nfft=32 inverse=0,snr = 85.341197 nfft=32 inverse=1,snr =