[tremor] Start up time / overhead

[David Hembrow]

I've been evaluating Tremor with an interest in using it within our products. We produce signs which show the arrival times of
public transport, blind people have keyfobs which cause the sign to speak the arrival times.

Until now, I've been using an 11kHz 4 bits/sample ADPCM scheme, 44kb/s. We can optionally use 8kHz, giving 32kb/s (but not very good
quality).

We're using an Atmel ARM7TDMI part, which we were clocking at 14MHz. I've found it possible to get Vorbis to decode in real time if
I increase the clock (which I can do from software) to 22MHz, and decrease the oversampling rate (this is also software) to 2x, but
only if I produce the samples using options to oggenc to keep the data rate very low:

        oggenc -b8 --resample 8000 file.wav

This typically encodes to around 10kb/s.

The problems I have encountered are as follows:

1. There is considerable overhead in the format, and our samples are short
   (individual words which the software puts together). As a result, the
   output file size is such that the bit rate works out on average as
   effectively more like 28kb/s. Is there a way of reducing the size of
   this overhead ?

2. There is also a time overhead in that the samples take a considerable
   time to start playing. As our software has to speak many samples back
   to back, this produces un-natural pauses between words. Is there a way
   of decreasing this start up time overhead per sample ?

3. In comparison with 11kHz ADPCM, any 8kHz format sounds lacking due to
   the lack of sibilance. If I specify --resample 11025, oggenc requires
   that I increase the -b argument to 12, and produces around 16kb/s
   output. The resulting file is too time consuming for our slow processor
   to decode in real time. Absolute sound quality is not nearly as important
   to us as file size and decoding speed, but is there a way of encoding
   vorbis so that I preserve the sibilance without increasing decoding time
   or output file size ?

Also, I am using the ARM ADS v1.1. I have converted the inline assembler
routines in arm_arm.h to compile with the inline assembler of the ADS.
I have seen discussion of using MSVC with this header file, and suspect
that what I have now is likely to be more similar to what MSVC would
require. I can contribute this if it is wanted.

Many thanks,

David.

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'tremor-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.