similar to: Problem with Blackfin assembly optimizations -- bug in fixed_bfin.h?

Hi Marc, I encountered the problems even with older versions of speex, including 1.2beta2 and 1.1.12, too. I had no time in the last weeks to investigate this issue further, sorry. Hopefully, I'm able to do some more test the next days, but I have no real idea how to proceed Performance and quality seem to be o.k. for me if I deactivate the Blackfin optimizations inside the file

Hi Jean-Marc, I did some further checks with 1.2 beta 3: The problematic function is DIV32_16 inside fixed_bfin.h. When I comment it out (i.e. replace it by the generic version of the routine), the quality improves significantly. Nevertheless, there is still a horrible distortion when there is some overdrive/saturation in the input signal. For me, it looks like there's an instable filter

Hi Jean-Marc, didn't get a reply to my last post (see below) -- do you have no idea what happens here? After some more tests, I disabled the DIV32_16 Blackfin optimizations and now get good quality on the Blackfin. But when I have overdrive on the input, things become very bad -- I'm not sure if this is really a filter stability issue like I wrote some weeks ago. I use the speex

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

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

Frank Lorenz a ?crit : > And yes, the same "overflow" happens even when I disable Blackfin ASM > optimizations. Indeed, that shouldn't happen. Just to make sure I understand, so far there's two problems: 1) DIV32_16() in Blackfin assembly causes problems 2) The resampler overflows When you fix/workaround those two, is the encoder/decoder working correctly or are there

Hi Jean-Marc I'm trying to integrate your speex codec on our custom Blackfin board. The board is not uCLinux compatible and there is no chance that it will ever be. I am using ADI-supplied VisualDSP++ IDE and corresponding toolchain. As long as I am compiling "C"-only version of the library everything is fine. VisualDSP++ produces working library. There is only one not so minor

> >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 Jean, First, I would like to thank for the prompt reply. Basically, what I have to do is to run a speex coder/decoder on a Blackfin processor, on top of the microC/OS II kernel. I wish I could use uclinux, since I'm familiar with Linux, but this doesn't depend on me. You said that the assembly code is written for gcc, not for VisualDSP++. Furthermore, in the link you sent me, the

-----Original Message----- From: Robin Getz [mailto:rgetz@blackfin.uclinux.org] Sent: Saturday, June 16, 2007 12:11 AM To: Michael Shatz Cc: speex-dev@xiph.org Subject: Re: [Speex-dev] Blackfin inline assembler and VisualDSP++ toolchain >On Wed 13 Jun 2007 12:37, Michael Shatz pondered: >> >> Hi Jean-Marc >> >> I'm trying to integrate your speex codec on our

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

Hi all, I'm trying to run speex on the Blackfin processor. I'm not familiar with programming/compiling/linking at all, but I guess the first thing I need is libspeex compiled for Blackfin, so that my program can use the library functions. I've downloaded the source files (version 1.1.10) from www.speex.org and I've been trying to compile libspeex from within VisualDSP++, but it

Hello all, I'm testing the Speex codec for my diploma thesis on a BF-533 Blackfin under uCLinux (2005R3 RC3 release). I successfully compiled the Speex (1.1.11-svn) and I can encode/decode wav-files on my STAMP-board using the speexenc/speexdec sample apps. But I encountered that the decoded file sounds strange/noisy, when compiling with "--enable-blackfin-asm" +

There are multiple problems with the elf2flt usage in the configure script: - clobbers LDFLAGS - is used for all targets so breaks non-FLAT targets - is only used for Blackfin FLAT targets Signed-off-by: Mike Frysinger <vapier at gentoo.org> --- configure.ac | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index cc30d99..3179521

>-----Original Message----- >From: Robin Getz [mailto:rgetz@blackfin.uclinux.org] >Sent: Tuesday, June 19, 2007 9:35 PM > > >On Tue 19 Jun 2007 13:00, Michael Shatz pondered: >> Robin Getz wrote: >> >I never met any hardware that gcc could not run code on. toolchains have >> >nothing do with embedded OSes. >> >> That's true. Add some

Dear Wine-Team, my name is Sascha Trott and would like to ask you, if I can use the Wine logo (Tux with a bottle of wine) for my home page about "German Wine Tutorials" (http://saschats-winepage.chapso.de/). I would be very happy, if you can send me some informations about. Yours sincerely, Sascha Trott _________________________________________________________________________ In 5

Problems building celt-0.5.2 for blackfin. Use the following to configure: #!/bin/sh # bfinconf # Set up configuration to cross compile on blackfin ./configure \ --host=bfin \ --enable-fixed-point \ CC=bfin-uclinux-gcc \ CFLAGS='-O2 '\ '-mfast-fp '\ '-ffast-math '\ '-Wall -Dlinux '\ '-D__linux__ '\ '-fno-strict-aliasing '\