[maemo-developers] DSP SBC encoder update

[From: Simon Pickering]

> >> Do you use any buffers allocated by malloc? My guess is that malloc
> >> does allocation of DARAM and SARAM memory.
> >> In any case, memory returned by malloc should be not worse than the
> >> memory buffer explicitly statically placed to EXTMEM.
> >
> > Yes, I think you're right, in the avs_kernelcfg.cmd file it talks
about a
> > DARAM_heap and a SARAM_heap, presumably it's possible to allocate
from
> > either somehow (using the CSL MEM_* calls probably, I don't know off
hand
> > which heap is used for task data, but will have a look this
evening). It
> > also talks about a/the stack being in SARAM.
> 
> I'm sorry if it was not clear enough. Just use normal malloc from C
library 
> without any CSL_MEM_* stuff. You can add some debugging prints for the
addresses
> of allocated blocks and identify what kind of memory they are actually
in (DARAM,
> SARAM, SDRAM). By the way, this information is especially important if
you want
> to use DMA, as you need specifically configure the type of memory (not
just
> address) when setting up DMA transfer.

No, I understood, I was just mentioning that there appear to be two
heaps to chose from - presumably one is used by the DSP tasks (malloc is
probably #defined as one of the CSL MEM* fns in the DSP Gateway task
functions).

> > Over lunch I had a play with the things I talked about in my last
email.
> > Removing the memcpy (from the slow SDRAM X[] array to the fast SARAM
> > fast_in[] array) made the code marginally slower - at least there
were more
> > drop outs, so it appears that the memcpy() overhead is less than the
extra
> > time needed to access the data in SDRAM.
> 
> Yes, accessing SDRAM memory is extremely slow. And if you access SDRAM
> memory using 16-bit accesses instead of 32-bit accesses, the overhead
> doubles. So if your data processing algorithm does not deal
exclusively
> with 32-bit data accesses, you are better not to run it to process
data
> in SDRAM memory. Copying data to a temporary buffer in DARAM or
> SARAM, processing it there and copying results back to SDRAM would be
> faster in this case.

The X[] array data type is an int32, so even accessing 32bit from SDRAM
is still slower than using a local buffer (depending on what you need to
do with it of course).

> > I shaved a few array elements off the output[] SARAM array (down
from 100 to
> > 78 elements, this fits the current Bluez encoder parameters, but if
they
> > were changed upwards, both the input[] and output[] arrays would
probably
> > need to be made bigger). I also removed the #PRAGMAs I had been
using to
> > place the const data from sbc_tables.h in SARAM as from looking the
> > avs_kernelcfg.cmd file, .const data is already placed in SARAM
(SARAM_DATA
> > section) and I thought this might free up some room to fit the X[]
array in
> > SARAM directly. It didn't. Moving the const tables freed 72x32bits,
removing
> > the fast_in[] array (not needed if X[] itself is fast) freed
80x32bits, but
> > the X[] array requires 2x160x32bits. It still doesn't fit :(
> 
> 2x160x32 bits is only 1280 bytes, which is hardly too big. Try to
allocate 
> buffers with malloc and copy constant tables there on initialization.

It know there's not much free SARAM memory (note that the DSP Gateway
kernel also appears to hold the majority of its data in the DSP internal
memory). But parts of the SARAM and DARAM are reserved for the stack and
heaps, which may well have free space on them. It appears that 0xc00
(8bit) bytes are reserved for the stack, the DARAM heap is 0xbf40 bytes
in size and the SARAM heap is 0xd000 bytes long. So this may mean that
there's enough space in the SARAM if I use malloc to get the memory from
the heap. I had thought that the heap would be fairly small so I was
#PRAGMAing my large structures to be placed in SDRAM; this was probably
the wrong thing to do.

I'll test and report back.

Cheers,


Simon