Hi all, We are using Codec2 as one of the codecs for transferring voice data over tcp/ip (ie Internet) in our project:
http://napan.ca/ghpsdr3/index.php/Main_Page Decoded audio from the sdr server (called dspserver) is transferred to the client (called QtRadio) using PCM16, aLaw or Codec2, selectable by the QtRadio client. For tx, the microphone audio is sent from Client to server with codec2 encoding. Communication can use TCP (or optionally RTP , but only with G711A or aLAw). Since codec2 is transferred with TCP, there is rare networking error as TCP is responsible for error checking and re-transmission. This has been working for a while and we have good reports of our transmitted audio during regular QSO's. We are planning to make use of the codec2 <--> QFDM codes that is being tested here to allow the dspserver to transmit/receive the QFDM signals through simplex RF. if this is successful, we can multiplex multiple voice channels in a single RF signal in future. 73 Alex Sent from my iPhone On 16 Feb, 2012, at 6:15 PM, freetel-codec2-requ...@lists.sourceforge.net wrote: > Send Freetel-codec2 mailing list submissions to > freetel-codec2@lists.sourceforge.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/freetel-codec2 > or, via email, send a message with subject or body 'help' to > freetel-codec2-requ...@lists.sourceforge.net > > You can reach the person managing the list at > freetel-codec2-ow...@lists.sourceforge.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Freetel-codec2 digest..." > > > Today's Topics: > > 1. Re: codec2 tasks (David Rowe) > 2. Re: codec2 tasks (Bruce Perens) > 3. Re: soundcard-based OFDM Codec2 transceiver (Josh Mesilane) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 16 Feb 2012 11:17:49 +1030 > From: David Rowe <da...@rowetel.com> > Subject: Re: [Freetel-codec2] codec2 tasks > To: freetel-codec2@lists.sourceforge.net > Message-ID: <1329353269.3877.31.camel@bear> > Content-Type: text/plain; charset="UTF-8" > > Hello Steve, > > The CPU overhead of an interleaver is trivial - just shuffling an array > of bits. > > However yes it should be implemented as an option, e.g. a function call > that is optionally applied to the encoded bits. > > As we are looking at push to talk applications, we can tolerate a fair > bit of delay. So we could interleave a few 100ms of Codec 2 frames to > helps us ride over short fades. > > In line with the voice-SMS ideas Codec 2 offers another way to use voice > in low SNR channels. It could be transmitted at any bit rate in > non-real time then played back. For example 1200 bit/s coded speech > could be sent at 300 bit/s, then playback in real time. This would mean > waiting 40 seconds to receive 10 seconds of speech, but might be useful > for some applications. A quarter of the bit rate is equivalent to 4 > times the power, or 6dB SNR. > > Thanks, > > David > > On Wed, 2012-02-15 at 07:54 -0700, Steve Strobel wrote: >> On Tue, Feb 14, 2012 at 8:49 PM, David Rowe <da...@rowetel.com> wrote: >>> >>> 4/ Write an interleaver to re-arrange bits in a frame using a random >>> pattern known to the encoder and decoder. Useful so that a few >>> consecutive bit errors are spread randomly over a frame. >> >> It seems to me that interleaving bits like that would be especially >> effective in combination with using gray code to minimize the >> magnitude of the error introduced into any field by a single bit >> error. Maybe that is SOP for this kind of thing, but the light just >> turned on for me :) >> >> If interleaving the bits adds significant overhead, it might be worth >> making it optional or even doing it in a separate layer (possibly >> along with FEC) that could be easily disabled. I don't think >> interleaving bits (or FEC) will be of any advantage when the codec2 >> audio is being transported over IP, as packets with errors are >> generally dropped before they ever reach the VoIP application. >> >> On that subject, does anyone know if packets with errors can be >> captured rather than dropped by putting a network interface into >> promiscuous mode or something? If so, it might be possible for errors >> that are introduced in the last hop of a IP connection (WiFi, 3G) to >> be corrected. There probably isn't anything we can do to get routers >> to pass corrupted packets, but that might give us a shot at correcting >> some errors. >> >> Steve >> >> > > > > > > ------------------------------ > > Message: 2 > Date: Wed, 15 Feb 2012 16:51:52 -0800 > From: Bruce Perens <br...@perens.com> > Subject: Re: [Freetel-codec2] codec2 tasks > To: freetel-codec2@lists.sourceforge.net > Message-ID: <4f3c5328.8060...@perens.com> > Content-Type: text/plain; charset="utf-8" > > On 02/15/2012 02:43 PM, David Rowe wrote: >> Is Codec 2 actually of any use to anyone over IP? > It is if you are a telephone company. If you're trunking 10,000 > telephone calls between two points, it should help tremendously. > > There are some interesting concepts for geostationary communications > satellites. You can merge a whole lot of low-speed uplinks into one > downlink that everyone can hear. > > Thanks > > Bruce > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: bruce.vcf > Type: text/x-vcard > Size: 265 bytes > Desc: not available > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: smime.p7s > Type: application/pkcs7-signature > Size: 4447 bytes > Desc: S/MIME Cryptographic Signature > > ------------------------------ > > Message: 3 > Date: Thu, 16 Feb 2012 09:20:12 +0000 > From: Josh Mesilane <zinde...@chibiko.net> > Subject: Re: [Freetel-codec2] soundcard-based OFDM Codec2 transceiver > To: freetel-codec2@lists.sourceforge.net > Message-ID: > <cabrutrcwflk4j8ygg1xe8adxz11ka30q+nfu-wq+d+z1f6r...@mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > I too have tried to get this working under both Linux and Windows and in > both I've had soundcard errors. Is there any trick to executing the program > so that it can detect the soundcard? > > What Linux distro did you use? > > On Thu, Feb 16, 2012 at 12:06 AM, Darkside <lenniethelemm...@gmail.com>wrote: > >> This is incredibly awesome, and I'm looking forward to testing this out >> over the radio tonight :-) >> >> However - The program gives me an error saying it can't open the sound >> card, on Windows 7 (64-bit). This happens no matter what sound card I pick. >> >> I might (finally) install Linux on my PC and see if I can get it going >> there. >> >> Cheers, >> Mark VK5QI >> >> >> On Thu, Feb 16, 2012 at 2:38 AM, Peter Lawrence <majbt...@gmail.com>wrote: >> >>> All, I've written proof-of-concept PC software to demonstrate >>> receiving Codec2-encoded speech over an audio/radio link using a >>> soundcard. >>> >>> It uses a 2500 bps OFDM implementation to convey raw Codec2 data in >>> about 2.2kHz of audio. >>> >>> In the spirit of David's post, there is no FEC and the symbol period >>> is the same as the Codec2 frame size. The classic 2500bps Codec2 code >>> is used. >>> >>> It is a multi-platform tool (Windows and Linux) and source code and >>> binaries are provided: >>> >>> http://code.google.com/p/codec2demo/ >>> >>> The suggested usage is to use one of the provided pre-encoded modem >>> .wav files (see download section of web page) at the transmitter and >>> use the tool at the receiver. >>> >>> Using the tool, the user picks one soundcard to listen for the modem >>> signal and one soundcard to playback the speech. (These can be the >>> same soundcard.) >>> >>> As with any soundcard software, some manual tweaking of the audio >>> levels (both at the transmitter and at the receiver) is needed. I've >>> provided some instructions in the wiki section on volume controls in >>> Ubuntu and Windows. >>> >>> When the Linux version detects a modem signal, it turns green. On the >>> Windows version, it displays the word "RECEIVING". >>> >>> I've been testing with a simple acoustical coupling of microphone to >>> speaker. As I increase the distance between microphone and speaker, >>> the voice quality becomes corrupted and eventually cuts out. >>> >>> It would be nice if someone could test it with a real radio link. I >>> don't claim to know the entire history of Codec2 testing, but you >>> might literally be the very first person in the world to use a Codec2 >>> radio link! :) >>> >>> Note that because there is no FEC, there will be bit errors; the >>> Codec2 decoder can misinterpret these errors as loud digital >>> artifacts. So, please exercise some caution; an open loudspeaker to >>> listen to the decoded speech seems preferable to using a >>> headset/handset. >>> >>> On Mon, Feb 6, 2012 at 6:18 PM, David Rowe <da...@rowetel.com> wrote: >>>> Hello Peter, >>>> >>>> Nice work, and thanks for the links to those resources. >>>> >>>> The 1400 bit/s mode is buggy and still under development, so the bit >>>> stream (and even bit rate) might change. >>>> >>>> I've used Golay and Hamming codes in the past for Codec FEC. You won't >>>> have any patent problems. I might be able to dig up some code - let me >>>> know. To work out which bits to protect, try subjecting each bit in >>>> turn it to some random BER and see which ones are the most sensitive. >>>> Likely candidates for the 2500 bit/s codec are the MSB of pitch, >>>> voicing, energy, and MSB of low order LSPs. >>>> >>>> On this topic, I have some thoughts for modems and Codec 2: >>>> >>>> 1/ I like the idea of making the symbol rate the same as the frame rate, >>>> as it means no frame sync is required. So we might have 56 BPSK >>>> carriers with 40ms symbol rate. >>>> >>>> 2/ What we really want to maximise is speech quality at a given SNR. >>>> It's not about bit errors, but the perceptual effect of those bit >>>> errors. Speech is not like data - we don't want to aim for zero bit >>>> errors. Many Codecs can tolerate a 1% random bit error rate, data has >>>> to be perfect. This means SNR can be quite low without FEC, and we will >>>> still get our message through. >>>> >>>> 3/ A low bit rate gives us a narrower signal, which Mel has indicted >>>> fights interference (QRM). This might be more important than SNR or bit >>>> error performance on crowded Ham bands, where our signal sounds like >>>> noise and SSB users on adjacent frequencies may be inclined to >>>> accidentally splatter us. >>>> >>>> 4/ Halving the bit rate will give a 3dB increase in SNR, like doubling >>>> your tx power. Small changes in bit rate won't affect the signal much, >>>> e.g. 1600 bit/s compared to 1400 bit/s is only 10log(1600/1400) = 0.6dB. >>>> This also means we can add small amounts of FEC without much penalty. >>>> >>>> 5/ The 1% BER regime is the "knee" in the BER versus SNR curve for many >>>> modems. If the SNR drops much the modem falls over. If the power >>>> increases a few dB the raw BER gets low quickly, and FEC is not reqd at >>>> all. >>>> >>>> 6/ The HF DV channel might be characterised by fades where we either get >>>> a great signal or lose complete packets. Assuming we cant interleave >>>> much due to delay, then BER performance is not an issue, FEC is not >>>> helpful, we just need to do our best with lost packets. Or, maybe as HF >>>> DV is push-to-talk, we can tolerate 500ms of delay and can interleave >>>> using FEC to ride over short fades. >>>> >>>> 7/ Jean-Marc recently asked me about the usefulness of variable bit >>>> rate. After some thought I think that might be useful. For example >>>> imagine if we could send unvoiced and silence frames at 700 bit/s. We >>>> could do this by halving the number of carriers for that frame, if power >>>> is constant we would be putting twice the energy into each carrier. So >>>> during the pauses between words and consonants we would have a 3dB >>>> better SNR for our data than voiced speech (vowels). Curiously this >>>> would mean the listener would hear _less_ "channel" noise in the silence >>>> between words - the opposite to analog modes like SSB. These sorts of >>>> tricks are possible if we consider the speech coding and modulation >>>> together. >>>> >>>> Guess once we get this thing on the air we will get some clarity around >>>> the best way to handle HF DV. Right now I am working on integrating the >>>> LSP work Jean-Marc showed me a few weeks ago into a 1400-ish bit/s mode. >>>> Rather than make it perfect, I would like to get it to the point where >>>> we can test OTA and start tuning - hopefully get an on-air demo up for >>>> Dayton in May. >>>> >>>> My end-goal is to make HF DV work better than SSB for a given SNR. Not >>>> sure if that's possible yet, but digital has overtaken analog in most >>>> other areas of radio so it's worth a shot. >>>> >>>> Cheers, >>>> >>>> David >>>> >>>> On Mon, 2012-02-06 at 16:00 -0500, Peter Lawrence wrote: >>>>> In my limited spare time, I've been working on adapting an OFDM >>>>> implementation to convey the Codec2 1400bps bit stream. >>>>> >>>>> Functionally, it would operate like WinDRM, EasyPal, etc. (e.g. use a >>>>> soundcard connection to a radio's existing audio in/out), but could be >>>>> open-sourced and multi-platform. >>>>> >>>>> I took this packet modem implementation: >>>>> >>>>> http://www.arrl.org/q15x25 >>>>> >>>>> which is encapsulated into this open source library: >>>>> >>>>> http://www.baycom.org/~tom/ham/soundmodem/ >>>>> >>>>> and stripped out the FEC and data link layer (since these were suited >>>>> to a packet modem implementation, but not a real-time audio link). >>>>> >>>>> I've also been adapting the modem parameters (number of carriers, >>>>> symbol rate, etc.) to try to better suit Codec2, and have done testing >>>>> over a lossy audio channel under both Windows and Linux. >>>>> >>>>> Codec2 in the 1400bps mode operates on audio in chunks of 40ms. >>>>> However, the modem implementation uses powers-of-2 (a reasonable thing >>>>> to do with FFTs), which results in a symbol period of 12ms. >>>>> >>>>> The least common multiple of these two quantities is a not too >>>>> unreasonable 120ms ( 3 x 40ms = 10 x 12ms ). >>>>> >>>>> In my proposed implementation, there are 12 carriers, each with QPSK >>>>> modulation. This results in a 2000 bps data stream ( (1sec / 12 ms) x >>>>> 12 carriers x 2 bits/symbol = 2000 bps ). >>>>> >>>>> (FYI: the first carrier is at ~500 Hz, and the inter-carrier spacing >>>>> is ~125 Hz. This makes the highest carrier at ~1875 Hz. This should >>>>> fit comfortably into the audio bandwidth of most rigs and >>>>> regulations.) >>>>> >>>>> Rather than fixating on bit rates, a more applicable viewpoint would >>>>> be to view it as 168 bits of Codec2 data (3 x 56 bits/frame) that must >>>>> map into 240 bits (24 bits x 10 symbol periods). >>>>> >>>>> This mapping must also provide framing alignment so that a receiver >>>>> can align itself to the repeating blocks of 10 symbol periods. >>>>> >>>>> FEC is an art form, and rather than try to devise a (potentially >>>>> faulty) scheme on my own, I'd like to solicit input from the >>>>> knowledgeable readers on the mailing list. >>>>> >>>>> I'm looking for a specific suggestion on an implementation to map >>>>> these 168 bits into ten x 24 bits, rather than an open-ended "why >>>>> don't you try X?". Anyone can do a literature search on names of FEC >>>>> techniques; it takes real skill to devise a technique suited to a >>>>> channel (and quite frankly I don't have that experience yet). >>>>> >>>>> It also seems critically important to devise a technique not >>>>> encumbered by patent protection. >>>>> >>>>> Thanks for your time. >>>>> >>>>> >>> ------------------------------------------------------------------------------ >>>>> Try before you buy = See our experts in action! >>>>> The most comprehensive online learning library for Microsoft developers >>>>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, >>> MVC3, >>>>> Metro Style Apps, more. Free future releases when you subscribe now! >>>>> http://p.sf.net/sfu/learndevnow-dev2 >>>>> _______________________________________________ >>>>> Freetel-codec2 mailing list >>>>> Freetel-codec2@lists.sourceforge.net >>>>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 >>>> >>>> >>>> >>>> >>> ------------------------------------------------------------------------------ >>>> Try before you buy = See our experts in action! >>>> The most comprehensive online learning library for Microsoft developers >>>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, >>>> Metro Style Apps, more. Free future releases when you subscribe now! >>>> http://p.sf.net/sfu/learndevnow-dev2 >>>> _______________________________________________ >>>> Freetel-codec2 mailing list >>>> Freetel-codec2@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 >>> >>> >>> ------------------------------------------------------------------------------ >>> Virtualization & Cloud Management Using Capacity Planning >>> Cloud computing makes use of virtualization - but cloud computing >>> also focuses on allowing computing to be delivered as a service. >>> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >>> _______________________________________________ >>> Freetel-codec2 mailing list >>> Freetel-codec2@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 >>> >> >> >> >> ------------------------------------------------------------------------------ >> Virtualization & Cloud Management Using Capacity Planning >> Cloud computing makes use of virtualization - but cloud computing >> also focuses on allowing computing to be delivered as a service. >> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >> _______________________________________________ >> Freetel-codec2 mailing list >> Freetel-codec2@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 >> >> > > > -- > Josh > VK3HGI > zinde...@chibiko.net > 0416 039 082 > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > > ------------------------------ > > _______________________________________________ > Freetel-codec2 mailing list > Freetel-codec2@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freetel-codec2 > > > End of Freetel-codec2 Digest, Vol 22, Issue 15 > ********************************************** ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
