Pacchetti di decodifica Airplay in Java o C/C++ su Android

Question

Attualmente sto lavorando su un ricevitore AirPlay per una parte secondaria di un'applicazione Android. Sto usando il seguente quadro:

https://github.com/pentateu/DroidAirPlay

Mentre questo funziona alla grande su alcuni dispositivi di fascia media come la miPad, abbiamo bisogno di ottenere questo in esecuzione su un dispositivo spec personalizzato bassa. Il dispositivo personalizzato decodifica i pacchetti di airplay da 10x a 20x più lenti del miPad. Di conseguenza, i pacchetti audio perdono la sincronizzazione temporale e, a causa del tempo necessario per decodificare i pacchetti, l'audio non può mai risincronizzare.

Stavo esaminando alcune altre app di ricezione airplay sul Play Store e da quello che posso vedere tendono ad essere basate su Shairport (https://github.com/abrasive/shairport) per il lato del ricevitore in modalità airplay.

** Nota: ** i framework basati su Shairport non sembrano soffrire il problema di sincronizzazione sul dispositivo di fascia bassa.

Il framework che sto utilizzando è fortemente basato sul framework Shairport a parte il fatto che è scritto in Java.

Per la decodifica dei dati, C/C++ è di gran lunga superiore rispetto a Java?

In tal caso, dirigere la parte di decodifica del framework DroidAirPlay tramite un'implementazione C o C++ utilizzando l'NDK mi dà un grande impulso alle prestazioni?

Grazie in anticipo

Matt

Answer 1

Se è vero che Java viene compilato in bytecode che viene eseguito in una macchina virtuale, potrebbe non necessariamente essere più lento (o più veloce) di un eseguibile nativo compilato, se C/C++ o no. Tutto dipende dal programma!

C'è un certo numero di motivi per cui in questo caso Java può essere più lenta:

• L'implementazione di decodifica potrebbe essere proprio male codificato/ottimizzato? (che in realtà non è colpa di Java)
• Il compilatore Java può generare codice non ottimale per JVM.
• Alcuni dei costrutti del linguaggio Java sono troppo lenti per le richieste di velocità/risorse collocate su di esso qui.
• La JVM è solo un altro livello di astrazione e il colpevole
• La garbage collection è attiva ?!

(devo notare che io non sono un esperto di Java!)

Tuttavia, ancora non andrei così lontano da chiamare Java intrinsecamente più lento di C o C++. Sono sicuro che puoi trovare many-a benchmarks e testare su internet confrontando una lingua con un'altra, e alcune affermazioni in un certo grado (per orgoglio ed ego?). Ma questi test sono solo casi specifici, in genere testando gli aspetti specifici di una lingua più grande (prestazioni di ricerca della mappa hash per esempio!).

LLVM ha avuto un three part blog post su C e perché comportamento non definito permette al compilatore di generare ancora codice corretto, ma più efficiente a costo di inferire il controllo della sicurezza in fase di esecuzione o di decidere che i + 1 sempre arriva dopo che, ignorando totalmente l'esistenza di overflow di interi. Se il programmatore non sta attento, questo può avere conseguenze disastrose.

Nelle parole di Bjarne se stesso in Abstraction and the C++ machine model:

C++ è stato progettato per essere un linguaggio di programmazione di sistemi ed è stato utilizzato per la incorporato programmazione di sistemi e di altri tipi di risorse limitate di programmazione in quanto il i primi giorni.

In questo modo, credo che C e C++ possano essere spinti oltre Java a causa di questo comportamento indefinito e di minori restrizioni su di esso. (E c'è anche il bit assembly inline, ma non è proprio C!)