Hi Peter,
On 29-05-12 01:05, Peter wrote:
This is good stuff. I'll download and take a look-see, probably
tomorrow. But. Hmm maybe tonight actually. I'll try and get some stuff
published this week. But best man duties are likely to tie me up for
most of this upcoming week. Probably I should add the ad-hoc changes
and check it reflects what you did right, and we can make it a
solution, for simplex at least.
No problem.
Just note that the changes I made where just "to have something". I will
addapt them to your specification document.
* How to use the application:
Basic file-based encoding/decoding:
For encoding:
"../gmskmodem -format c -noreceiver -sif hts2a.c2 -sof hts2a.raw"
For decoding
"./gmskmodem -format c -nosender -rif hts2a.raw -rof hts2a"
(add options "-v", "-v -v", "-d" or "-dd" for more debug information)
All other options:
"./gmskmodem -h"
Can the -sof be stdout (-)?
Of course. :-)
Just thinking for realtime stuff. Whether we can stream it straight in:
RX: rec -r 48000 -t raw -s -b 16 -c 1 -|./gmskmodem -format c
-noreceiver -rif - -rof -|./c2dec.exe 1400 - -|play -r 8000 -t raw -s
-b 16 -c 1 -
TX: rec -r 8000 -t raw -s -b 16 -c 1 -|./c2enc.exe 1400 -
-|./gmskmodem -format c -noreceiver -sif - -sof -|play -r 48000 -t raw
-s -b 16 -c 1 -
I've not looked yet. Just wondering if such a thing would be possible.
It should but I haven't tried it that way.
I wonder how alsa will react if you have two different applications
using the same audio device. In theory it should work.
The way I would do it would be like this: run the modem as a service:
gmskmodem -v -format c -siu 12345 -soa hw:1 -ria hw:1 -rou 225.1.2.3
12345 -ptt_cs /dev/ttyUSB
-v: verbose
- format c: codec2 format
- siu 12345 : sender input UDP (i.e. listen for any UDP packets on port
12345)
- soa hw:1 : sender output ALSA (device hw:1)
-ria hw:1 : receiver input ALSA (device hw:1)
-rou 225.1.2.3 12345: receiver output UDP, multicast packets to
IP-address 225.1.2.3 port 12345. The destination can also be a unicast
address, both ipv4 and ipv6 are supported
- ptt_cs /dev/ttyUSB0: PTT switching via control signals on serial port
/dev/ttyUSB0
Then
RX; nc -l -u -p 12345 | ./c3dec ....
TX: rec -r ... | nc -u <ip-address of host running receiver> 12345
You can also use TCP-streams for input. I bit less "real-time", but a
bit better shielded from packetloss. Use the option "-sit" (sender input
TCP) instead of "-siu" (sender input UDP).
(BTW. I just noticed that I did not change the "usage" and "help" for
the PTT switching. Options are
ptt_cs (serial port control signal pins)
ptt_tx (serial port, TX 0 continuesly on servial port. This is
equivalent to +12 V on RS232). Can be used on boards where the
control-ports of a serial port is not connected (like on a pandaboard).
Just add a cap between the input of the transistor base port of the PTT
switch and the ground)
ptt_lf (create lock-file and apply POSIX lock to it).
This seperation between the "modem" and the "application" was done to
have a quick way to do tests.
E.g. you can very easily create a parrot with this:
- run the modem, with the options dump received streams in a file. (it
will create a different file with a different filename every time).
- run a small bash script in the background that detects the presence of
a new file and then does a "cat <file> | nc <ip-address-server> <port>"
to send it to the modem to play it out.
Peter, M6DGI.
73
Kristoff - ON1ARF
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
