Tiny Decoder *read_stream implementation, How to use the tiny decoder on embedded hardware Options

[TinyTron]

Hi there,

I'm trying to implement a WavPack decoder on embedded hardware using a ARM Cortex-M3 hardware.
The code I use is from the Tiny Decoder package from the downloads page, version is 4.40. I'm using the C-version, no assembler code is used.

The wavpack file is on a FAT formatted SD-Card, I'm able to read both the SD card blockwise, as well as the FAT-system blockwise. Blocks are 512 bytes wide.
My implementation is incompatible to the format of the read_stream, so I try to implement a "translator" function.

I'm not sure, if I get it right:

CODE

typedef int32_t (*read_stream)(void *, int32_t);

This implements the stream access - I assume, my function has to return a int32-value of how many bytes it could read and write the bytes to a buffer, void* points to (should it be a char*), the number of bytes that should be read is passed to the function as int32_t?

Has anyone tried to get the decoder running on an ARM processor?
Is there a port of the assembler part to thumb2-instructions?

Thanks in advance!

Best regards
TinyTron

[saratoga]

I'm trying to implement a WavPack decoder on embedded hardware using a ARM Cortex-M3 hardware.

Thats an interesting choice. Why such an odd ARM processor?

The wavpack file is on a FAT formatted SD-Card, I'm able to read both the SD card blockwise, as well as the FAT-system blockwise. Blocks are 512 bytes wide.
My implementation is incompatible to the format of the read_stream, so I try to implement a "translator" function.

So you want to do something like we do in rockbox, where the file is streamed a few KB at a time from storage, decode it, then do the next few KB? Heres our code:

http://svn.rockbox.org/viewvc.cgi/trunk/ap...amp;view=markup
http://svn.rockbox.org/viewvc.cgi/trunk/ap...ecs/libwavpack/

Has anyone tried to get the decoder running on an ARM processor?
Is there a port of the assembler part to thumb2-instructions?

I've never heard of someone using the Thumb2 processors for audio, but I think its not too different from standard ARMv4, so you could probably adapt our assembly.