CQ Codec2, Calling CQ Codec2
Over the holidays, I developed a bash script that allows to computers to communicate with codec2-encoded audio using UDP packets.
The script, called c2qso.sh, doesn't do any of the firewall-punching magic that Skype etc. perform. But it should be useful in testing lightweight linux contexts, especially those without a GUI, since it comprises pipelines built from pretty standard Unix tools.
Who'd like to arrange a QSO?
c2qso.sh works the following way. It pipes the audio-in through gstreamer to change the sample rate and format, pipes this through c2enc, and sends the resulting data out to the other machine as UDP packets, using a default port of 20002. Input is even simpler: a ncat process listens to the 20002 UDP port, and, if it gets a connection, opens a shell command that pipes the data through c2dec and pipes the resulting audio out through 'aplay'.
(I wasted a great amount of time trying to put the audio out through gstreamer, even writing gstreamer plugins for codec2. I kept getting choppy output, which was solved by using aplay. Unfortunately, although the rest of the toolkit is available for OS X, the OS X audio player doesn't seem to provide for streaming data in at 8000.)
There is no metadata or error correction in the streams.
Some helpful bits to get you started:
1. You need 'ncat', which is a souped-up version of 'nc'. ncat comes with nmap, so on a Fedora system do 'yum install nmap' and on a Debian system do 'apt-get install nma
2. Download and build codec2. This requires the 'svn' package installed. Then run '
Do 'cd codec2' then './configure' and 'sudo make install' (or su, then 'build all').
The script, called c2qso.sh, doesn't do any of the firewall-punching magic that Skype etc. perform. But it should be useful in testing lightweight linux contexts, especially those without a GUI, since it comprises pipelines built from pretty standard Unix tools.
Who'd like to arrange a QSO?
c2qso.sh works the following way. It pipes the audio-in through gstreamer to change the sample rate and format, pipes this through c2enc, and sends the resulting data out to the other machine as UDP packets, using a default port of 20002. Input is even simpler: a ncat process listens to the 20002 UDP port, and, if it gets a connection, opens a shell command that pipes the data through c2dec and pipes the resulting audio out through 'aplay'.
(I wasted a great amount of time trying to put the audio out through gstreamer, even writing gstreamer plugins for codec2. I kept getting choppy output, which was solved by using aplay. Unfortunately, although the rest of the toolkit is available for OS X, the OS X audio player doesn't seem to provide for streaming data in at 8000.)
There is no metadata or error correction in the streams.
Some helpful bits to get you started:
1. You need 'ncat', which is a souped-up version of 'nc'. ncat comes with nmap, so on a Fedora system do 'yum install nmap' and on a Debian system do 'apt-get install nma
2. Download and build codec2. This requires the 'svn' package installed. Then run '
svn co https://freetel.svn.sourceforge.net/svnroot/freetel/codec2 codec2' From a bare Fedora you'll need to do 'yum install gcc'.Do 'cd codec2' then './configure' and 'sudo make install' (or su, then 'build all').
3. Configure your firewall to allow incoming UDP packets on port 20002. On Fedora, go to 'Administration/Firewall' and use the 'Other Ports' tab to make this exception. In any case, the philosophy here is to use extremely simple networking tools to get the job done, and as a result, it should be easy to port this approach (if not the code) to platforms like the iPhone and android.
Very good Bruce, I'll have to give this a try. I'm currently swamped, but maybe next week we can try a QSO. I was working on my own client that simply used udp sockets and portaudio for portability: perhaps making that compatible with your setup would be fun.
ReplyDeleteMark --
ReplyDeleteThat'd be great. I think Simon will be set up soon, too: pretty soon we'll have many opportunities for testing and playing with this.
Your approach seems identical and should be interchangeable, since I'm just using the live data stream across UDP. My goal is to make this code work with various data radios, and especially UDP over 9600 baud packet (TH-D7, etc.) My feeling is that RTP would be overkill. (Moreover, this just works :-)
I'd like to try making an iOS client for this approach, too. If it took its data in over wifi, we could use something like the Wifly to send serial data from a TH-D7 to the iPhone or iPod.