Декодирование пакетов Airplay на Java или C / C ++ на Android
В настоящее время я работаю над приемником AirPlay для части приложения для Android. Я использую следующие рамки:
https://github.com/pentateu/DroidAirPlay
Хотя это прекрасно работает на некоторых устройствах среднего класса, таких как miPad, нам нужно запустить его на нестандартных устройствах. Пользовательское устройство декодирует пакеты трансляции в 10–20 раз медленнее, чем miPad. В результате аудиопакеты теряют временную синхронизацию, и из-за времени, необходимого для декодирования пакетов, аудиосигнал никогда не может быть повторно синхронизирован.
Я просматривал некоторые другие приложения для трансляции в Play Store и, насколько я вижу, они, как правило, основаны на Shairport (https://github.com/abrasive/shairport) для вещательной стороны вещания.
** Примечание: ** Платформы на основе Shairport, по-видимому, не страдают от проблемы синхронизации на младшем устройстве.
Платформа, которую я использую, в значительной степени основана на платформе Shairport, за исключением того, что она написана на Java.
Для декодирования данных C / C ++ намного превосходит Java?
Если это так, то даст ли мне направление на декодирование части инфраструктуры DroidAirPlay через реализацию на C или C ++ с использованием NDK?
заранее спасибо
Matt
Решение
Хотя это правда, что Java компилируется в байт-код, который выполняется на виртуальной машине, он не обязательно должен быть медленнее (или быстрее), чем исходно скомпилированный исполняемый файл, будь то C / C ++ или нет. Все зависит от программы!
Есть несколько причин, почему в этом случае Java может работать медленнее:
- Реализация декодирования может быть просто плохо закодирована / оптимизирована? (что на самом деле не вина Java)
- Компилятор Java может генерировать неоптимальный код для JVM.
- Некоторые языковые конструкции Java слишком медленны для требований скорости / ресурсов, предъявляемых здесь.
- JVM просто еще один уровень абстракции и виновник
- На этом идет сборка мусора ?!
(Я должен отметить, что я не эксперт по Java!)
Тем не менее, я до сих пор не пошел бы так далеко, чтобы вызвать Java по сути медленнее чем C или C ++. Я уверен, что вы можете найти много-ориентир и тесты в Интернете, сравнивающие один язык с другим, и некоторые в определенной степени претендуют (из гордости и эго?). Но эти тесты только конкретные случаи, обычно тестирование конкретные аспекты более крупного языка (например, производительность поиска по хэш-карте!).
LLVM имел блог из трех частей на C и почему неопределенное поведение позволяет компилятору генерировать все еще правильный, но более эффективный код за счет вывода проверки безопасности во время выполнения или принятия решения, что i + 1 всегда идет после i, полностью игнорируя существование целочисленного переполнения. Если программист неосторожен, это может иметь катастрофические последствия.
По словам самого Бьярне в Абстракция и машинная модель C ++:
C ++ был разработан как язык системного программирования и использовался для
программирование встроенных систем и другие ограниченные в ресурсах типы
программирование с самых первых дней.
Таким образом, я считаю, что C и C ++ могут продвигаться дальше, чем Java, из-за этого неопределенного поведения и меньших ограничений, накладываемых на него. (И есть также бит встроенной сборки, но это не совсем C!)
Другие решения
Других решений пока нет …