So, to clear up the confusion re NEON instructions, these are an extension of the main CPU instruction set (actually handled by a coprocessor iirc, like the VFP instructions) which perform some SIMD operations.

The DSP is a separate chip, with its own compiler and assembly language and indeed its own kernel (that runs on the DSP and performs IO access, multi-tasking of DSP threads, etc.)

So, there is an obvious advantage that the DSP can run in parallel with the CPU. That's the first thing.

The second, and the reason you have a DSP rather than another CPU is that the DSP is optimised for arithmetic operations in various ways. It can perform SIMD, efficient MAC (both in terms of time and power), the instructions generally inform you if they have had problems (e.g. overflow, underflow) so that explicit checks do not need to be coded in-line.

Another advantage of the DSP is the speed of the memory that it can access and the number of cycles required to access said memory.

I should say that I've not done any DSP programming for the C6x which we have in the N900/beagleboard, as I've been too busy, but I can comment on the disadvantages of the C55 which we had in the N8x0 and say how things have improved with the C6x which we have in the N900.

With the C55 there was no 8bit type (i.e. a char was 16bits wide) which made porting code a real pita. Thankfully the C6x does have an 8bit type which should make things much easier.

My understanding is that the DSP bridge (which is a Linux kernel side link to the DSP's own kernel, and allows data and object code to be passed back and forward) is also nicer to use now than the DSPgateway we used to use on the N8x0.

Not normally floating point, but certainly fixed point. In fact many DSPs (C55 in the N8x0 and I think the C6x in our N900s included) don't have fp hardware anyway so it's all done using fixed point.

Yes it can be, however how this is done may be troublesome.

The DSP runs a multitasking kernel (which is separate to the Linux kernel) and includes an MMU. Data transfer is carried out by mapping shared memory on both the DSP and CPU sides (this was done by the DSP gateway kernel-side code.)

On the 770 the DSP was used to decode video and on the N8x0 it was used only for audio decoding. With the N900 we're back to using the DSP for video.

I ported the SBC codec to the C55 DSP on the N8x0 in the hope that it would offload some CPU load and allow better quality movies to be played in mplayer while using A2DP headphones (the next step being to implement an mp3->PCM decoder that could keep the PCM data on the DSP rather than passing it back to the CPU via the shared memory buffer), but this was not to be.

While the Nokia supplied DSP kernel included an audio hw codec driver, no api docs were available so we would have had to have rewritten the audio hw codec driver and replace the kernel in order to directly output audio from the DSP (not the end of the world, but it would stop the existing mp3, aac decoders, etc., from working). Therefore I used the shared memory buffer to both pass PCM data to the DSP and retrieve it from the DSP. It worked, but some sort of memory contention issue stopped it from being used with mplayer playing video files at the same time.

So yes, you may have troubles. I'm afraid that I don't know how the N900's DSP outputs video data, whether it's passed back to a shared framebuffer or output directly.

Anything repetitive basically, I don't know about the internals of file compression offhand and would have to sit down and look at some pseudocode to decide either way.

Yes there are tools for the N900 which were originally here: http://omapzoom.org/wiki/DSPBridge_Project

There's a wiki page called "DSP Programming" on wiki.maemo.org with links for the N8x0 tools.

Actually there is resource handling and multitasking, so it might work (quickly enough).

HTH