Please create an account to participate in the Slashdot moderation system


Forgot your password?
Communications Open Source

Three Videos On Codec2 and Open Hardware 37

Bruce Perens writes "Codec2 is the Open Source ultra-low-bandwidth speech codec capable of encoding voice in 1200 Baud. FreeDV (freedv .org) is an HF (global-range radio) implementation that uses half the bandwidth of SSB, and without the noise. Here are three speeches about where it's going."
  • David Rowe: Embedding Codec2: Open Source speech coding on a low-cost microprocessor, at 2014. YouTube, downloadable MP4.
  • Bruce Perens: FreeDV, Codec2, and HT of the Future (how we're building a software-defined walkie-talkie that's smarter than a smartphone), at the TAPR/ARRL Digital Communications Conference 2013., YouTube
  • Chris Testa on the .Whitebox handheld software-defined radio design that is the RF portion of HT of the Future, which was also shown at the TAPR conference.

This discussion has been archived. No new comments can be posted.

Three Videos On Codec2 and Open Hardware

Comments Filter:
  • by AK Marc ( 707885 ) on Wednesday January 15, 2014 @02:42PM (#45967921)
    I wouldn't trust a CODEC I can't even find a MOS for (yeah, I found some independent tests, but they varied wildly).
    • by ajb44 ( 638669 )
      Feel free to pay to have that done. the algorithmic versions (PESQ, POLQA) are proprietary, and doing it with real people is also pretty expensive.
      • by AK Marc ( 707885 )
        So, I have to pay to see if it works? And people wonder why Open Source doesn't take off...
        • MOS is only for people who want to pay a lot of money. Of the automated processes, the one available to us isn't validated for less than 4K bps codecs.

          It would be a great improvement to MOS if there was an open version of POQLA. But the actual customer base for the codec have never even heard of MOS and thus we aren't volunteering to write that. The folks who want to put it in expensive government support systems yet aren't willing to help with testing don't get our sympathy.

          • by AK Marc ( 707885 )
            There are links in Alaska running on radio-phones of very poor quality. But I can't compare the quality of a bad radiophone link to this. I'd love to replace a radiophone system with a packet radio running a lower, but more robust bitrate, but if I can't compare the quality at a glance, I'll never get a business case approved to even evaluate it, let alone implement it. Not all telcos are made out of money.
            • There is a video of the codec vs. SSB on the same radio link here []. You can also take any radio links you have at hand and run the FreeDV program. This is an evening project to set up without a business case, and at least some companies appreciate people who take the initiative to do this sort of thing.
              • by AK Marc ( 707885 )
                That's a "radio link" but not a radiophone. I also don't have any radio phones on hand to test with. They are licensed devices, and the cost to test is $1000+ (as I'd have to fly to get to where the license is legal). They go long-distance, so can be difficult to test.

                Again, not all telcos are AT&T.
                • You could do this using FRS walkie talkies, as long as they have microphone and earphone connections. Or analog telephones. It's been tested multiple times on ham FM walkie talkies. Anything that carries voice should work. The bandwidth is only 1.25 kHz and I think the low end starts at about 700 Hz.

  • by bill_mcgonigle ( 4333 ) * on Wednesday January 15, 2014 @03:18PM (#45968321) Homepage Journal []

    This is pretty neat. Some high school friends and I were attempting to get voice working over 2400 baud c. 1990 (we wanted Internet phones). We never even came close, and thought we'd have to do phoenmic deconstruction to get that kind of data rate. This is pretty amazing for 1200 baud, even if it is almost 25 years later.

    • Would be if people used this for podcasts, Or if they just realized that they don't need to use 320 kbps stereo MP3 for their talking only podcasts. I don't really care about this when I'm at home, but most of the time I download my podcasts directly onto my phone. Using smaller formats means I can download it faster (I usually don't updated until I realize that I want to listen to something), and that I can store more stuff on my phone for listening to it later. It's kind of annoying when podcast creato
      • Using smaller formats means I can download it faster [...] and that I can store more stuff on my phone for listening to it later. It's kind of annoying when podcast creators end up generating a 120 MB file for 60 minutes of audio.

        Consider using a quad-core CPU to transcode 320 kbps MP3 to 64 kbps Vorbis. Divide the recording into four parts and run one part on each core. Then you can store the four parts on your phone without using too much internal storage. It won't solve your download time or monthly transfer cap problem, but it will help you work around phone makers' tendency to cut out microSD slots and mark up internal storage at highway robbery prices.

        • Uhhh...where is he gonna get a phone that will actually play the resulting 64kbps Vorbis? Like it or not while most phones will play MP3 from what I've seen very few will play Vorbis and while most phones have hardware MP3 decode to cut down on battery usage Vorbis is strictly CPU decode which will end up costing more in battery life.

          I'd say he'd be better off encoding to 128kbps MP3 or simply investing in a bigger microSD, not like you can't get those cheap nowadays.

          • All Androids by now have native Vorbis decoding libraries. It's software-based, but if I recall correctly, the battery life is about the same for mp3 and vorbis. Neither codec is ideal though, because podcasts are mainly speech. Speex or Opus (ideally) would be better and VLC will play those just fine.
          • where is he gonna get a phone that will actually play the resulting 64kbps Vorbis? [...] he'd be better off encoding to 128kbps MP3 or simply investing in a bigger microSD

            No iPhone has a microSD slot. So unless and until Windows Phone or BlackBerry becomes popular again, pretty much any phone with a microSD slot is going to ship with Android. And as chowdahhead pointed out, every Android device I've owned going back to 2.2 has come with a Vorbis decoder.

            Vorbis is strictly CPU decode which will end up costing more in battery life.

            MoonShell and Guitar Hero On Tour run 67 MHz ARM9 (ARMv5) CPU of a Nintendo DS, and they decode Vorbis in real time. With the higher clock speed and signal processing instructions of the processor in a modern phone, CPU use o

  • How does it handle latency? I was interested in FreedomPop since the cost was so low but the latency and jitter of 3G data networks caused it to be completely unusable and they were supposed to be using one of the better VoIP codecs for the conditions.

    • by stevew ( 4845 )

      I've used codec2 daily in the ghpsdr-alex branch for controlling SDR over Linux remotely.

      It is deployed on the Android App glSDR that you can find in the Android Market.

      The app provides a GUI with spectrum & waterfall along with Audio from the radio being controlled. Codec2 is used to provide a low-overhead transport that survives the Internet quite nicely.

      I've used the app with my 4G phone quite successfully.

      Now to the question of latency. When I connect to my own radio with a real-time playback PLUS

      • by stox ( 131684 )

        glSDR is awesome! Thanks for mentioning it. Now off to build a dspserver. ;->


  • by viperidaenz ( 2515578 ) on Wednesday January 15, 2014 @03:30PM (#45968481)

    The way that current digital voice products for Radio Amateurs encode voice signals to digital bits is both trade-secret and patented.

    Excuse me, but if something is patented, how can it be a trade secret?

    • Perhaps they are referring to different products, some of which are patented, others trade secrets.

  • Even codec2 authors wrote "1200 and 2400 bits per second".

    Nowadays with QAM64/256 and other modern techniques one symbol is not equal to one bit, and 1200 baud can be many times more bits/second.

    Already in 1990s V.32 standard transmitted 4800 bits/s over 1200 baud line, using symbols with 4 bits.

    Come on, this used to be technology geek site.

    • To put things in perspective for the new-ish Slashdot readers who aren't nerds at all, this means 1200 bit per second, 150 bytes per second or 0.146484375 KiB per second or roughly 870 times smaller than a typical 128kbps MP3/AAC file.

    • Sorry. When I say "1200 Baud", I am in general thinking of the TAPR TNC 2, which was never built for voice but can do it, to a degree, with this codec. It's sort of a Bell 212 modem on half-duplex radio. There were many commercial products based on the TNC 2 design and many hams have them on hand. It's a good demo to put speech through a pair of them, not really practical because the latency is high.
      • by Moskit ( 32486 )

        Thank you for taking time to reply and adding interesting information!

        Regardless of bauds/bits (and 1200 bits/s is more impressive than 1200 baud), Codec2 is a very interesting development in voice area. It also demonstrates how much has changed on endpoints when it comes to processing power and capabilites, while bandwidth (that in Hz and that in bit/s) still remains limited.

  • The typical VoIP packetization interval is 20ms. At their highest bitrate, you would be transmitting 48 bits (or 6 bytes) of data per packet.

    However, RTP packets have 54 bytes of overhead, and 20ms of G.729 is 20 bytes. Switching from G.729 to codec 2, the net bandwidth would only be a 19% decrease in bandwidth. For comparison, the last widespread codec change (G.711 to G.729) was a 65% decrease in bandwidth. It would be a much harder sell.

    On the other hand, VoIP could use the bandwidth for redundancy;

    • Correct. It's made for radio, and indeed you need to go connection-based rather than datagram-based to keep the header overhead smaller than the payload.

"The number of Unix installations has grown to 10, with more expected." -- The Unix Programmer's Manual, 2nd Edition, June, 1972