Bluetooth: передача данных через SCO, данных, а не звука Опции

[gerber]

Как известно, существуют 2 основных способа передачи данных через Bluetooth-соединение - ACL и SCO.
ACL всем хорош, но данные добираются до другого "берега" беспроводного линка с приличной задержкой, от 3 до 30 мс, что губительно для моей задачи. Настройка QoS (Quality of Service) существенно улучшает ситуацию до 5-7 мс, но периодически, очень редко задержка всё равно достигает 25-30 мс и вся идея теряет смысл.
SCO является синхронным каналом с гарантированной полосой и минимальными задержками и вписался бы замечательно в моё решение, но он предназначен для передачи звука. При открытии канала и передаче данных через него я вижу на приемной стороне не точную копию входного бинарного потока, а некоторую "пародию" на него. Дело в том, что SCO-канал целиком и полностью ориентирован на звук, и перед передачей он аппаратно обрабатывается некими алгоритмами (кодеками), которые далеко не lossless. Таким образом, бинарный поток несколько видоизменяется, что приемлемо для звука, но неприемлемо для данных.
Может, подскажет кто - неужели нельзя использовать SCO-канал для передачи данных?

[uriy]

С FEC задержка как раз будет гарантированная и фиксированная. Про retransmission в SCO никогда не слышал. Зачем это для звука?

[alx125]

С FEC задержка как раз будет гарантированная и фиксированная. Про retransmission в SCO никогда не слышал. Зачем это для звука?

Не удивительно, что не слышали. Спецификация про это молчит :-)
Но ТС написал , "потерянные данные восстановит верхний протокол".
Т.е. он это планирует взять на себя, а не на спецификацию стека BT возложить.
В принципе - рабочий подход.
Так реализовано было в Skype (по крайней мере до Microsoft).
Чтобы сократить накладные затраты TCP, передачи велись ч/з UPD-пакеты.
А доп.верхний уровень в случае необходимости запрашивал повтор.

Что же касается FEC-кодов ( Forward Error Correction, FEC, помехоустойчивое кодирование), то это решение добавляет избыточность в передачу и конечно же уменьшает скорость для payload.
Представьте на минуту, что он (код) выделил ошибку. То необходимо запросить (т.е. трафик в обратном направлении со всеми timeout-ами) повтор передачи. Какая уж тут гарантированная мин.задержка.
Если же код не только с обнаружением , но и с коррекцией ошибок, то там и избыточность передачи выше и кодирование сложнее.
А возможности коррекции ошибок очень даже ограничены. Например, можно исправить лишь 1-2 бита.
Именно поэтому SCO изначально ориентирован на речь, т.к. там мелкие проблемы в передаче сгладит ухо+мозг.