IPB

Welcome Guest ( Log In | Register )

Any suggestions on minimising tiny encoderís heap usage on ARM7?
okey
post Jan 10 2012, 00:46
Post #1





Group: Members
Posts: 4
Joined: 10-January 12
Member No.: 96332



I'm working with an LPC2387 chip (72MHz) and a quite limited amount of RAM, and I need to run tinyencoder on it. 'As is', the malloc calls to create buffer space in pack_audio() (in tinypack.c) fail, because there isn't enough heap space. Any suggestions to reduce the heap footprint as much as possible?

The audio data I'm working with is 8KHz 16-bit, and I'm using the TinyEncoder source from the Wavpack download page. I suspect I may be going about this the wrong way since the readme says there is no malloc/free usage...
Go to the top of the page
+Quote Post
 
Start new topic
Replies
saratoga
post Jan 10 2012, 00:56
Post #2





Group: Members
Posts: 5119
Joined: 2-September 02
Member No.: 3264



QUOTE (okey @ Jan 9 2012, 18:46) *
I'm working with an LPC2387 chip (72MHz) and a quite limited amount of RAM, and I need to run tinyencoder on it.


How much RAM?

QUOTE (okey @ Jan 9 2012, 18:46) *
'As is', the malloc calls to create buffer space in pack_audio() (in tinypack.c) fail, because there isn't enough heap space. Any suggestions to reduce the heap footprint as much as possible?

The audio data I'm working with is 8KHz 16-bit, and I'm using the TinyEncoder source from the Wavpack download page. I suspect I may be going about this the wrong way since the readme says there is no malloc/free usage...


tinypack.c isn't part of the decoder. Its the example program showing you how to use the library. It mallocs some large buffers to hold the input data. If you don't have that much RAM, either don't use the example program (since you probably don't want to actually run it on your device...) or process from smaller buffers.
Go to the top of the page
+Quote Post
okey
post Jan 10 2012, 01:22
Post #3





Group: Members
Posts: 4
Joined: 10-January 12
Member No.: 96332



QUOTE (saratoga @ Jan 10 2012, 11:56) *
How much RAM?

64KiB. Much of which (~36-40KiB) is needed elsewhere.
QUOTE (saratoga @ Jan 10 2012, 11:56) *
tinypack.c isn't part of the decoder. Its the example program showing you how to use the library. It mallocs some large buffers to hold the input data. If you don't have that much RAM, either don't use the example program (since you probably don't want to actually run it on your device...) or process from smaller buffers.

Thanks. That's pretty much what I needed to know. I had arrived at the conclusion that some of it was intended as an example, but due to some spectacular mental failure I failed to realise that all of was intended as such. Duh.
Go to the top of the page
+Quote Post
saratoga
post Jan 10 2012, 01:27
Post #4





Group: Members
Posts: 5119
Joined: 2-September 02
Member No.: 3264



QUOTE (okey @ Jan 9 2012, 19:22) *
QUOTE (saratoga @ Jan 10 2012, 11:56) *
How much RAM?

64KiB. Much of which (~36-40KiB) is needed elsewhere.


Looking at the rockbox version:

http://www.rockbox.org/wiki/pub/Main/Codec...1_SansaClip.png

You need about 64KB not counting in/out buffers on ARMv4, roughly 40% of which is code space. If you can put the code segments in a ROM or other memory, you might be able to make this work.
Go to the top of the page
+Quote Post
okey
post Jan 10 2012, 02:56
Post #5





Group: Members
Posts: 4
Joined: 10-January 12
Member No.: 96332



QUOTE (saratoga @ Jan 10 2012, 12:27) *
Looking at the rockbox version:

http://www.rockbox.org/wiki/pub/Main/Codec...1_SansaClip.png

You need about 64KB not counting in/out buffers on ARMv4, roughly 40% of which is code space. If you can put the code segments in a ROM or other memory, you might be able to make this work.

Cheers. As it happens, I have just done exactly that - shoved the code segments into a ROM and managed to squeeze everything else in. Re-arranged some other bits and pieces so that I can reuse another pair of buffers here. At this stage it appears to work (I'm still testing...).

Is there some (non-trivial) point at which the wv and wvc buffer size (wputils.c) gets too small for proper compression, even when not using hybrid mode? I have observed that it does not compress properly for quite small sizes. Of course, I could just be screwing up again.
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: 27th November 2014 - 01:21