Коды для защиты от потери пакетов, Альтернатива RaptorQ (RFC6330) Опции

[mvb]

Здравствуйте.
Решаем задачу: в udp пакетах передаём поток звуковых отсчетов, принимаем и воспроизводим с минимально возможной задержкой. На wifi наблюдаем потери пакетов (что естесственно). Хочется до какой-то степени защитится от этих потерь, при этом минимально увеличив задержку (latency) при воспроизведении.
Из описаных решений нашли следующие:
* xor группы из N пакетов и передача отдельно результата, позволяет восстановить один из N потеряных пакетов. Самая простая реализация.
* В лучших домах используют RaptorQ. Но он сильно нагружает процессор. И реализовать его достаточно трудоёмкая задача сама по себе. В открытом доступе есть только на матлабе и питоне. Ещё один персонаж на stackoverflow давно обещал выложить реализацию на Java в открытый доступ.

Наивный вопрос: может кто вдруг знает открытую реализацию RaptorQ?
Менее наивный: может кто подскажет альтернативное эффективное решение?

[stealth-coder]

1. Стандартный подход в мобильных системах связи - замена потерянных пакетов на комфортный шум (silence frame), нигде не видел использования схем перезапросов (для речи, конечно), даже при потере половины фреймов (не куском, конечно, а более-менее "размазанная" по времени) речь разборчива.
2. Простое использование помехоустойчивого кодирования не поможет, т.к. очевидно, что не справляется кодирование самого WiFi, НО если у вас есть возможность получать от модема ВСЕ пакеты, в т.ч. и битые, тогда это имеет смысл;
3. Пом. уст. кодирование может помочь при использовании перемежителя (на интервале нескольких пакетов), тогда потерянные блоки могут быть восстановлены декодером, естественно, за это придётся заплатить задержкой;
4. Не знаю тонкостей решаемой задачи, но если возможно, то использовать вокодер, который "сожмёт" поток и тогда:
1) Можно передать несколько одинаковых пакетов за то же время;
2) Уменьшить скорость передачи и за счёт этого повысить помехоустойчивость (WiFi это умеет).
При использовании вокодера задержка будет равна сумме длительности фрейма (обычно 20 мс) и времени кодирования/декодирования (в худшем случае, очевидно, не более длительности фрейма, иначе это перестанет быть системой реального времени).