[Speex-dev] Blackfin port on Visual DSP, Michael Shatz ?
stephane.lesage at ateis-international.com
Wed Nov 21 11:27:20 PST 2007
> -----Original Message-----
> From: Jean-Marc Valin [mailto:jean-marc.valin at usherbrooke.ca]
> Sent: Wednesday, November 21, 2007 4:34 PM
> To: Stéphane Lesage
> Cc: speex-dev at xiph.org
> Subject: Re: [Speex-dev] Blackfin port on Visual DSP, Michael Shatz ?
> > I compiled 1.2beta1, beta2, and the SVN from yesterday.
> > Beta1 works fine, but starting from beta2, the sound is scrambled...
> > Of course, project options are identical.
> > Did you change something in the API ?
> > Do I need to initialize extra things ?
> Can you test with testenc just to make sure? The only thing I
> can think of is that some of the assembly that got
> written/modified between beta1 and beta2 broke it (maybe it's
> just for VDSP). Could you try doing a bisection in svn and
> pinpoint which commit is causing problems?
It's not easy for me to use testenc.
(I have no file-system and limited memory)
But I could find which revision causes my troubles
(by "bisection", did you mean "dichotomie" ?)
Last revision OK:
12171 from 2006/12/4 14:09:18
12173 from 2006/12/6 15:08:39
"zero-response now in 16-bit and stored on the stack. About 1 kB saved off
wideband encoder (including removing unused QMF memory)."
For my sanity, I checked the thread stack size, and increased from 8KB to
32KB, but without result.
0. I'm using the plain C implementation of the fixed-point implementation.
I tried different compiler options, (don't saturate on integer arithmetic or
saturate to 40 bits)
but it's not related (I hoped so, as this implementation should use less
than 16/32 bits)
1. This is really strange, for loud or quick sounds, it's like a part of a
frame is repeated on next frames.
2. The encoder is responsible. Not the decoder.
3. As on 1.2beta1, Echo-cancellation totally removes the problem.
only sb_celp.h/.c changed ???
Is it because you're using only 16-bits instead of 32 ?
> > I noticed a very interesting thing: the echo-cancellation totally
> > removes this problem !!!
> You mean that the codec works if you add the echo
> canceller??? Could be a memory issue...
> > The Visual DSP++ assembler/compiler/linker tools.
> What does that (adding support) involve?
It involves a different ASM implementation.
- intruction syntax is the same
- some constraints are different
- 'dynamic' labels are not available on VDSP
(when you use an inline several times,
the gcc compiler can do some kind of incrementation)
More information about the Speex-dev