This thread sure is getting long. I've just searched all through it to see whether the info I'm interested in is available, and I couldn't see it, my apologies if I've missed it.

I see that there was mention of performing the audio decoding using the ARM and the video decoding using the DSP, but that this was excluded because of the picky nature of the video DSP plugins. My question is basically the following: how would the audio and video ideally be split (assuming someone puts the effort in to write the DSP video decoders, etc.)?

I presume that the DSP is not running at 100% just decoding the audio, and that video decoding would almost certainly cause it to run at a higher load, and I also assume that the speed increase in using the DSP rather than the ARM to decode the video is greater than using the DSP rather than the ARM to decode the audio (I hope that makes sense). I may be wrong about this..? This does assume that either the DSP or ARM carries out all of the processing for either the audio/video, though splitting the larger of the two tasks between the two parts of the chip may be another option. It also assumes that both the DSP and ARM have equal memory bandwidth to the display, and this may not be the case, and would therefore influence the choice of video decoding.

I'd be interested to see CPU/DSP load figures and hear other people's thoughts about this.

Cheers,


Si