Стандарт позволяет (про конкретный Ваш чип не скажу). Но!
Спецификация (Classic BT):
"Four packets are allowed on the SCO logical transport:
HV1, HV2, HV3 and DV. These packets are typically used for 64kb/s speech transmission but may be used for transparent synchronous data"

"The air coding by log PCM or CVSD may be deactivated to achieve a transparent synchronous data link at 64 kbits/s."




Если Вы будете использовать "восстанавливающие коды FEC, и retransmission", то где же тут у Вас гарантированная задержка (latency)?
Для Real Time, в этом случае, нужен существенный запас скорости.
:-)
Да и без "восстанавливающие коды FEC, и retransmission" макс. возможная скорость SCO может Вас не устроить.

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

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

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

Механизм retransmission не подразумевает перезапрос данных - просто при его использовании данные передаются дважды, что увеличивает вероятность правильной доставки и не меняет гарантированную latency. Для retransmission отводится специальное окно в том же тайм-слоте, в котором передается основной пакет.
И таки да, согласен, в классическом SCO нет retransmission, и при использовании пакетов HV1-HV3 симметричная пропускная способность до 64 кбит/с.
Но начиная со спецификации 1.2 появился eSCO, где уже есть и retransmission, и скорость канала можно поднять до 288 кбит/c, при использовании пакетов EV5, и режим air coding = "transparent data". Вот в эту сторону и буду двигаться, благо CC2560 поддерживает eSCO линки.
Кому интересно - информацию можно поискать по ключевым словам "Using eSCO in Profiles", и Handbook of Networked and Embedded Control Systems