[maemo-developers] DSP SBC encoder update

[From: Siarhei Siamashka]

On Thu, Jul 10, 2008 at 5:09 PM, Simon Pickering
<S.G.Pickering at bath.ac.uk> wrote:
>> > I looked at this yesterday evening (thanks to derf, crashanddie, and
> others
>> > for answering my C questions), trying to move some parts of the priv
>> > structure to SARAM (sorry for the SRAM typo above). Unfortunately just
>> > moving the bare minimum (the X array) won't happen as there's not enough
>> > SARAM (so dsp_dld tells me). I don't know where it's all gone, anyone
> have
>> > any ideas?
>>
>> 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.

> To answer the question, only if the thing to be malloc'd is small. In this
> case it's only a couple of structures (and they are large), so I've manually
> created them in EXTMEM2. I know this is not ideal, but they won't fit in
> SARAM.
>
> 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.

> 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.