Am 22.04.2013 18:13, schrieb Steve Strobel: > On Wed, Apr 17, 2013 at 2:05 PM, David Rowe <[email protected] > <mailto:[email protected]>> wrote: > > Yes I think something like 800 bit/s is possible at roughly the same > quality using Vector Quantisation of the LSPs. However this > wouldn't be > robust to channel errors. > > > I am not sure what you mean by "robust to channel errors". It seems > to me that the job of the codec itself should be to compress the audio > and the job of the FEC should be to make the communication channel > robust. Is it a design goal for codec 2 itself (absent FEC) to > minimize the loss in intelligibility due to bit errors? If so, it > seems that it may lead to a design that is sub-optimal for > communication channels like IP in which FEC (at the IP level) doesn't > work (because packets with errors get dropped before the application > has a chance to apply FEC). Well, the lower bandwith was suggested for use on narrowband connections - VoIP for example... But also in the case that the FEC may be implemented on a lower OSI - Layer (e.g. transmission protocol or physical layer)... > > I would suggest that the design goals for the codec itself should be > to use minimum bandwidth and add minimum latency, with some > consideration for making the job of the FEC easier by minimizing how > long an uncorrected bit error would affect the audio (as Bruce > referred to). Then the FEC should use the remaining available > bandwidth to make the channel as robust as possible. I suppose the > counter-argument might be that giving up some compression in the codec > in order to minimize the effect of uncorrected bit errors would be > more effective (in the RF case) than doing more compression and more FEC. It seems plausible to reduce the algorithmic latency as well as frame lenght. In case of VoIP appilications, the bursts may be repacked, sorted and even split anyway, so a single lost packet may not become critical. But this is the key difference between the ''primary usage field'' (digital hamradio) and ''secondary usage fields'' (VoIP).
Once the lowest possible bandwith for Codec2 w/o FEC is found, the remaining bandwith can be used for FEC or other appilications, like AX.25 packet radio - making both stations in communication capable to adjust their transmission parameters to the best possible ratio of robustness vs. speech quality or to exchange some text messages as well. Also, new joining hams in a channel can signalize they are listening and want to speech without actually interfering the station that is talking - like children that learned to rainse their hands and wait until they are called. In Germany, a similar system is used to transmitt status-codes by fire-brigade trucks, emergency services and police. They have to send out a specific status (in this case, it's the number ''5'') and wait until they are called (join ''J''). Once you get used to this, you don't want to miss it: It enables interference-free radio commmunication for an almost infinite number of mobile and fixed stations on a very few channels. This is the original reason that led to the development of Codec2 - an open, narrowband digital voice codec that enables efficient bandwith usage for hams, isn't it? > > I guess this touches on the issue where "digital" radio protocols in > general tend to maintain their audio quality as the signal gets weak > until they suddenly "fall off the cliff". As long as the FEC is able > to correct all of the errors, there is no loss of quality. When it > can't, we get to hear how "robust" the underlying codec is when > dealing with uncorrected errors. So there is a tradeoff between > pushing the cliff out as far as possible (more compression and more > FEC) versus giving it a soft knee (making the codec fall apart less > with uncorrected errors). Which is more effective at making > communication possible at a given bit error rate is probably going to > take a lot more experimentation to figure out, and even then be > subjective. That's the point. in RF appilications, it seems more useful to keep as much of the robustness iniside of Codec2 itself - meaning a high tolerance to frame and packet losses. Something that is pretty useful when you want to mirgate to Codec2 on very noisy frequencies. (Like on 27 MHz / 12m - band)...
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
