search for: speex_alloc_scratch

...d to the kludge of declaring global variables, which I initialize based on the allocated memory blocks. My alloc routines then look at the global variables, similar to the way calloc works. This does not solve the problem of distinguishing persistent and scratch storage. To do this, I added a speex_alloc_scratch routine, which uses a different memory block than speex_alloc. This does force a change to nb_encoder_init, etc. At the moment, the code looks like this: #if defined(VAR_ARRAYS) || defined (USE_ALLOCA) st = (EncState*)speex_alloc(sizeof(EncState)); if (!st) return NULL; st->s...

...ind that the data footprint in the lastest versions is >pretty small. There's a bit more code/tables, but you'll find that many >can go away if you're not actually using them. Yes, data footprint in the new version is quite manageable. Still I would wish better documentation for speex_alloc_scratch(). It took me time to figure out that in single-threaded environment I could give the same scratch area to multiple encoders end decoders. It would be also very useful to document the size of the scratch area as the function of mode. By the process of trial and error I found out that in my mode sc...

...tephane Lesage > Cc : speex-dev at xiph.org > Objet : Re: [Speex-dev] Resampler saturation, blackfin performance > > - are there buffers who could be placed in scratch memory ? > > (I don't see any speex_scratch_alloc inthere) > > I don't understand your question. speex_alloc_scratch() is used only in nb_celp.c, and sb_celp.c re-uses the stack from the nb en/de-coder. But the echo-canceller and preprocessor don't use it. I suppose they also have some scratch buffers. (comments in SpeexEchoState_ structure mdf.c) But you allocate them with speex_alloc instead of using the...

...a c55-specific function that allocates enough memory for everything and then overload speex_alloc to return pointers to that area (in a way similar to the way my pseudo-stack works). > This does not solve the problem of distinguishing persistent and scratch > storage. To do this, I added a speex_alloc_scratch routine, which uses a > different memory block than speex_alloc. This does force a change to > nb_encoder_init, etc. At the moment, the code looks like this: I'm not sure how your environment defines scratch space. What's the difference? > Note that I also moved the "if...

Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: maleout12may.wav Type: audio/wav Size: 95884 bytes Desc: not available Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20050524/57112d0c/maleout12may-0001.bin

I'm only using the narrow-band encoder on my embedded system and have removed all references to the wide-band and ultra-wide band encoder functions and tables. They will be pulled in by the linker due to the references made by the structures in modes.c. Attached is a replacement modes.c for compiling out modes that are not in use for anyone who's interested. Also, I've removed the

...y when the input buffers > are placed > > in MyDecoderClass. > > There's actually a much simpler way of making everything > contiguous. All you need to do is allocate (or reserve or > whatever) a big block yourself and override speex_alloc() and > speex_free() (and speex_alloc_scratch if you don't have a C99 > compiler) to distribute that memory explicitly. I completely understand that it's possible to override speex_alloc() and speex_free(), in fact that's what i've done. However, how much memory do I reserve? Without running the code I would like it to b...

...lin@usherbrooke.ca] Sent: Tuesday, June 19, 2007 6:38 PM To: Michael Shatz Cc: speex-dev@xiph.org Subject: Re: [Speex-dev] Blackfin inline assembler and VisualDSP++ toolchain >> Yes, data footprint in the new version is quite manageable. Still I would >> wish better documentation for speex_alloc_scratch(). > >I'll be waiting for your patch :-) I didn't realize that you accept patches for documentation, too. > >> It took me time to >> figure out that in single-threaded environment I could give the same scratch >> area to multiple encoders end decoders. It woul...