[maemo-developers] DSP SBC encoder update

[From: Simon Pickering]

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

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.

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 :(

Brad (Midgley) was talking earlier about implementing zero-copy; this would
be good as then at least some of the data could be left in the SARAM
input/output arrays (both faster because these are SARAM and because it
doesn't need a copy). I'll have a look at this.

So onto trying to optimise the inner loop...

Cheers,


Simon