On Wed, Feb 13, 2013 at 2:34 PM, Kristoff Bonne <[email protected]> wrote: > On 12-02-13 07:31, Albert Cahalan wrote:
>> BTW, given the nature of distortion and interference, I have >> to wonder if it might be good to send a wider signal with the >> assumption that half of it might be destroyed. The receiver >> could get just the low half, or just the high half, and be fine. > > Well, there where two reason: > > First, operating on 10 meter where a signal may not be wider then a > simular AM signal (i.e. 6 Khz) (very limited bandwidth) Uh, country? Here in the USA a mode may be illegal due to not being explicitly listed, but there generally isn't a bandwidth limit to be concerned about. (though waste is rude) > But also the idea of "half the bandwith = half the noise". A 2400 bps > signal should give us (in theory) a 3 db power gain over a 4800 bps signal. This is why I wrote "given the nature of...". We aren't facing white noise from DC to light. IMHO, it looks like chunks of your signal get blown to bits while other chunks go unscathed. > For the 4800 bps modem, I now use a simple 3/1 repetition code. It's > pretty lame but -as explained- the goal at that point was to have > something on the air. That should be low-latency and easy to process. Nice! :-) >> I've dealt with API and ABI issues before. It can get really awful. >> If at all possible, avoid: >> >> structs with layout the caller can see >> global data >> the need for locking >> non-public symbols showing up in an "nm -D foo.so" listing > > OK. I understand your point. > > However, as this is a project for the ham community; my problem will > probably not be that people who want to bypass the API. It's usually > more of an issue to find programmer to start with. :-) No, that wasn't the point. It's not about misbehaving programmers. If you have a struct in the ABI, you can never change the layout. You can't change a member from int to long, you can't add a member, you can't remove a member that has become useless and annoying, etc. If you do any of these things, the apps will all crash. If you have global data, then you need locking. As a library author you have no idea how this might interfere with the library users. The users may wish to run numerous instances of your codec. They might run one codec per thread. They might only have a single thread, but want to handle multiple streams of data via functions like select, poll, pselect, ppoll, epoll, WaitForMultipleObjects, or the kqueue stuff. They may want to run 2 instances of your codec in a 5-thread process, with 3 threads running the codec. Your library should not restrict these choices. If non-public symbols are showing up, performance is hurt. You suffer both longer start-up time due to symbol resolution and slower code due to the compiler's need to reload various references to global data. Calls may be less direct because the compiler and linker may need to allow function interception. >>> - creating a good UDP streaming-protocol between different parts of the >>> application: e.g. between the audiotool (voice input/output) and the >>> modem; but also -looking into the future- between a modem and a >>> "repeater" or "reflector" service, or between a freeDV receiving station >>> (acting as "webreceiver") and a remote listener. >> UDP will hurt. >> >> You can do named pipes or shared memory, but IMHO that belongs >> in higher-level code. The software modem itself ought to be purely >> math, without any IO. > > The UDP streams are not for the modem itself, but for streaming between > different applications. I use it between the "audiotool" (i.e. voice > capture/playback + codec2 encoding/decoding) and the gmskmodem (gmsk > modulation/demodulation + interfacing to radio). It looks like you are reinventing network audio. Even if you aren't, this sort of thing still belongs at a higher level. It isn't fundamental to running the modem or codec. You could write a separate library for the UDP protocol, if you really are 100% sure it needs to be written at all, then write a demo app that is simply a wrapper around both libraries. The demo app would parse the command line, initialize both libraries, then endlessly pass data from one library to the other. > But, if we think of applications like listing to remote FreeDV receivers > via the net, that format will surely not do. > > I like to see somebody come up with a proposal (and possible also > implementation as a library :-) ) of a streaming-format for codec2 over > UDP that will also work in a WAN enviroment. I think the IAX2 protocol should do, hmmm? It's just VoIP after all. ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb _______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
