similar to: incorrect use of MAX16

The patch prevents KEIL MDK compile warnings, like:   warning:  #1035-d: single-precision operand implicitly converted to double-precision Actually ARM Cortex-M4F has only a *single precision* (float) FPU. It's suit for all platforms. See the comment at the begin of patch file. Sincerely Forrest Zhang -------------- next part -------------- Specify the floating point constant with single

Here some Blackfin inline assembly, mainly picked and adapted from speex. It's helps a little on my BF537 eval board. Julien -------- /** @file fixed_bfin.h @brief Fixed-point operations for the ADI BF5xx DSP family */ /* Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: -

--- libcelt/Makefile.am | 6 +- libcelt/bands.c | 26 +++++++++- libcelt/bands.h | 2 +- libcelt/celt.c | 23 +++----- libcelt/pgain_table.h | 133 ------------------------------------------------- libcelt/quant_pitch.c | 117 ------------------------------------------- libcelt/quant_pitch.h | 44 ---------------- 7 files changed, 37 insertions(+), 314

Greetings, I have found that QCONST16(32.f, 10) yields different result (from gcc 4.4.7 ) when the code is compiled for TI C55 or C64 DSPs. gcc - result is 32767 TI compiler result is -32768 (C55 compiler version 4.4.1 and C6x compiler version 7.4.2) Although not in the current code, QCONST32(32.f, 26) results differ in similar fashion. Judging by the use #ifdef TI_C.. in the code base, these

I did find it using my browser search. I am not sure where the "Git" is. It looks like many of the macros that use the TI intrinsics are commented-out. #if 0 +#include "dsplib.h" + +#undef MAX16 +#define MAX16(a,b) _max(a,b) ... Once my development has commenced (still in the study phase). I will be trying it. dave -----Original Message----- From: Jean-Marc Valin

Hi Jean-Marc et all, Thanks for the quick feedback, responses to your questions are below: I've attached a revised patch. PTAL, thanks! On Fri, Apr 7, 2017 at 1:22 PM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: Hi Drew, Thakns for the patch. Here's some comments for now (not done reviewing): 1) You want to use isqrt32() rather than celt_sqrt(), since celt_sqrt() changes

Hello all, Attached is a proposed patch for Opus that allows support for encoding non-diegetic stereo audio as a coupled stream for use with channel mapping 254. It also rejects channel counts that are not (n+1)^2 + 2j, where n is 0 to 14 and j is either 0 or 1 (See IETF public draft doc attached for clarification). Please let me know any suggestions / concerns / comments. Thank you for your

Hi Drew, Thakns for the patch. Here's some comments for now (not done reviewing): 1) You want to use isqrt32() rather than celt_sqrt(), since celt_sqrt() changes behaviour for fixed-point and provides no guarantee about rounding. 2) About these two lines: + if (nondiegetic_channels && 2 != nondiegetic_channels) + return OPUS_UNIMPLEMENTED; Why not just have the

Hi Drew, I think your revised patch looks good overall. Just two comments: 1) In opus_multistream_encoder_init_impl(), rather than use a huge condition with two ORs for the return OPUS_BAD_ARG, maybe you can just multiple three separate if()s, each with its own condition (one of which will be entirely in an #ifdef). That should make the code easier to read. 2) In

I see the following in arch.h #elif defined (TI_C6X_ASM) #include "fixed_c6x.h" But there does not seem to be a header file by that name in the 1.1.2 distribution. dave

Hi, I'll try to keep this as brief, yet descriptive enough to save everyone some time. If I'm off with this one please forgive me, but it has fixed my issues. I am not sure whether it is just my compiler (gcc 3.3.5) doing the wrong thing with the cast. File: preprocess.c Arch affected: x86, (others?) svn revision: 12778 Description: The SpeexPreprocessState_ member 'nb_adapt'

Hi Jean-Marc, Thanks again for your comments. Attached is a revised patch. On Mon, Apr 24, 2017 at 1:08 PM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Hi Drew, > > I think your revised patch looks good overall. Just two comments: > > 1) In opus_multistream_encoder_init_impl(), rather than use a huge > condition with two ORs for the return OPUS_BAD_ARG, maybe you can

> >Actually, you're the first I know using the VisualDSP++ toolchain :-) > I guess that's because speex has pretty big memory footprint. So developers that integrate speex tend to have plenty of RAM and once one has plenty of RAM he could install biggish OS. And between biggish OSes for Blackfin the most popular choice is uCLinux. And ucLinux works best with gnu tools. Something

Hi, I just started to examine the DIV32_16 function (Blackfin ASM version), and wondered why the return value of the function inside 'fixed_bfin.h' is of type 'spx_word16_t', but the local variable 'res' which is returned by this function is of type 'spx_word32_t'. Is this a trick of optimization or a bug? (Same question for PDIV32_16 and MAX16, too!) best

Hi, I tried to figure out what the problem is -- but it seems to be totally different from what I expected. My status at the moment is: - computing results for "generic" and "Blackfin ASM" versions of the DIV32_16 function are the same, there is no "algorithmic bug" - Instead, there seems some sort of memory corruption: When I comment out the DIV32_16 function

Hi, when I compile with FIXED_DEBUG enabled, I get an error -- both when make tries to build testenc.o and when I try to link my app against the speex lib: lorenz@panelmaker:~/Blackfin/tests/speex_loopthrough$ make bfin-uclinux-gcc -c -g -I/home/lorenz/include -o main.o main.c bfin-uclinux-gcc -gl -elf2flt -L/home/lorenz/lib -o speex_through main.o -lspeex_debug -lspeexdsp -lm

Hi Jean-Marc, after some problems with getting svn to work here I finally made it. Problem is, you write that I cannot use libspeex and libspeexdsp at the same time now -- because I use a "live" system (mic-in -> speex_enc -> speex_dec -> headphone out) and I can run the AD1836 audio codec on 48 kHz only, I cannot use my program now (because I use speex resampling...) So I

Jean-Marc, Frank, I have stumbled across a similar situation regarding optimization. I seem to have a similar setup as Frank does with a fixed 48khz in and out. The wideband mode and ultra-wideband modes are really what I?m looking for. I have a test application that reads audio, downsample to 16kHz (or 32kHz), speex encode, speex decode, upsample back to 48kHz, and playback. If I remove

Most asm statements clobber ASTAT bits (shifts, maxes, etc...) but do declare the register as clobbered. Same thing with CC in a few places. Some places make an attempt at clobbering some hardware loop registers, but it's very incomplete compared with how many asm statements actually use hardware loops. Signed-off-by: Mike Frysinger <vapier at gentoo.org> --- libspeex/bfin.h

Should call celt_inner_prod(). --- celt/bands.c | 7 ++++--- celt/bands.h | 2 +- celt/celt_encoder.c | 6 +++--- celt/pitch.c | 2 +- src/opus_multistream_encoder.c | 2 +- 5 files changed, 10 insertions(+), 9 deletions(-) diff --git a/celt/bands.c b/celt/bands.c index bbe8a4c..1ab24aa 100644 --- a/celt/bands.c +++ b/celt/bands.c