similar to: Using opus on ATMEL 32-bit RISC microcontroller

Hi Jean-Marc, thanks a lot for your reply. > Well, the first question is whether you want encoding, decoding, or > both. If there's one you don't need then you can remove that > (unfortunately, there's no easy way right now). You're right! I forgot to say that I need only the encoder side (and only for voice). My application have to acquire a 16bit 8KHz PCM stream and

Hello Daniele It would be worthwhile to attach an external serial flash or USB thumb drive, if the intent is store data. This allows for far more flexibility in storage Regards Amit On Fri, Aug 26, 2016 at 11:02 AM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > On 26/08/16 11:40 AM, Daniele Barzotti wrote: > > You're right! I forgot to say that I need only the encoder

Hi Daniele, On 26/08/16 10:39 AM, Daniele Barzotti wrote: > Have I any way to reduce the source footprint? > (Eg. throw away unecessary files, if there are any..) Well, the first question is whether you want encoding, decoding, or both. If there's one you don't need then you can remove that (unfortunately, there's no easy way right now). Even if you need both, then you can

Hi all, thanks a lot for your replies! Sorry for my typo, the flash size is 8MB (Byte) :-) Unfortunately I cannot use another flash because I'm working on a proprietary board. Jean-Marc, thanks for your suggestions. I thought to use fixed point for convenience, but I can work on floating point too, so I will take in account the codec2 (I didn't know it). Moreover, if you all have

On 26/08/16 11:40 AM, Daniele Barzotti wrote: > You're right! I forgot to say that I need only the encoder side (and > only for voice). Then you can remove all of the decoder. As for the encoder, it depends on the bitrate and sampling rate you want (more below). > My application have to acquire a 16bit 8KHz PCM stream and save a > compressed audio into a flash. Sounds like a job

ATMEL GNN - Components 1. Introduction : Atmel Corporation (http://www.gnn-components.com/Atmel_corporation-22-423.aspx) is a global leader in designing, manufacturing and marketing advanced semiconductorsincluding microcontroller (MCU), programmable logic, and nonvolatile memory. Atmel meets the evolving and growing needs of today's electronic system design engineer through the production

Dear sirs, I'm trying to build an Opus library for an embedded application to run on a Microchip PIC32MX processor and I get a lot of errors in compilation time. My question is, what should be the minimum files and options needed to have such building, having in mind that only the very basic functionality in fixed point arithmetic is needed? Looking forward to your answer. Kind

Hi all, I would like to implement an opus encoder on a TI CC2650 MCU (128 kB Flash). I did not find any information about the hardware requirements of opus, but I found that someone already had trouble with the flash size with the 512 kB ATMEL AT32UC3B0512. (http://lists.xiph.org/pipermail/opus/2016-August/ 003611.html) Do you think I should start implementing or rather find an other

Hi Jean-Marc, The original celt_fir() is a little bit messy. It has 2 branches chosen by #ifdef SMALL_FOOTPRINT. For floating-point, the 2 branches are identical (except the operation sequence of accumulating x[i] to sum, which is not a big deal). For fixed-point, the 2 branches are different. I separate them into 2 functions: the new celt_fir(), and celt_fir_permit_overflow() which is the

Linfeng Zhang wrote: > +#ifdef SMALL_FOOTPRINT > + for (i=0;i<N-7;i+=8) > + { > [snip over 80 lines of complicated NEON intrinsics code] > + } > +#else So, one of the points of SMALL_FOOTPRINT is to reduce the code size on targets where this matters (even if it means running slower), but this is an awful lot of code. I think it makes much more sense to expose the

Hello, for your consideration. The following patch moves the channel_pos() function from within the #if !defined(DISABLE_FLOAT_API). This change is required when compiling with FIXED_POINT and DISABLE_FLOAT_API defined. #### ### diff --git a/src/opus_multistream_encoder.c b/src/opus_multistream_encoder.c index 3efab53..6f3eb53 100644 --- a/src/opus_multistream_encoder.c +++

The atmel-hlcdc driver uses an empty implementation for its encoder. Replace the code with the generic simple encoder. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> --- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c

This patch set nukes all the dummy crtc mode_fixup implementations. (made on top of Daniel topic/drm-misc branch) Signed-off-by: Carlos Palminha <palminha at synopsys.com> --- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 9 --------- 1 file changed, 9 deletions(-) diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c index

Thanks Boris. @Daniel, do you want me to resend this patch or will you fix it directly in mode-fixup git branch? On 16-02-2016 16:58, Boris Brezillon wrote: > On Tue, 16 Feb 2016 14:19:06 +0000 > Carlos Palminha <CARLOS.PALMINHA at synopsys.com> wrote: > >> This patch set nukes all the dummy crtc mode_fixup implementations. >> (made on top of Daniel topic/drm-misc

We have a 1:1 relationship between connectors and encoders and the driver is relying on the atomic helpers: we can drop the custom ->best_encoder() and let the core call drm_atomic_helper_best_encoder() for us. Signed-off-by: Boris Brezillon <boris.brezillon at free-electrons.com> --- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 12 ------------ 1 file changed, 12 deletions(-)

On Wed, Aug 21, 2024 at 02:59:08PM +0200, Thomas Zimmermann wrote: > Call drm_client_setup_with_fourcc() to run the kernel's default client > setup for DRM. Set fbdev_probe in struct drm_driver, so that the client > setup can start the common fbdev client. > > v2: > - use drm_client_setup_with_fourcc() > > Signed-off-by: Thomas Zimmermann <tzimmermann at

Interested in building a speex codec (basically audio <-> speex <-> data stream) using TI's small MSP430 microcontroller. Is there any way to estimate feasibility based on CPU requirements? Example - speex is happily encoding on an old Pentium-1 processor (166 MHz) using about half the CPU (as reported under Linux); the TI microcontrollers are much slower yet (8-16-25 MHz) and

On Wed, Feb 17, 2016 at 09:02:44AM +0000, Carlos Palminha wrote: > Thanks Boris. > > @Daniel, do you want me to resend this patch or will you fix it directly in mode-fixup git branch? I can fix the typos, but I'm meh on the whitespace change ;-) Imo that doesn't need a resend. -Daniel > > On 16-02-2016 16:58, Boris Brezillon wrote: > > On Tue, 16 Feb 2016 14:19:06