IPB

Welcome Guest ( Log In | Register )

Tiny Decoder *read_stream implementation, How to use the tiny decoder on embedded hardware
TinyTron
post May 2 2011, 15:47
Post #1





Group: Validating
Posts: 2
Joined: 2-May 11
Member No.: 90268



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
Go to the top of the page
+Quote Post
 
Start new topic
Replies
bryant
post May 3 2011, 18:04
Post #2


WavPack Developer


Group: Developer (Donating)
Posts: 1291
Joined: 3-January 02
From: San Francisco CA
Member No.: 900



QUOTE (TinyTron @ May 2 2011, 07:47) *
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! smile.gif

David

Go to the top of the page
+Quote Post

Posts in this topic


Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 28th August 2014 - 14:32