On Mon, Apr 22, 2013 at 2:28 PM, Bruce Perens <br...@perens.com> wrote:
> Well, the lower bandwith was suggested for use on narrowband connections -
> VoIP for example...
>
> This only works if you trunk a lot of connections between two points
> together, not for individual connections. The codec2 frame is 1/10 the size
> of an IPV4 header, and it's even worse when you get to IPV6. For VoIP, once
> a voice frame fits in a single IP packet, there is usually not much point
> in making it smaller.
>
If you pack multiple codec2 frames into each IP packet, the codec bandwidth
isn't quite as insignificant as in your example. Of course that increases
the latency, which may or may not be acceptable depending on the
application. Also, some IP connections (satellite) charge by the KB, so
saving even a few bytes does make a difference even if the number of
packets is the same. Nonetheless, your point is completely valid. In many
cases when using VoIP the headers will be bigger than the payload, and
there is nothing we can do to change that.
On 04/22/2013 09:13 AM, Steve Strobel wrote:
>
>> 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.
>>
>
> Yes, I used to think this as well, and if we had packets as large as IP
> it would probably be true. Things change because we have such small frames.
> David has shown that the FEC schemes that we can fit will themselves fail
> if the bit errors are higher than 3% or so, and will indeed cause good bits
> to be identified as bad. Fading will frequently bring the errors above this
> level.
>
> There's a very significant benefit to having the FEC understand the codec
> data frame, and having the codec itself tuned for bit error resistance.
>
I can't think of any drawback to having the FEC understand the codec data
frame, so I am completely in agreement there. Tuning the codec for bit
error resistance is obviously an advantage in some cases, but if it costs
very much bandwidth it seems to me that it would be worth considering
whether the same performance under fading could be achieved by using the
extra bits for additional FEC. Then for applications in which FEC isn't
helpful (VoIP), the lower bandwidth would be beneficial. But I understand
that VoIP isn't the primary application for codec2.
The most densely compressed version of the codec has vector quantization of
> the filter parameters. This compresses very efficiently, but even a one-bit
> error leads to a completely wrong result. So, David removed the VQ. He then
> applied 16 bits of FEC to the most significant bits only. So, bit errors
> result in a signal that might be somewhat off but is still readable by ear.
> We end up with a fade margin comparable to SSB, where previously it took
> an S7 signal to work reliably (and everyone complained).
>
That is clever and very impressive. It may very well be that additional
FEC can't provide the same result.
I wish I was better with FEC, as I would like to try something like BCH on
an entire frame or even multiple frames at a time. By using large FEC
blocks like that, it should be possible to correct a large number of bit
errors no matter where they occur in the block. The larger the block, the
more total bits could be corrected (the same percentage of the total bits
in the block). Since errors tend to occur in bursts, making the block
relatively long compared to the duration of a typical fade would allow it
to be completely corrected. Now that I think about it, the concept of
using large FEC blocks isn't so different from the modem using multiple
carriers and a relatively low symbol rate to minimize the effect of
time-localized errors.
> Steve
--
Steve Strobel
Link Communications, Inc.
1035 Cerise Rd
Billings, MT 59101-7378
(406) 245-5002 ext 102
(406) 245-4889 (fax)
WWW: http://www.link-comm.com
MailTo:steve.stro...@link-comm.com
------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
_______________________________________________
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2