Just my two cents worth to hopefully further constructively frame the discussion...
It seems that there are three broad types of approaches to a would-be real-world Codec2 implementation: 1) PC/laptop/tablet/smartphone (let's just call this PC for simplicity) 2) SDR 3) embedded hardware Regardless of which choice, the following building blocks are needed: a) suitable "glue" to connect to the radio set b) suitable "glue" to connect to the user's headset/handset of choice c) modulation and FEC scheme d) implementation-specific optimization of the Codec2 algorithm On item (a), there are a plethora of different variations of interfaces between manufacturers and models. Some radio sets have a 9k6 port; others only have a headset port. Even with a headset port, there are a myriad of different pinouts, microphone types (dynamic v.s. electret), microphone sensitivities, audio bandwidths, etc., etc. Item (b) is linked to item (a). There are a myriad of different pinouts, microphone types (dynamic v.s. electret), microphone sensitivities, etc., etc. There has to be a catalog of adapters to connect Brand X headset to Brand Y radio set. Item (c) is a development effort in itself. A lot of previous work exists for various packet radio implementations, although these are not necessarily tuned for a real-time digital audio link. Item (d) is at the mercy of development milestones of the Codec2 algorithm and Item (c). (An optimized implementation of Codec2 may only work on brand A CPU, and for said implementation there may be enough residual CPU time for modulation scheme X but not Y.) For a PC-based approach: This approach has the advantage that there are already a cornucopia of products to provide soundcard or USB connectivity to a radio set to address item (a). (However, some of these items will not work as well on, say, a tablet or smartphone, as these may have been artificially locked out by the manufacturer.) Addressing item (b), although possibility inferior to a "proper" ham headset/handset, there are an even greater variety of microphone + speaker products for the PC world (including ones built-in to the PC itself). On items (c) and (d), the PC has an excess of CPU power and the easiest path to development. This makes it possible to iterate repeatedly to refine and experiment on item (c) and not even worry about trying to expend effort on the optimization. (Tablet/smartphone devices may also have less CPU power than their PC/laptop relatives.) For a SDR-based approach: Item (a) because irrelevant, as the SDR *is* the radio. Since most SDR approaches involve a PC, item (b) can be addressed the same as with a PC. The SDR may also have a native headset interface, and development costs would be amortized over the entire market of the SDR platform, rather than just pioneering Codec2 users. Depending on the specifics of the SDR implementation, the modulation and FEC may be done more in the PC or in dedicated hardware. If the former, the same advantages of the PC on Item (c) apply to SDR. SDR potentially offers a major advantage over a PC-based solution in that the SDR is the radio. (I'm presuming that a PC-based solution is more of an "in-band" solution that is usurping the normal headset audio for a modulated alternative.) An SDR approach, however, could directly modulate at baseband/IF, potentially allowing more modulation options. Similarly, if the Codec2 implementation is done in a host PC, the same advantages of the PC on Item (d) apply to SDR. A disadvantage to SDR is that the equipment costs are likely much, much higher. It is at least equivalent to buying a whole additional radio, which potentially alienates many would-be users. For an embedded approach: The long-term advantage of this approach is that it offers the greatest cost-reduction, portability, and battery life. However, this is predicated on a decidedly non-trivial amount of development (loosely equivalent to that invested by a commercial radio developer). Items (a) and (b) must be largely developed from scratch, and one must either pick a subset of interface standard to support in order to simplify implementation (but risk alienating huge swathes of users that own Brand Z, etc.) or try to take on the Herculean task of designing and build a jack of all the trades solution. Items (c) and (d) are not any easier. As has already been heavily discussed on the mailing list, these are items still in flux and need of experimentation to optimize. (Furthermore, a modulation approach that might work well at one frequency range and bandwidth might be highly unsuitable for another, causing further fragmentation of effort.) One variant of the embedded approach would be to convince the developer of an existing AMBE product to modify it to use a near plug-in Codec2 replacement to the existing AMBE chip. With such a variation, one would inherit all the development effort to address items (a) through (d). The cost of entry is still high (a product revision), but not nearly as high as trying to do all of this from scratch. However, the Innovator's Dilemma applies: what incentive exists for an established manufacturer to introduce a new incompatible product that might alienate existing users (and IC suppliers)? On Tue, Nov 29, 2011 at 1:28 PM, Bruce Perens <[email protected]> wrote: ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
