[maemo-developers] dsp-sbc and video output problems

[From: Simon Pickering]

Hi everyone,

As at least some of you know, the dsp-sbc task works (for all the  
music I've tried anyway, but I know there are some oddities, which I'm  
going to investigate - e.g. qwerty's music ;).

This is all well and good, but we don't gain much, except possibly  
better battery life if we scale the CPU speed right back while we  
decode (and even then I don't know if it will be more efficient). The  
goal had been to offload sbc encoding to the DSP to allow e.g. mplayer  
to use more cpu to do video decoding.

I and others have done some testing with the dsp task, and with the  
cpu at 400MHz, although the sbc encoding works fine, the video  
stutters quite severely (producing <1fps output). This is obviously  
not workable, so it needs fixing if possible.

I've converted the existing task, which uses bulk transfers (where the  
copying is done in the kernel) to use shared memory and word transfers  
for synchronisation. This should cut the amount of time the kernel  
spends doing memory copying by some significant margin (i.e. ~4 bytes  
data copied rather than 512+78 bytes per transfer, of which there are  
375/sec). This hasn't improved things though, the video is still at  
<1fps.

Before I look at DMA or other exotics, I thought I'd ask if anyone  
knows about the bandwidth limitations of the memory controller/memory?

The dsp mp3 task which works with mplayer while displaying video  
consumes (not quite sure how to work out exact bitrate here), let us  
say a 5Mb file in 3min or so, which gives 28.4kb/sec (kilobytes that  
is).

My sbc encoder eats 48000hz stereo 16bit data, which equates to  
187.5kb/sec input. It also spits out 78 bytes for every 512 bytes it  
reads in, which adds an extra 28.5kb/sec to the total bandwidth  
requirement.

So, am I running up against a fundamental limitation of the memory  
architecture?

Cheers,


Simon