Stéphane Lesage
2007-Nov-21 15:56 UTC
[Speex-dev] Blackfin port on Visual DSP, Michael Shatz ?
> -----Original Message----- > From: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca] > Sent: Wednesday, October 17, 2007 1:56 AM > To: St?phane Lesage > Cc: speex-dev@xiph.org > Subject: Re: [Speex-dev] Blackfin port on Visual DSP, Michael Shatz ?Salut Jean-Marc, After 1 month busy on other projects, I can finally answer you:> Some things to check. Do you compile with VAR_ARRAYS? If not, > you can probably reduce the size of the managed stack. In > terms of data RAM, everything should fit into SRAM easily.No I didn't know this macro. According to the sources, I understand it's destined to compilers supporting run-time size for local arrays on the stack. But this is not documented (API or user manual), and does not appear in any header file. It should appear at least in arch.h, commented and defaulting to #undef... BTW, do you have figures on the stack-usage of the different Speex modules ?> I've done some massive wideband RAM reduction in 1.2beta2. If > it's not working on Blackfin, then we'd need to investigate > that first.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 ? See myspeex.c code. It's pretty simple. I noticed a very interesting thing: the echo-cancellation totally removes this problem !!! How can I help you debug this thing ? My platform is Blackfin fixed-point on visual DSP. I can't use the debug-out on VDSP (too slow), but my custom-board has IP and RS232 interfaces which could help.> Depending on whether you're using all the > bit-rates, you might want to put only some of the codebooks > in SRAM (if you tell me what bit-rate, I can tell you which > codebooks you need). > About code, it could be a bit more tricky and I don't know > whether everything can fit into SRAM.Actually performance is not my priority for the moment, as long as Encoder + Echo cancellation + UDP + Decoder runs in real-time on a 400 MHz BF-537. (I'll see later if I can use a slower processor)> > Jean-Marc, I don't want to come back on the debate, but I think you > > should include the VDSP architecture. > > What do you mean by "the VDSP architecture"?The Visual DSP++ assembler/compiler/linker tools.> > (there is also a problem with variables named "bank" > > which is a compiler keyword...) > > You don't even need that part of the code actually. Try > getting the git/svn version where I actually did a split into > libspeex and libspeexdsp. The one you need is libspeex only.I also need the echo-cancellation. and actually I don't know in which files it's implemented ! So I just renamed the variables/members to "bnk". Can you include these modifications ? BTW, everything is in the /libspeex directory... It does not look like we have 2 projects. Moreover you also have examples in this directory. Most users using IDEs are not familiar with make-files and don't know what files to include in their projects. (already seen this on the mailing-list) Maybe you should split it into: /libspeex /libspeexdsp /tests -- St?phane Lesage ATEIS International -------------- next part -------------- A non-text attachment was scrubbed... Name: myspeex.c Type: application/octet-stream Size: 1453 bytes Desc: not available Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20071121/3a00cf4e/myspeex.obj
Jean-Marc Valin
2007-Nov-21 15:56 UTC
[Speex-dev] Blackfin port on Visual DSP, Michael Shatz ?
> No I didn't know this macro. > > According to the sources, I understand it's destined to compilers supporting > run-time size for local arrays on the stack. > > But this is not documented (API or user manual), and does not appear in any > header file. > It should appear at least in arch.h, commented and defaulting to #undef...Actually, it's meant to be auto-detected by the configure script, which is why I didn't bother. But I guess I'll put that on my documentation TODO list.> BTW, do you have figures on the stack-usage of the different Speex modules ?Stack usage for the codec depends a lot on the actual options used. Can range from 2 kB to maybe around 10 kB. As for other modules, they don't use much stack because most of the temporary variables are allocated in the state (fixing this is also on todo list).> 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?> 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...> How can I help you debug this thing ? > My platform is Blackfin fixed-point on visual DSP. > I can't use the debug-out on VDSP (too slow), but my custom-board has IP and > RS232 interfaces which could help.Forget about the debugger. As long as you have one version that works and one that doesn't, the easiest is to just bisect until you find the commit that breaks things. At that point, the problem should be obvious (my commits are generally small).> Actually performance is not my priority for the moment, > as long as Encoder + Echo cancellation + UDP + Decoder runs in real-time > on a 400 MHz BF-537. > (I'll see later if I can use a slower processor)Shouldn't be a problem.>>> Jean-Marc, I don't want to come back on the debate, but I think you >>> should include the VDSP architecture. >> What do you mean by "the VDSP architecture"? > > The Visual DSP++ assembler/compiler/linker tools.What does that (adding support) involve?> I also need the echo-cancellation. > and actually I don't know in which files it's implemented !echo canceller is mdf.c and if you was additional suppression of the remaining echo, it's preprocess.c> So I just renamed the variables/members to "bnk". > Can you include these modifications ?I'll put that on the todo as well.> BTW, everything is in the /libspeex directory... > It does not look like we have 2 projects. > Moreover you also have examples in this directory. > Most users using IDEs are not familiar with make-files > and don't know what files to include in their projects. > (already seen this on the mailing-list) > > Maybe you should split it into: > /libspeex > /libspeexdsp > /testsThere's still a bit of cleanup left to do here. Actually, many of the header files are shared, so I'm still not sure what to do. todo... Cheers, Jean-Marc
Stéphane Lesage
2007-Nov-21 21:12 UTC
[Speex-dev] Blackfin port on Visual DSP, Michael Shatz ?
> -----Original Message----- > From: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca] > Sent: Wednesday, November 21, 2007 4:34 PM > To: St?phane Lesage > Cc: speex-dev@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 Starting bad: 12173 from 2006/12/6 15:08:39 "zero-response now in 16-bit and stored on the stack. About 1 kB saved off the 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) -- St?phane Lesage ATEIS International
Stéphane Lesage
2007-Nov-24 01:47 UTC
[Speex-dev] Blackfin port on Visual DSP, Michael Shatz ?
> -----Original Message----- > From: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca] > Sent: Thursday, November 22, 2007 12:16 AM > To: St?phane Lesage > Subject: Re: [Speex-dev] Blackfin port on Visual DSP, Michael Shatz ? > > (en passant, tu es francophone?)oui, fran?ais, travaillant pour une soci?t? suisse ;-)> > St?phane Lesage a ?crit : > > It's not easy for me to use testenc. > > (I have no file-system and limited memory) > > Fair enough.Well, actually, I found-out that the stdio lib can access my PC file-system through the JTAG interface. So I can eventually try this.> Hmm... let me investigate a bit further. > You mean you disabled blackfin assembly optimisations? Do you > see the same results on a PC. I suspect it could be an > uninitialised memory problem somewhere.Yes, I currently have no ASM optimizations, it's the standard FIXED_POINT code. I didn't test on PC linux/win32, as other users have no trouble on these platform. I looked at the sources and discovered the different temp-memory allocation schemes. After compiling with VAR_ARRAYS, it's better with revision 12173. -> working for 2-3 VoIP calls (init & destroy for each call) -> not working again for next calls With lastest revision from SVN, sometimes it only worked once. Now it's not working anymore. *** WITH preprocessor initialized and called (but nothing activated in it) *** -> same as echo-canceller, it's working. So I think you are right on the memory init problem. Do you think it comes from my run-time libraries ? Or is it a mistake in Speex ?> >>> 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 > > How different?Not so much, it's easy to handle, but would require specific syntax.> > - 'dynamic' labels are not available on VDSP (when you use > an inline > > several times, the gcc compiler can do some kind of incrementation) > > What would you use instead?hehe, that's where I have trouble. No documentation on how to do this... I guess I will have to use PC-relative addressing-mode and compute the offset myself. -> This would compile also on the GCC. Alternatively and because only some functions are used several times, and AFAIR it's mainly the divisions, I can handle this with 3 solutions: - just use the standard syntax to let the compiler use its library. - use built-in functions (can also do this for MUL/MAC functions) - for bigger functions, just de-inline them ! -- Stephane
Jean-Marc Valin
2007-Nov-24 03:42 UTC
[Speex-dev] Blackfin port on Visual DSP, Michael Shatz ?
> Well, actually, I found-out that the stdio lib can access my PC file-system > through the JTAG interface. > So I can eventually try this.Would be a good thing to try if you want to rule out a bug in your code.>> Hmm... let me investigate a bit further. >> You mean you disabled blackfin assembly optimisations? Do you >> see the same results on a PC. I suspect it could be an >> uninitialised memory problem somewhere. > > Yes, I currently have no ASM optimizations, it's the standard FIXED_POINT > code. > I didn't test on PC linux/win32, as other users have no trouble on these > platform.That could also help identify bugs -- especially if you can run your code within valgrind.> I looked at the sources and discovered the different temp-memory allocation > schemes. > After compiling with VAR_ARRAYS, it's better with revision 12173. > -> working for 2-3 VoIP calls (init & destroy for each call) > -> not working again for next callsLooks like something is uninitialised.> With lastest revision from SVN, sometimes it only worked once. > Now it's not working anymore. > > *** WITH preprocessor initialized and called (but nothing activated in it) > *** > -> same as echo-canceller, it's working.Looks like something is uninitialised.> So I think you are right on the memory init problem. > > Do you think it comes from my run-time libraries ? > Or is it a mistake in Speex ?>From most likely to least likely:1) An bug in your test code 2) A problem with your run-time 3) A bug in Speex Note that if you have overridden the speex_alloc() function you MUST replace it by something that frees the memory (calloc) otherwise Speex will not work.>>> - 'dynamic' labels are not available on VDSP (when you use >> an inline >>> several times, the gcc compiler can do some kind of incrementation) >> What would you use instead? > > hehe, that's where I have trouble. > No documentation on how to do this... > I guess I will have to use PC-relative addressing-mode and compute the > offset myself.Yuck! How many functions are affected (maybe they can be disabled or something?). Also, try and find if there's a way to generate these dynamic labels. I can't believe they hadn't thought of the problem.> -> This would compile also on the GCC.But would be hard to maintain and error prone.> Alternatively and because only some functions are used several times, > and AFAIR it's mainly the divisions, > I can handle this with 3 solutions: > - just use the standard syntax to let the compiler use its library. > - use built-in functions (can also do this for MUL/MAC functions)What do you mean?> - for bigger functions, just de-inline them !Not an option, I don't want to have functions that are inline for one arch and not on other archs. That's a recipe for problems. Jean-Marc