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 _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
