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...

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.

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.

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.

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.

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).

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).

Ah. By "too small", I mean I tried making them 256 bytes. The results of which now make perfect sense when considering the header size. Thanks very much for the explanation.