> Aren't most of the existing plugins just developer toys? ;-)
> (Just kidding!)

Offense taken.

> From what you're writing it seems to me that you already did some
> testing with the codec. Is that right? What are the results?

No, I didn't, only read the datasheet.

> > A similar problem exists for the disk I/O, here we have to endian swap
> byte
> > pairs. Archos unfortunately wired the 16 bit data bus directly 1:1, not
> > taking into account that IDE is little endian and the SH CPU is big
> endian.
>
> Isn't there the same problem when playing/recording MP3 data? Or does
> the built-in MP3 codec take care of this?

Yes, and that's a reason to tackle both at once: squeeze the bitswap to the
output stage, buffer the data as-is.

> I don't think that my idea is too bad at all, since e.g. the video
> plugin does in a way exactly the same (processing data that cannot be
> handled by the Rockbox CPU simply outside of the unit.)

Don't tell me, I wrote that plugin and the authoring procedure. Not many
people (or nobody?) is using that seriously, for good reason.

> I just think that the goal shouldn't
> be set too high for the start and that the code can be improved once the
> basic things are running.

True, I was talking about the far end goal, or what I would view as my goal.

Jörg

-- 
DSL-Aktion wegen großer Nachfrage bis 28.2.2006 verlängert:
GMX DSL-Flatrate 1 Jahr kostenlos* http://www.gmx.net/de/go/dsl