[Tremor] Implementing Tremor on low-end ARM

[Ethan Bordeaux]

Hi Nicholas - this is all very interesting.  I have a similar need to remove
the dynamic memory allocation with static allocations for my application.
Please keep us in the loop on your explorations!

Also, if some of the more experienced Tremor users/developers could chime in
here on maximum allocations for various parts of the codec I would really
appreciate it.  I only need to worry about signals up to 2 channels which
seems like it will simplify some of the allocations and let them easily
resolve to a reasonable fixed value but other allocations it's not quite so
clear what the limit is.  Nicholas, are you planning on limiting your system
to mono or stereo Ogg Vorbis files?

Lastly on memory usage, can someone comment on the "LIMIT_TO_64kHz" #define
in a few places of the code?  It removes the largest window which saves some
memory, but this causes the codec to fail on decodes of highly compressed
audio files right?  What are the circumstances it is safe to enable this
switch?

Ethan

On Sun, Nov 23, 2008 at 11:36 AM, Nicholas Vinen <hb at x256.org> wrote:

> Replying to myself again.
>
> Well, I've done some further investigations into Tremor's memory
> allocation. I have redirected each different call to
> malloc/calloc/realloc/free into a separate function. I've also set it up
> so that I can just change one #define and it will redirect them all back
> to the standard allocation functions. Thus this could possibly become a
> standard part of Tremor (if people feel it's worthwhile). The idea is
> that I can (a) see what's being allocated where and how much and (b)
> theoretically write different allocation functions for each type of
> buffer required.
>
> The more I think about this the more I think that I will be able to get
> away with dedicating a certain portion of memory to certain things (data
> buffers, "dectable", code books, etc.) and just split up this memory
> into chunks as required by Tremor. i.e. it will allocate them all in one
> go, then probably free them all when playback is finished, so there's no
> need for any kind of intelligent allocation. Some other things may be
> more dynamic but this could be handled by giving them "large enough"
> chunks (possibly more than they ask for) in order to cover the maximum
> that will be asked for.
>
> If/when I come up with a sensible static memory allocation strategy I'll
> report on it. For now here is what the allocations look like for playing
> back what I would consider a fairly ordinary Ogg Vorbis file. I note
> that it seems to be allocating an awfully large numer of buffers - I
> wonder if this could be reduced somewhat?
>
> _ogg_calloc_sync 28
> _ogg_calloc_bufstate 16
> _ogg_calloc_stream 76
> _ogg_malloc_buffer 16
> _ogg_malloc_bufdata 1024
> _ogg_malloc_ref 16
> _ogg_malloc_ref 16
> _ogg_malloc_ref 16
> _ogg_calloc_info 52
> _ogg_malloc_buffer 16
> _ogg_malloc_bufdata 1024
> _ogg_malloc_buffer 16
> _ogg_malloc_bufdata 1024
> _ogg_malloc_buffer 16
> _ogg_malloc_bufdata 1024
> _ogg_malloc_ref 16
> _ogg_malloc_ref 16
> _ogg_malloc_ref 16
> _ogg_malloc_ref 16
> _ogg_calloc_vendor 30
> _ogg_calloc_comments 20
> _ogg_calloc_commentlens 20
> _ogg_calloc_comments2 12
> _ogg_calloc_comments2 12
> _ogg_calloc_comments2 28
> _ogg_calloc_comments2 15
> _ogg_calloc_bookparam 2816
> _ogg_malloc_dectable 14
> _ogg_malloc_dectable 126
> _ogg_malloc_dectable 126
> _ogg_malloc_dectable 508
> _ogg_malloc_dectable 62
> _ogg_malloc_dectable 380
> _ogg_malloc_dectable 32
> _ogg_malloc_dectable 62
> _ogg_malloc_dectable 308
> _ogg_malloc_dectable 32
> _ogg_malloc_dectable 62
> _ogg_malloc_dectable 308
> _ogg_malloc_dectable 30
> _ogg_malloc_dectable 14
> _ogg_malloc_dectable 1020
> _ogg_malloc_dectable 126
> _ogg_malloc_dectable 508
> _ogg_malloc_dectable 62
> _ogg_malloc_dectable 380
> _ogg_malloc_dectable 62
> _ogg_malloc_dectable 380
> _ogg_malloc_dectable 32
> _ogg_malloc_dectable 62
> _ogg_malloc_dectable 308
> _ogg_malloc_dectable 32
> _ogg_malloc_dectable 62
> _ogg_malloc_dectable 308
> _ogg_malloc_dectable 198
> _ogg_malloc_dectable 192
> _ogg_malloc_dectable 1440
> _ogg_malloc_dectable 200
> _ogg_malloc_dectable 528
> _ogg_malloc_dectable 320
> _ogg_malloc_dectable 480
> _ogg_malloc_dectable 344
> _ogg_malloc_dectable 48
> _ogg_malloc_dectable 672
> _ogg_malloc_dectable 480
> _ogg_malloc_dectable 896
> _ogg_malloc_dectable 1760
> _ogg_malloc_dectable 672
> _ogg_malloc_dectable 672
> _ogg_malloc_dectable 96
> _ogg_malloc_dectable 198
> _ogg_malloc_floorparam 8
> _ogg_malloc_floortype 2
> _ogg_calloc_floor1 36
> _ogg_malloc_partition 6
> _ogg_malloc_class 44
> _ogg_malloc_postlist 38
> _ogg_malloc_fwdindex 19
> _ogg_malloc_loneighbor 17
> _ogg_malloc_hineighbor 17
> _ogg_malloc_fwdindex 19
> _ogg_free_fwdindex
> _ogg_calloc_floor1 36
> _ogg_malloc_partition 8
> _ogg_malloc_class 55
> _ogg_malloc_postlist 58
> _ogg_malloc_fwdindex 29
> _ogg_malloc_loneighbor 27
> _ogg_malloc_hineighbor 27
> _ogg_malloc_fwdindex 29
> _ogg_free_fwdindex
> _ogg_malloc_residueparam 56
> _ogg_malloc_stagemasks 10
> _ogg_malloc_stagebooks 80
> _ogg_malloc_stagemasks 10
> _ogg_malloc_stagebooks 80
> _ogg_malloc_mapparam 40
> _ogg_malloc_coupling 2
> _ogg_malloc_submaplist 2
> _ogg_malloc_coupling 2
> _ogg_malloc_submaplist 2
> _ogg_malloc_modeparam 4
> _ogg_malloc_offsets 16
> _ogg_malloc_serialnos 4
> _ogg_malloc_dataoffsets 8
> _ogg_malloc_pcmlens 16
> _ogg_malloc_buffer 16
> _ogg_malloc_bufdata 1024
> _ogg_malloc_ref 16
> _ogg_calloc_stream 76
> _ogg_free_stream
> title=Donna
> artist=10cc
> album=The Very Best of 10cc
> tracknumber=01
>
> Bitstream is 2 channel, 44100Hz
>
> Decoded length: 7776300 samples
> Encoded by: Xiph.Org libVorbis I 20050304
>
> _ogg_calloc_dspstate 76
> _ogg_malloc_dsp_work 8
> _ogg_malloc_dsp_mdct 8
> _ogg_calloc_dsp_work2 4096
> _ogg_calloc_dsp_mdct2 2048
> _ogg_calloc_dsp_work2 4096
> _ogg_calloc_dsp_mdct2 2048
> Playing raw data 'stdin' : Signed 16 bit Little Endian, Rate 44100 Hz,
> Stereo
> _ogg_malloc_buffer 16
> _ogg_malloc_bufdata 1024
> _ogg_malloc_ref 16
> _ogg_malloc_ref 16
>
> Aborted by signal Interrupt...
>
>
> _______________________________________________
> Tremor mailing list
> Tremor at xiph.org
> http://lists.xiph.org/mailman/listinfo/tremor
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/tremor/attachments/20081124/cb964cec/attachment.htm