Speex dev - Aug 2004 - @Christian Buchner: speex acm & netmeeting

Christian Buchner wrote:
> Thanks for your hacked up instcodec source code. I installed the 16.8
> kbit/s 16kHz Q5 mode and it worked instantly. It offers a pretty decent
> and clear sound quality.
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.

D A

<p>--- >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@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

> As you can see Q4 and Q5 are good candidates providing one
> frame per block at rates of 12800 and 16800 bits/sec.
> SO I'll try the 16kHz modes next, as they should really be an 
> improvement to quality and clarity. I'll sort out the sources now and 
> mail them to you.
Thanks for your hacked up instcodec source code. I installed the 16.8
kbit/s 16kHz Q5 mode and it worked instantly. It offers a pretty decent
and clear sound quality.

I was only doing some testing from one PC to another on my home LAN
and so far I am impressed.

Christian

--- >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@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

> 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@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.