Domanda:
Ritardo di 1-2 secondi tra il video del telefono e l'audio dell'auto connesso al telefono tramite Bluetooth
Michael
2017-02-08 02:01:20 UTC
view on stackexchange narkive permalink

Quando guido i miei figli guardano spesso i cartoni animati sul mio telefono Android con l'audio del fumetto che esce dagli altoparlanti dell'auto, collegato al sistema audio dell'auto tramite bluetooth. Sfortunatamente, c'è un evidente ritardo di 1-2 secondi tra il video (come osservato sullo schermo del telefono) e l'audio. Non si verifica tale ritardo durante l'ascolto dell'audio direttamente dall'altoparlante del telefono. Non ci sono ritardi evidenti quando il telefono è collegato alla stessa auto ai fini delle conversazioni telefoniche. Tuttavia, la combinazione video di YouTube sullo schermo del telefono + audio dagli altoparlanti dell'auto ha questo fastidioso ritardo di 1-2 secondi.

Da qui la domanda: cosa potrebbe causare questo e come riconfigurare ciò che deve essere configurato per risolvere questo problema?

Nel caso in cui le specifiche contino, il telefono è Samsung Galaxy S5, l'auto è Honda Odyssey 2013 con sistema audio integrato.

Hai provato ad associare nuovamente il telefono all'Odyssey?
Ricorderò a chiunque abbia VTC e downvoted che le domande sugli accessori per auto * sono * sull'argomento di questo sito. Lo stereo nel veicolo è un accessorio.
Utilizzare il jack per le cuffie e l'ingresso aux in stereo, vedere se il problema persiste.
Nessuna di queste risposte è utile. Ho avuto questo problema con numerose auto. Non è il telefono se il video si sincronizza perfettamente con gli auricolari Bluetooth e alcuni stereo per auto after market. Sembra essere solo una differenza di ingegneria stereo individuale. Ma cos'è? Quali sono alcuni stereo per auto mancanti rispetto ad altri e auricolari Bluetooth?
Quattro risposte:
lifebinder
2018-01-17 02:21:55 UTC
view on stackexchange narkive permalink

Non voglio eliminare un thread morto, ma questo è un problema noto con l'audio Bluetooth Honda.

C'è un bug nell'handshake Bluetooth che si traduce in una trasmissione di soli dati. Prova.

Ciò significa che il telefono codifica l'audio in dati e quindi l'auto decodifica i dati in audio. Di conseguenza, si ottiene un ritardo nella codifica e un ritardo nella decodifica. Honda è a conoscenza del problema, ma a partire dal 2018 deve ancora rilasciare un aggiornamento del firmware per le auto con questo problema. Non so se le Honda del 2018 mostrano ancora questo bug.

Cucumber
2017-03-11 10:23:45 UTC
view on stackexchange narkive permalink

Per quanto ne so, è così che funziona il Bluetooth. In tutti i miei anni c'è sempre stato un ritardo nell'audio se usato in combinazione con Bluetooth.

Ci sono alcuni software che ritardano il video di alcuni secondi in modo che corrisponda all'audio.

Quindi immagino che la tua soluzione sarebbe trovare un lettore video in cui puoi sincronizzare manualmente il video e l'audio.

Forse VLC su Android può farlo: https://play.google .com / store / apps / details? id = org.videolan.vlc

Ho un'Odissea del 2007 e sono uno sviluppatore di software con 5 anni di esperienza in Bluetooth. Un ritardo da 1 a 2 secondi non è normale. Dovresti aspettarti qualcosa nell'intervallo da 100 a 200 millisecondi per il Bluetooth. I dispositivi che supportano A2DP 1.3, tuttavia, possono compensare questo ritardo di buffering. Sia la sorgente audio che il sink devono supportare A2DP 1.3 affinché possa fare la differenza.
Barkermn01
2017-02-09 05:46:57 UTC
view on stackexchange narkive permalink

Questo è un problema di limite software / hardware, potresti provare un'app di streaming migliore sul tuo telefono se il tuo stereo supporta altri, il problema è che lo streaming audio tramite Bluetooth richiede parecchio lavoro,

Processo telefonico

Ricevi vapore audio -> converti in un codec per il lettore -> invia tramite dente blu

processo stereo

ricevi dente blu -> converti codec in flusso audio -> riproduci audio

quindi per tutti i suoni devono essere eseguiti questi 6 passaggi e la conversione dell'audio è un processo relativamente lento e peggiorato da poco / codec gratuiti.

e più probabilmente essere sui tuoi telefoni finisce come dici che sembra essere brutto con you tube, quindi potrebbe essere l'elaborazione del download del video e quindi la decodifica del codec video da visualizzare e l'elaborazione dell'audio per Bluetooth potrebbe essere dovuta al fatto che la CPU del telefono non è in grado di farcela contemporaneamente

L'app Music del mio iPhone funziona perfettamente con qualsiasi altro altoparlante Bluetooth, non ci sono ritardi evidenti. Inoltre, Bluetooth utilizza un codec (SBC) ottimizzato per l'utilizzo minimo della CPU, non per la qualità. Vedi anche il mio commento alla risposta di Cucumber.
Oh, la tua conoscenza del nome di un codec non cambia la validità della mia risposta, l'OP ha detto che c'era più ritardo quando si utilizzava YouTube, il che significa che c'è un problema di carico della CPU non importa quanto sia ottimizzato una CPU ARM non è realmente costruita per processi multitasking ad alto carico, e solo perché è di qualità inferiore rispetto a MP3 o qualche altro codec non significa che non sia un processo relativamente lento rispetto alla gestione degli input., un'ultima cosa non è tutto l'audio bluetooth utilizza SBC, è uno dei pochi https://www.soundguys.com/understanding-bluetooth-codecs-15352/
Qualsiasi smartphone realizzato, sia Apple che Android, probabilmente dal 2010/2011 ha una potenza della CPU più che sufficiente per gestire questo caso d'uso. In Bluetooth ci sono 2 profili per il trasferimento audio, HFP e A2DP. HFP è per le telefonate. È progettato per una bassa latenza, con un compromesso di qualità. A2DP è progettato per un'alta qualità, con un compromesso di latenza. L'OP non ha preso nota del ritardo con un'app musicale autonoma. Un'app musicale e YouTube utilizzano entrambi A2DP, alta latenza. Una telefonata utilizza HFP, bassa latenza.
Possiedo un'Odissea. Ho utilizzato il mio telefono con * molti * altri dispositivi Bluetooth. Il ritardo non è dovuto al mio telefono. La Honda ha un jitter buffer superfluo sovradimensionato. Forse lo hanno fatto per risolvere un problema hardware, ad es. forse un design dell'antenna scadente. O forse la CPU dell'Odyssey è sovraccarica e questo è stato il modo più semplice per superare i dropout audio. Ad ogni modo, questo è un problema dell'Odissea. Leggi alcuni forum, molte persone hanno segnalato questo problema, ecco un esempio: http://www.driveaccord.net/forums/138-audio-electronics-lighting/282537-bluetooth-audio-streaming-a2dp-delay- lag.html.
L'OP afferma specificamente Honda Odyssey. I tuoi punti non sono sbagliati, è solo altamente improbabile che sia la causa. Il mio punto di vista non era quello di sminuire il valore della tua risposta, ma piuttosto di dare la colpa alla parte che più probabilmente ha la colpa, che in questo caso è la Honda. Questa è una discussione, non so perché sia ​​necessario un linguaggio volgare.
Perché anche lì ciò che hai suggerito è una violazione della politica di Stack Exchange, nessuna domanda o risposta dovrebbe essere del tutto specifica. Dovrebbe avere un valore di riutilizzo. Questa è ora la seconda volta che spieghi qualcosa che è chiaramente nella politica di Stack Exchange. Non mi importa che non sia la risposta contrassegnata, cosa che mai qualcuno commenta con informazioni che non spaventeranno nessuno tecnico mentre fanno sembrare la mia risposta completamente sbagliata per chiunque abbia problemi simili, i commenti devono fornire feedback e scoraggiare l'uso quando la risposta è sbagliato.
Si prega di andare a leggere: https://meta.stackexchange.com/questions/184154/closing-changes-on-hold-unclear-too-broad-opinion-based-off-topic-reasons Non dovrei doverlo spiegare all'utente di Stack Exchange Network.
Per il 99% delle persone che leggono questo post, la tua risposta non sarà utile. Ed è fuorviante per la persona non tecnica che non sa niente di meglio. È il 2018, l'era della lentezza degli smartphone è arrivata e se n'è andata.
Hanno ancora lo stesso inconveniente di ogni altro processore ARM non è costruito per gestire una grande quantità di memoria che altera alla velocità in quanto non utilizza la memoria direttamente passa attraverso i negozi, il set di istruzioni è limitato, il che significa che le applicazioni devono utilizzare più spazio per le applicazioni poiché sono più istruzioni in memoria che a sua volta significa che l'esecuzione di un'applicazione è più lenta e questo prima che l'applicazione inizi a leggere l'audio nella sua memoria, quindi lo traspone da un sacco di I / O di memoria e quindi lo scrive in un buffer di output, quindi lo passa a un sistema operativo per il transito Bluetooth. e sono buoni come X86 con gli stessi Ghz / Core
Sembra che tu sappia molto sulle CPU ARM. Ecco un altro modo di pensarci che smentisce la tua incapace teoria del telefono. Se il telefono avesse un ritardo di 2 secondi, l'auto avrebbe bisogno di un buffer jitter di 2 secondi per compensare. Se avesse un buffer di jitter più piccolo, si sentirebbero interruzioni dell'audio. Non lo sentiamo. Quindi deve essere che l'auto abbia un buffer di jitter di 2 secondi o entrambi il telefono abbia un ritardo di 2 secondi e l'auto abbia un buffer di jitter di 2 secondi. Non può essere che solo il telefono abbia il ritardo di 2 secondi, quindi avresti buffer underrun.
Quindi, in entrambi gli scenari l'auto deve aggiungere un ritardo di 2 secondi. È ancora possibile che il telefono abbia il suo ritardo di 2 secondi, ma l'ho letteralmente testato con centinaia di telefoni e altoparlanti Bluetooth, questo furgone ha il ritardo più grande che abbia mai visto. Bene, a pensarci bene, immagino che non smentisca la tua incapace teoria del telefono, ma dimostra che l'auto è almeno una parte del motivo del ritardo di 2 secondi. Forse il tuo punto era che Honda aveva bisogno del buffer di jitter di 2 secondi per compensare il ritardo di 2 secondi di alcuni telefoni.
Sì, ma il ritorno a come hai sottolineato che l'auto non accetta un flusso audio come hai sottolineato che l'auto sta accettando un flusso di byte WAV Raw significa che 2 secondi potrebbero essere bufferizzati se l'app che invia l'audiovisivo conosce il lag ma a causa del jailing in Android e iOS non fa comunicazione tra app e hardware, quindi l'app non conosce troppo lo sfalsamento / ritardo del video di 2 secondi. Conosco molte architetture di CPU e perché ne abbiamo di diverse per processi diversi, in particolare, cerco e sono specializzato nell'ottimizzazione della memoria delle applicazioni.
Bill
2018-08-30 04:51:08 UTC
view on stackexchange narkive permalink

Questo è un problema noto con l'Hondas. Ho una sincronizzazione Bluetooth delle risorse molto migliore nelle automobili non Honda. Il telefono non è il problema, è la honda.

Anche se non ho motivo di dubitare di te, hai dei riferimenti per mostrare di cosa stai parlando?


ⓘ
Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...