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: 5161
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: 5161
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
bryant
post Jan 10 2012, 07:49
Post #6


WavPack Developer


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



QUOTE (okey @ Jan 9 2012, 18:56) *
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.

WavPack is not particularly efficient at encoding small block sizes because of the relatively large headers required, and those two buffer sizes determine the largest blocks that can be created with the tiny encoder. Therefore, you want to make those as large as your system allows, but they can certainly be much smaller than the 64K default. The headers are in the 100-byte or so range, so if you could only afford 10K of buffer, then you would still only be losing about 1% efficiency because of the small blocks.

Obviously if you made them really small (like 1K) then you would start losing significant compression (but it still should work even at that size).

BTW, thanks saratoga! smile.gif

edit: typo

This post has been edited by bryant: Jan 10 2012, 07:50
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: 25th December 2014 - 06:34