Codec2 — an Open Source, Low-Bandwidth Voice Codec

Bruce Perens writes "Codec2 is an Open Source digital voice codec for low-bandwidth applications, in its first Alpha release. Currently it can encode 3.75 seconds of clear speech in 1050 bytes, and there are opportunities to code in additional compression that will further reduce its bandwidth. The main developer is David Rowe, who also worked on Speex. Originally designed for Amateur Radio, both via sound-card software modems on HF radio and as an alternative to the proprietary voice codec presently used in D-STAR, the codec is probably also useful for telephony at a fraction of current bandwidths. The algorithm is based on papers from the 1980s, and is intended to be unencumbered by valid unexpired patent claims. The license is LGPL2. The project is seeking developers for testing in applications, algorithmic improvement, conversion to fixed-point, and coding to be more suitable for embedded systems."

Comments

Presentation this week.

[Bruce Perens]

I'll be presenting on Codec2 at the ARRL/TAPR Digital Communications Conference this weekend in Vancouver Washington, Near Portland. I'll try to get the video online.

Re:Presentation this week.

[Bruce Perens]

I am bringing the materials for a demo table with two laptops and real-time encode-decode, so people can try it themselves.

Original Rationale

[Bruce Perens]

The original rationale for Codec2 is at Codec2.org. I've been promoting this issue for about four years, as I was bothered by the proprietary nature of the AMBE codec in D-STAR. But I didn't have the math, etc., to do the work myself. It was really fortunate that David became motivated to do the work without charge. He has a Ph.D. in voice coding. By the way, look over his web site rowetel.com for the other work he's done: two really nice Open Hardware projects - a PBX and a mesh telephony device, an Open Source echo canceler for digital telephony, used in Asterisk and elsewhere, and his own electric car conversion. He'd be my nomination for the MacArthur grant.

Re:Original Rationale

[Yaur]

In a nutshell it looks like the rational for not just using Speex is:

• better resilience to bit errors
• better performance at ultra low bitrates

Re:Original Rationale

[Bananatree3]

that is basically it. Speex is built (as I understand it) for lossless transmission methods with little/no error correction needed. Radio, by its very nature is a very lossy medium, so something with better error tolerance is needed. Hence, Codec2 provides a nice route.

Re:Original Rationale

[Bruce Perens]

Sound-card modem implementations over SSB would be practical. See FDMDV. We're still a little wide for that, but we'll get there.

Re:Original Rationale

[Bruce Perens]

How does it compare to CELT?

So far, we've really only compared it to g.729, and it does OK against that. CELT starts at 32 kilobits per second and we're at 2 kilobits, so it's not really for the same application. But I noticed that the Alpha, all-floating-point implementation with some known low-performance code encoded the 3.75 seconds in 0.06 seconds, and decoded them in 0.04, on my 2.4 GHz processor. I would think that a polished implementation could achieve low delay on a DSP chip or some flavors of embedded CPU.

Re:Original Rationale

[Yaur]

With UDP the typical loss scenario is dropped packets but with radio single bit errors are more likely. This difference means that FEC strategies for one scenario are not directly applicable to the other.

for UDP in packet FEC data is useless and your error correction scheme needs to be prepared to deal with losing a whole packets worth of data to be useful. For voice this is going to introduce too much latency so instead a typical codec might just try to interpolate the lost data. With radio on the other hand there is value to in packet error correction bits within the stream and in the event of an error you are going to have more data with which to guess what the audio should be like, especially if you know which bits are errored (or possibly errored)

Re:Original Rationale

[jmv]

The fundamental difference is not that much the lossless vs lossy transmission, but the actual bit-rate. I designed Speex with a "sweet spot" around 16 kb/s, whereas David designed codec for a sweet spot around 2.4 kb/s. Speex does have a 2.4 kb/s mode, but the quality isn't even close to what David was able to achieve with codec2.

Re:what about LATENCY?

[Bruce Perens]

Right. Sorry. Real time on the x86 workstation I'm using. Not converted to fixed-point for weaker CPUs yet. Not tested on ARM, Blackfin, AVR, etc. Waiting for you to do that :-) Downloadable code. Reasonably portable. Type make and let fly.

Re:Serindipidy.

[Bruce Perens]

Congratulations on the license, OM. We haven't yet explored how to wedge this into D-STAR, but sending it as data rather than voice would be one way. All of the D-STAR radios except the latest one, the IC-92AD, use a plug-in daughter board to hold the AMBE chip, and it might be that somebody could make a dual-chip version of this board sometime. Since AMBE is proprietary we are stuck using their chip if we want to be compatible, unless the repeater does the conversion for us using a DV-Dongle. They sell TI DSP chips with their program burned in, and don't give out the algorithm.

It may be that on D-STAR the AMBE chip also does the modulation for a data transmission, just doesn't run the codec. But the modulation is known and there is a sound-card software implementation of D-STAR that interoperates with it. I don't have any D-STAR equipment to test. The folks on dstar_development@yahoogroups.com know a lot more about D-STAR.

73
K6BP

Re:Serindipidy.

[Bruce Perens]

The repeater can rebroadcast the data, but that data would be AMBE encoded, and AMBE is both trade-secret in its implementation and patented in some of its algorithms. There may be an AMBE chip in the repeater, I've not played with one. The usual way one converts to and from AMBE on a PC is with a device called the DV-Dongle, which contains the AMBE chip. This costs lots of money and is not nearly so powerful as the CPU of the computer it's plugged into, which is one reason to be fed up with proprietary codecs.

So, if you had some newer, Codec2-based radios, and some older D-STAR radios, linking repeaters might be a good way to get them to talk to each other.

This is hand-waving about a lot of issues, like we've not designed the next generation of data radio to put Codec2 into. One might guess that such a thing could use IPV6, and better modulation than just FM, and FEC, etc.

Really early latency figures

[Bruce Perens]

It encoded those 3.75 seconds in 0.06 seconds and decoded in 0.04 seconds on my AMD Phenom 9750 2.4 GHz, one core only, compiled with GCC and the -O3 switch. That's all of the overhead of the program starting and exiting, too. It's using floating, not fixed point.

This, it seems, bodes well for low latency of the final implementation on a DSP chip.

Re:Packet loss?

[Bruce Perens]

We don't know yet, but I don't see how it could be worse than AMBE in D-STAR, which makes various eructions when faced with large packet loss. I did various sorts of bit-error injection inadvertently while debugging yesterday, and right now you still get comprehensible voice with significant corruption of the LSP data. This, IMO, indicates an opportunity for more compression. Handling the problems of the radio link is more a problem for forward error correction, etc.

Re:what about LATENCY?

[Bruce Perens]

There are currently 51 bits in a frame. That is the minimum that you can send, and you'd send 40 of those per second as the codec is presently implemented. A real data radio would add bandwidth for its data encapsulation, but would have to meet the time and bandwidth requirements of the codec payload.