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

[bryant]

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?

Yes, I think your understanding is correct. The only thing is that the stream reader function MUST read the number of bytes requested (and return that number) unless the stream is exhausted (i.e., EOF). If your "translator" function can only read 512 bytes from the filesystem at a time, then it will need to maintain a 512 byte buffer to hold any leftover bytes between calls from the tiny decoder.

BTW, the read_stream() function is almost identical to the standard Posix read() except that no file descriptor is passed in.

The ARM assembly routines provide some improvement in performance, but it's not huge (maybe 30% faster) and so it's quite likely that the C version will work fine for you unless you have some unfortunate combination of very high sampling rate and low CPU clock speed.

Please feel free to let me know if you run into any trouble or have other questions!

David