[tremor] Start up time / overhead

[Monty]

On Wed, Sep 18, 2002 at 03:43:04PM +0100, David Hembrow wrote:

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

Our encoder, for any selected mode and input type (that is, if you
keep the sample rate, channels and passed in paramteres the same),
will use the same setup header.  If the samples are all short and all
using the same parameters, you can store them as raw, headerless files
and just store the header once somewhere.

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

Following the above scheme, you would not need to tear down/restart
the decoder for each sample.  Just keep feeding packets and it will
keep playing back.

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

Transform codecs, honestly, are not ideal for speech and sibilance
suffers first. 

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

We're happy to take patches that increase portability.  For ARM,
however, modern GCC is way ahead of MSVC.  If performance is important
you won't easily beat GCC.  In some places, we've already removed
patches of assembly as GCC produced equal or better code.

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