Pregunta:
Retraso de 1-2 segundos entre el video del teléfono y el audio del automóvil conectado al teléfono a través de bluetooth
Michael
2017-02-08 02:01:20 UTC
view on stackexchange narkive permalink

Cuando conduzco, mis hijos a menudo ven dibujos animados en mi teléfono Android con el audio de los dibujos animados que sale de los altavoces del automóvil, conectados al sistema de audio del automóvil mediante bluetooth. Desafortunadamente, hay un retraso muy visible de 1-2 segundos entre el video (como se observa en la pantalla del teléfono) y el audio. No existe tal retraso al escuchar el audio directamente desde el altavoz del teléfono. No hay una demora notable cuando el teléfono está conectado al mismo automóvil para mantener conversaciones telefónicas. Sin embargo, la combinación de video de youtube en la pantalla del teléfono + audio de los parlantes del automóvil tiene este molesto retraso de 1-2 segundos.

Por lo tanto, la pregunta: ¿qué puede estar causando esto y cómo reconfiguro lo que sea necesario? configurado para arreglar esto?

En caso de que los detalles sean importantes, el teléfono es Samsung Galaxy S5, el auto es Honda Odyssey 2013 con sistema de audio incorporado.

¿Ha intentado volver a emparejar el teléfono con el Odyssey?
Le recordaré a quien sea que haya votado en VTC y haya votado en contra, que las preguntas sobre accesorios de automóvil * están * en el tema de este sitio. El estéreo del vehículo es un accesorio.
Use el conector para auriculares y la entrada auxiliar en estéreo, vea si el problema persiste.
Ninguna de estas respuestas es útil. He tenido este problema con numerosos coches. No es el teléfono si el video se sincroniza bien con los auriculares Bluetooth y algunos equipos de sonido para automóviles del mercado secundario. Parece ser solo una diferencia de ingeniería estéreo individual. ¿Pero, qué es esto? ¿Qué faltan algunos estéreos de coche que otros y los auriculares Bluetooth tienen?
Cuatro respuestas:
lifebinder
2018-01-17 02:21:55 UTC
view on stackexchange narkive permalink

No quiero necro un hilo muerto, pero este es un problema conocido con el audio Bluetooth de Honda.

Hay un error en el protocolo de enlace de Bluetooth que da como resultado una transmisión de solo datos. Prueba.

Esto significa que el teléfono está codificando audio en datos, y luego el automóvil está decodificando esos datos nuevamente en audio. Como resultado, obtienes un retraso en la codificación y un retraso en la decodificación. Honda es consciente del problema, pero a partir de 2018 aún no ha lanzado una actualización de firmware para automóviles con este problema. No sé si las Honda 2018 todavía presentan este error.

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

Hasta donde yo sé, así es como funciona Bluetooth. A lo largo de todos mis años, siempre ha habido un retraso en el audio cuando se usa en combinación con Bluetooth.

Hay algunos programas que retrasan el video unos segundos para que coincida con el audio.

Así que supongo que su solución sería encontrar un reproductor de video donde pueda sincronizar manualmente el video y el audio.

Tal vez VLC en Android pueda hacerlo: https://play.google .com / store / apps / details? id = org.videolan.vlc

Tengo una Odyssey 2007 y soy un desarrollador de software con 5 años de experiencia en Bluetooth. Un retraso de 1 a 2 segundos no es normal. Debe esperar algo en el rango de 100 a 200 milisegundos para Bluetooth. Los dispositivos que admiten A2DP 1.3, sin embargo, pueden compensar este retraso de almacenamiento en búfer. Tanto la fuente de audio como el receptor deben ser compatibles con A2DP 1.3 para que marque la diferencia.
Barkermn01
2017-02-09 05:46:57 UTC
view on stackexchange narkive permalink

Este es un problema de límite de software / hardware; podría probar una mejor aplicación de transmisión en su teléfono si su estéreo es compatible con otros, el problema es que la transmisión de audio a través de Bluetooth es bastante trabajo,

Proceso telefónico

Reciba vapor de audio -> conviértalo en un códec para el reproductor -> envíe por blue tooth

proceso estéreo

recibir blue tooth -> convertir códec a flujo de audio -> reproducir audio

así que para todos los sonidos estos 6 pasos tienen que ocurrir y la conversión de audio es un proceso relativamente lento, y empeora por el bajo costo / free codecs.

y es más probable que esté en el extremo de sus teléfonos cuando dice que parece estar mal con su tubo, por lo que podría ser el procesamiento de la descarga de video y luego decodificar el códec de video para mostrar y el procesamiento del audio para Bluetooth podría ser que la CPU del teléfono no pueda hacer frente a tanto simultáneamente

La aplicación Música de mi iPhone funciona bien con cualquier otro altavoz Bluetooth, no hay demoras notables. Además, Bluetooth usa un códec (SBC) optimizado para un uso mínimo de la CPU, no para la calidad. También vea mi comentario a la respuesta de Cucumber.
Oh, saber que el nombre de un códec no cambia la validez de mi respuesta, el OP dijo que había más retraso al usar YouTube, lo que significa que hay un problema de carga de la CPU, no importa cuánto esté optimizado, una CPU ARM no está realmente construida para procesos multitarea de alta carga, y el hecho de que sea de menor calidad que MP3 o algún otro códec no significa que no sea un proceso relativamente lento en comparación con el manejo de entrada., una última cosa es que no todo el audio bluetooth usa SBC, es uno de los pocos https://www.soundguys.com/understanding-bluetooth-codecs-15352/
Cualquier teléfono inteligente fabricado, ya sea Apple o Android, probablemente desde 2010/2011 tiene potencia de CPU más que suficiente para manejar este caso de uso. En Bluetooth hay 2 perfiles para transferencia de audio, HFP y A2DP. HFP es para llamadas telefónicas. Está diseñado para una latencia baja, con una compensación de calidad. A2DP está diseñado para alta calidad, con una compensación de latencia. El OP no tomó nota del retraso con una aplicación de música independiente. Una aplicación de música y YouTube usan A2DP, alta latencia. Una llamada telefónica usa HFP, baja latencia.
Soy dueño de una Odyssey. He usado mi teléfono con * muchos * otros dispositivos Bluetooth. El retraso no se debe a mi teléfono. El Honda tiene un búfer de jitter superfluo de gran tamaño. Quizás hicieron esto para solucionar un problema de hardware, p. tal vez un mal diseño de antena. O quizás la CPU de la Odyssey está sobrecargada y esta fue la forma más fácil de superar las caídas de audio. De cualquier manera, este es un problema de Odyssey. Lea algunos foros, mucha gente ha informado de este problema, aquí hay un ejemplo: http://www.driveaccord.net/forums/138-audio-electronics-lighting/282537-bluetooth-audio-streaming-a2dp-delay- lag.html.
El OP establece específicamente Honda Odyssey. Tus puntos no están mal, solo es muy poco probable que sean la causa. Mi punto no era disminuir el valor de su respuesta, sino culpar a la parte que probablemente tiene la culpa, que en este caso es Honda. Esta es una discusión, no estoy seguro de por qué se necesita un lenguaje soez.
Porque incluso allí lo que ha sugerido es una infracción de la política de Stack Exchange, ninguna pregunta o respuesta debe ser totalmente específica. Debería tener valor de reutilización. Esta es la segunda vez que explicamos algo que está claramente en la política de Stack Exchange. No me importa que no sea la respuesta marcada, lo que sea, que alguien comente con información que no ahuyentará a ningún técnico mientras hace que mi respuesta parezca totalmente incorrecta para cualquiera que tenga problemas similares, los comentarios son para dar retroalimentación y desalentar el uso cuando la respuesta Está Mal.
Vaya y lea: https://meta.stackexchange.com/questions/184154/closing-changes-on-hold-unclear-too-broad-opinion-based-off-topic-reasonsNo debería tener que explicar esto al usuario de Stack Exchange Network.
Para el 99% de las personas que leen esta publicación, su respuesta será inútil. Y es engañoso para la persona no técnica que no conoce nada mejor. Es 2018, la era de la lentitud de los teléfonos inteligentes ha llegado y se ha ido.
Todavía tienen el mismo inconveniente que cualquier otro procesador ARM no está diseñado para manejar grandes cambios de memoria a gran velocidad, ya que no usa la memoria directamente, pasa por las tiendas, el conjunto de instrucciones es limitado, lo que significa que las aplicaciones tienen que usar más espacio de aplicación ya que hay más instrucciones en la memoria, lo que a su vez significa que la ejecución de una aplicación es más lenta y eso es antes de que la aplicación comience a leer audio en su memoria, luego lo transponga mediante una gran cantidad de E / S de memoria y luego lo escriba en un búfer de salida y luego lo pase a un sistema operativo para el tránsito de Bluetooth. y son tan buenos como X86 de los mismos Ghz / Cores
Parece que sabes mucho sobre las CPU ARM. Aquí hay otra forma de pensar que refuta su teoría del teléfono incapaz. Si el teléfono tuviera un retraso de 2 segundos, entonces el automóvil necesitaría un búfer de fluctuación de 2 segundos para compensar. Si tuviera un búfer de jitter más pequeño, escucharía cortes de audio. No escuchamos eso. Por lo tanto, debe ser que el automóvil tenga un búfer de jitter de 2 segundos, o que el teléfono tenga un retraso de 2 segundos y el automóvil tenga un búfer de jitter de 2 segundos. No puede ser que solo el teléfono tenga el retardo de 2 segundos, entonces tendría un búfer insuficiente.
Entonces, en ambos escenarios, el automóvil debe agregar un retraso de 2 segundos. Aún es posible que el teléfono tenga su propio retraso de 2 segundos, pero literalmente lo he probado con cientos de teléfonos y parlantes Bluetooth, esta camioneta tiene el retraso más grande que jamás haya visto. Bueno, pensándolo bien, supongo que no refuta su teoría del teléfono incapaz, pero demuestra que el automóvil es al menos parte de la razón del retraso de 2 segundos. Quizás su punto fue que Honda necesitaba el búfer de fluctuación de 2 segundos para compensar el retraso de 2 segundos de algunos teléfonos.
Sí, pero vuelve a lo que señaló que el automóvil no acepta una transmisión de audio, ya que señaló que el automóvil está aceptando una transmisión de bytes WAV sin procesar, lo que significa que 2 segundos podrían almacenarse en búfer si la aplicación que envía el audio visual conoce el Lag, pero debido al encarcelamiento en Android e iOS, no se aplica a la comunicación del hardware, por lo que la aplicación no sabe demasiado escalonar / demorar el video en 2 segundos. Sé mucho sobre muchas arquitecturas de CPU y por qué tenemos diferentes para diferentes procesos, en particular, investigo y me especializo en la optimización de la memoria de las aplicaciones.
Bill
2018-08-30 04:51:08 UTC
view on stackexchange narkive permalink

Este es un problema conocido con Hondas. Tengo una sincronización Bluetooth de recursos mucho mejor en automóviles que no son Honda. El teléfono no es el problema, es el Honda.

Si bien no tengo ninguna razón para dudar de ti, ¿tienes referencias para mostrar de qué estás hablando?


Esta pregunta y respuesta fue traducida automáticamente del idioma inglés.El contenido original está disponible en stackexchange, a quien agradecemos la licencia cc by-sa 3.0 bajo la que se distribuye.
Loading...