[speex-dev] @Christian Buchner: speex acm & netmeeting

[Christian Buchner]

> Nice to hear! Do sou think you will be able to make the other modes also 
> compatible? But I guess these working modes are already OK for 
> netmeeting. I will try the Q4 16kHz mode today.

Low bitrate was the design goal, not Netmeeting compatibility ;)

Padding loss occurs because Speex encodes frames that do not end on
byte boundaries. If you force each Speex frame to be byte aligned
you get significant padding loss (up to 7 unused bits per frame).
And that is bad because it drives your bitrate up.

I used a C program to determine good bit packing for each mode. This
was able to ensure that bit padding loss is less than 1/1000th of
the total bitrate for all available modes in the codec.

In some low quality modes I was able to save 10% in bitrate. This
came at a price though. Grouping several speex frames into one block
makes it more difficult to use the ACM for low latency applications
like Netmeeting.

So if the ACM combines 8 Speex frames into a block (or packet) then
you need to encode these 8 frames before you can send off the packet.
Each frame has 20 ms duration, so you have to wait 160 ms before you
can encode a packet and send it off. 320 ms roundtrip delay is bad
for a phone conversation - especially in a heavy argument! ;)

Netmeeting may be unable to buffer enough samples to begin encoding
of such a long packet (limited sample buffers). That may be why you
received invalid/garbled data when you first tried that.

It may be worthwile to try the higher quality modes also (those which
pack 2 frames into a packet). Netmeeting may be able to handle that
just fine.

--- >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 'speex-dev-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.