Linux: El audio bluetooth Pi3 tartamudea con Wifi habilitado

He tenido exactamente el mismo problema. La desactivación de WLAN0 solucionó los problemas de audio. Sin embargo, me gustaría mucho poder usar el wifi ...

Lo mismo está aquí. Me tomó 3 días, 2 distribuciones para descubrir que era la construcción en WiFi. El mismo error aparece cuando utilizo un dispositivo WiFi directamente en los puertos USB. Cuando utilizo un cable de conexión USB con la memoria USB, todo funciona bien. Así que simplemente creo que se debe a la antena incorporada que los dos servicios de 2,4 GHz se interfieren entre sí. : - /

Pude hacer que A2DP funcionara desactivando el wifi integrado y usando un adaptador USB Wi-Pi, sin ningún cable de extensión.

Esto plantea una pregunta bastante interesante: ¿el chip WiFi integrado es compatible con la coexistencia de Bluetooth, el controlador lo admite y funciona correctamente? Según lo que he visto de múltiples fuentes, hay una latencia considerablemente mejor cuando deshabilita el WiFi integrado o deshabilita el Bluetooth integrado y usa un adaptador USB en su lugar, y eso me suena como el chip integrado no implementa correctamente la coexistencia de BT o el controlador no lo admite correctamente.

El BCM43438 tiene una interfaz de coexistencia entre las interfaces WiFi y Bluetooth; no se requiere soporte de software.

@Ferroin Desde mi experiencia, diría / fundamentalmente / sí, aunque no soy una fuente autorizada y no exijo mucho en el lado de Bluetooth ... Mientras desarrollaba aplicaciones centrales y periféricas de Bluetooth LE en un Pi 3 I ejecute una sesión VNC X, 2x sesiones SSH y tenga el recurso compartido NFS montado todo a través de WiFi y todo está bien.

+1 en esto, como acabo de descubrir esta noche. Tomó wlan0 y el audio se reprodujo bien. ¿Alguien ha recibido noticias nuevas desde agosto sobre lo que está pasando aquí y si hay una solución?

+1 yo también, "ifdown wlan0" y pulseaudio se transmite bien a través de a2dp

+1, recién actualizado hoy, usando un altavoz bluetooth Anker Sound Core. Se reproduce maravillosamente si apago el wifi, pero esa es una solución bastante grande. Es molesto pero viable para este proyecto (Está bien, me conectaré a través de hdmi en lugar de vncserver, supongo ) pero yo también estoy esperando una solución porque limita seriamente mi capacidad para hacer que mis proyectos sean móviles. VNCserver es imprescindible.

+1 que me dio dolores de cabeza al descubrir este problema!

Necesitaba WiFi, así que solo:
1) Utilice un dongle USB como adaptador WiFi
2) Desactive el adaptador WiFi integrado en / etc / network / interfaces

No más problemas de sonido.

Estoy emocionado de ver cualquier progreso en esto, pero como recordatorio, puedes suscribirte a este hilo y agregar una reacción a la publicación original. No se recomienda para publicar una respuesta de 1.

Estuvo de acuerdo en que no hay WiFi paralizante para el Pi3 base. Agregar un dongle USB derrota una de las grandes ganancias con el Pi3 de WiFi / BT integrado. :-(

También probé el comportamiento y enfrenté el mismo problema que se informa aquí. Planea agregar un adaptador WiFi USB adicional para solucionar el problema. Hope pi soportaría un segundo WiFi sin muchos problemas.

Supongo que el Zero W sufrirá los mismos problemas con respecto a Bluetooth y WLAN, ya que usa el mismo chip.
Sin embargo, usar dispositivos USB como soluciones alternativas no es tan fácil con la Zero W.

¿Le está pasando esto a todo el mundo Raspberry Pi? ¿Cómo se reproduce la música? (¿Pi hat DAC, tarjetas de sonido, BCM?) ¿Para qué estás usando el Wifi?

Porque no he tenido ningún problema con mi Pi3

Solo un problema cuando ambos se van. WiFi transmitiendo activamente y luego intente usar Bluetooth. Bluetooth + LAN no es un problema. Por lo tanto, la mayoría de las personas y aplicaciones no verán el problema.

Agregué un receptor WiFi secundario y lo convertí en primario y utilicé WiFi integrado como receptor bluetooth. Esta es una forma más económica de hacer que esto funcione.

Bluetooth + LAN no es un problema.

Muéstrame el puerto LAN del Pi0W.

¿Alguien ha intentado cambiar pulseaudio para tener una mayor prioridad?

Sí, lo intenté con mayor prioridad sin diferencia perceptible en el resultado.

Hola,
¿Puede dejarme saber una configuración viable si tiene una para
el problema anterior, es decir, Wifi, necesario, emparejamiento de altavoces Bluetooth en A2DP
modo.
Desde su perfil, parece que ha jugado mucho en ese
zona.

Gracias.

Salud,
Pradeep
http://pradeepclicks.com/

El lunes 6 de marzo de 2017 a las 9:29 p.m., Brett Reinhard [email protected]
escribió:

¿Alguien ha intentado cambiar pulseaudio para tener una mayor prioridad?

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/raspberrypi/linux/issues/1402#issuecomment-284439625 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ADb1rV3_oFd2_qM8-2yHoDdLGeFK3d5dks5rjC1ngaJpZM4IExoX
.

También estoy tratando de resolver este problema. La agitación parece cambiar un poco entre los diferentes altavoces / auriculares BT, pero todavía está ahí usando un dongle WiFi y desactivando el WiFi integrado. Incluso usando un dongle BT, la agitación sigue ahí mientras se reproduce un mp3 local o se usa Pithos (Pandora). También utilicé un archivo mp3 con una tasa de bits más baja y la agitación mejoró.

Descargué un par de archivos de muestra de 16 a 64 kbps y los reproduje usando VLC en RPi3. Estoy ejecutando pulseaudio y conectándome a unos auriculares bluetooth baratos.
http://www.digitalprosound.com/Htm/WebAudio/2000/Oct/MP3bitrates3.htm

Con solo actividad WiFi de fondo, cada archivo se reprodujo, pero mostró algo de agitación con el aumento de la tasa de bits. Luego, ejecuté una actualización de apt-get y mientras se ejecutaba reproducía el archivo de 16k. Muy picado. Lo mismo para los demás. De hecho, la actividad wifi tuvo más efecto que la tasa de bits del archivo.

Ahora conecte un dongle WiFi y desactive el Wifi integrado (sudo ifdown wlan0). Inténtalo de nuevo.
Todos los archivos completamente suaves. ¿Qué pasa al realizar una descarga a través de Wifi? También suave a 64 kbps.
¿Ejecuta Pithos (Pandora)? Suave. Este no fue el caso anoche, por lo que no estoy convencido de tener una solución sólida.

Experimento el mismo problema.

Lo resolví usando un dongle Bluetooth que es un éxito total.
Tecnologías enchufables USB-BT4LE

Sin embargo, todavía no estoy contento con esto, ¿cuál es el punto de tener funciones que no se pueden usar?

Una cosa que debes asegurarte es que desactivas el escaneo de bluetooth (escaneo apagado) mientras estás en el indicador bluetoothctl. Eso resolvió mi problema y pude transmitir bien con un Pi Zero W, Pi3, usando el wifi / BT incorporado y Pi Zero + redbear IoT PiHat.

@Michiman : Estoy 100% seguro de que lo probé sin escanear al mismo tiempo. todavía tenía el problema. Aunque estoy usando rpi3.

+1
Lo mismo aquí es definitivamente la combinación de wifi integrado + bluetooth.
Configuración: pi zero w + phat dac

Habilitación de bluetooth + wifi a bordo -> el audio tartamudea muy mal
wifi integrado desactivado -> el audio se reproduce perfectamente sin tartamudear

Supongo que necesito comenzar a investigar cómo funciona todo esto en un nivel bajo, lo que constituye un buen desafío para aprender esto correctamente.

También tuve problemas de sonido terribles al intentar transmitir audio usando tutoriales a2dp basados ​​en pulseaudio.
Probé sugerencias para ajustar el tamaño del búfer y deshabilitar la WLAN interna.
La calidad del sonido mejoró enormemente, pero aún no hasta el punto de usarlo como un dispositivo de escucha real; en el mejor de los casos, obtendría un chasquido o tartamudeo cada pocos segundos.

Encontré otro proyecto de github que soluciona el problema al evitar pulseaudio por completo:
https://github.com/lukasjapan/bt-speaker
Después de deshabilitar la WLAN interna, el audio es bastante razonable con ese método y no es necesario iniciar sesión en el arranque (lo tengo ejecutándose en el fondo de mi imagen retropie).

@maklotski , ya hemos establecido que el problema se produce cuando tanto el Wi-Fi como el Bluetooth están

Hemos publicado toda la información útil que tenemos, es decir, no mucha. Cypress (antes Broadcom) tiene dos pilas de controladores paralelos: dhd y brcmfmac. Supuestamente están cerca de terminar un controlador dhd actualizado que mejora la coexistencia, pero a) aún se está probando yb) usamos brcmfmac. Tan pronto como haya un controlador brcmfmac mejorado, lo eliminaremos.

Simplemente agregar +1 a este número no sirve de nada. Simplemente hace que la lista de comentarios sea más larga sin ningún motivo. Tan pronto como tengamos información, se publicará.

+1 para seguir poniendo esto en el radar y, con suerte, aumentando la prioridad
para una solución

Este hilo de github se actualizará cuando haya información relevante para el problema. Dependemos un poco de que Broadcom (ahora Cypress) proporcione actualizaciones de controladores, ya que el soporte de coexistencia en el chip es una función del firmware del chip o de la configuración del firmware.

Degradar la relación señal-ruido del hilo con respuestas spam es simplemente irritante. Es probable que los comentarios que no aporten nada a la discusión sobre la investigación o resolución del problema se eliminen de manera sumaria.

Escribí un pequeño script para usar inotify para encender y apagar wlan0 si bluetooth se conecta / desconecta. Ok es
una solución pero puedo vivir con ella.

`#! / bin / bash

si bien es cierto
hacer
RES = inotifywait -q -e CREATE,DELETE /dev/input/
caso "$ RES" en
"/ dev / input / DELETE event1")
ifconfig wlan0 up
;;
"/ dev / input / CREATE event1")
ifconfig wlan0 abajo
;;
esac
hecho &
'

Así que aquí está el trabajo (de todos modos) que me gustaría compartir a expensas de que se rían de él.
Ejecute pacat /dev/zero en segundo plano
Ahora reproduzca algo de audio y después de que el crujido se detenga + -30 segundos, luego reproduzca más audio y disfrute de la reproducción clara hasta que detenga la pacat.
Si le preocupa que todos los ceros vuelen sobre bluetooth, entonces considere instalar "pv" con:
sudo apt-get install pv
Ejecute lo siguiente en segundo plano en lugar de cat /dev/zero | pv -qL 2k | pacat para limitar los ceros a una determinada tasa de bits.
Me gustaría saber cómo funciona esto para usted.

Interesante, todos. He estado trabajando en un Pi Zero / W - No X11 sin cabeza. Y puedo tener dos / tres shells ssh pasando por wifi, y Bluetooth es tan limpio como puede ser. Me di cuenta de que el sondeo excesivo del dispositivo Bluetooth (es decir, obtener información de Bluetooth) provoca tartamudeo. ¿Ha intentado simplemente arrancar a cli?

Bueno, me acabo de dar cuenta de que el siguiente comentario no fue realmente útil sin contexto. Lo siento, he estado golpeando el teclado toda la noche ...

1 - Pi Zero / W y Pi 3 idénticos en términos de Bluetooth / Wifi, al menos en lo que respecta al kernel.
2 - Ejecutando Jessie Lite - actualizado recientemente y kernel 4.9.29+
3 - Ejecución de NetBeans en el escritorio y depuración remota en Pi.
4 - Prueba de estrés Tasas de fotogramas con una pantalla TFT --- realmente arrancando ese bus SPI.
5 - Sondeo de eventos de entrada para pantalla táctil y volcado de resultados a stderr, que se canaliza a NetBeans - prueba de jitter en pantalla táctil
6 - Ejecutando el programa de ejemplo mpg123_to_out123 desde mpg123 tarball sobre Bluetooth reproduciendo "An Innocent Man" de Billy Joel desde la tarjeta SD.
7 - No hay X11 a la vista.

Funcionando tan suave como un pastel, con sabor a frambuesa. Hace tanto tiempo que tarareo Billy Joel mientras duermo.
He notado que forzar una consulta sobre el estado de la conexión Bluetooth empeoró las cosas.

Sugiera eliminar tanto código "otro" como sea posible.

Hola,
Definitivamente hay un problema serio con el Bluetooth PI (Zero W).

Moví un script de Python que detecta teléfonos a través de bluetooth desde un CHIP a un Pi Zero W.
El resultado fue una locura, atascó todo mi Home Wifi cuando se accedió a Bluetooth :-(

El script usa el siguiente comando para detectar si un teléfono está dentro del alcance:
resultado = bluetooth.lookup_name (mac, timeout = 5)

Ejecuto esto en un bucle con dos teléfonos. El ciclo comienza cada 15 segundos y prueba ambos teléfonos.
Primero notifiqué que a) SSH a través de Wifi no respondía a veces yb) mi luz LED WiFi no respondía a veces después de configurar el Pi Zero W.
Extraño, así que intenté hacer ping a las luces Wifi, resultado: tiempos de espera de aproximadamente 5 segundos cada 15 segundos.
Luego intenté hacer ping al PI Zero W: tiempos de ping de aproximadamente 2000-4000ms durante esas ventanas de 5 segundos, a veces incluso tiempos de espera.

Así que desactivé el script que ejecuta la detección de bluetooth: todo estaba bien.
Reinicio del script: los tiempos de espera se volvieron a producir.

¡Esto es Loco! El escaneo de bluetooth para los teléfonos (es básicamente un "¿estás ahí?" A un dispositivo bluetooth emparejado) básicamente rompe todo mi Home Wifi.
Sé que Bluetooth y Wifi están en la misma frecuencia. Pero Bluetooth está estandarizado para usar saltos de frecuencia extensivos para evitar tal interferencia. ¿No es así en el Pi Zero W?

Definitivamente es reproducible, solo pruebe el script de Python a continuación.

Mi mejor suposición sobre la razón: la radio bluetooth perturba el Wifi, no al revés. La razón podría ser un problema en la pila de bluetooth con respecto al salto de frecuencia. Esto también explicaría los problemas de audio de bluetooth informados: cuando el bluetooth permanece en una frecuencia, es más probable que el wifi perturbe su señal.
Sin embargo, podría estar equivocado, conozco el WiFi bastante bien como hice mi doctorado sobre un tema relacionado con la capa Phy de Wiifi, pero no soy un experto en Bluetooth Phy.

Un breve script de prueba de Python que reproduce el problema. Simplemente haga ping al Pi mientras lo ejecuta.

tiempo de importación
importar bluetooth
mac = "00: 00: 00: 00: 00: 00"
mientras que es cierto:
print ("Buscar% s por Bluetooth ..."% mac)
tratar:
resultado = bluetooth.lookup_name (mac, timeout = 5)
excepto bluetooth.btcommon.BluetoothError como e:
print ("\ nERORR: error en la solicitud de Bluetooth, error:% s"% e)
print ("Resultado:% s es:% s"% (mac, resultado))
hora de dormir (15)

Mañana (lunes por la noche EST), si quieres, publicaré un youtube que muestre lo bien que funciona. Sin embargo, solo una confirmación doble / triple (hace solo 5 minutos): los únicos problemas ocurren durante "Detectable" y "Escaneo". Si hace que su dispositivo no sea detectable y no escanee activamente (descubra) WiFi y Bluetooth funcionan bien juntos en un Pi Zero W. Obtengo un ping constante de 4-5 ms a través de WiFi mientras está conectado a través de Bluetooth y ssh. Necesito averiguar cómo grabar el sonido de un video de YouTube, pero puedo escucharlo claramente sin vibraciones.

FWIW - Estoy trabajando en una aplicación de audio Bluetooth, así que esto realmente me preocupa. En mi aplicación, estaba sondeando la información del dispositivo conectado para obtener RSSI, etc. Tuve que eliminar el sondeo debido a los problemas que ya han notado tantas personas aquí.

A menos que tenga el control de todas las aplicaciones en su sesión que podrían hacer una encuesta (D-Bus) en la conexión Bluetooth, no puede descartarlas como cómplices de los problemas. No estoy ejecutando X11, por lo tanto, estoy mucho más cerca del hardware y de lo que sucede. Por supuesto, PulseAudio sigue siendo una "caja negra", pero aparte de eso, básicamente tengo el control de todo el asunto y funciona bastante bien.

Ahora, no estoy diciendo que el firmware no tenga problemas, pero en realidad, las aplicaciones deberían comportarse mejor.

Oye,
Me interesaría mucho un video de youtube si tienes tiempo :)
También estoy usando un Pi Zero W, pero cuando desactivo el Wifi, el umbral tartamudea un poco ...

Hola, solo una nota: mi Zero W tiene el mismo problema: se salta el audio BT cuando se transmite por wifi, incluso para la versión 9.1 / Stretch de Raspbian

Cypress espera mejorar la "coexistencia" entre WiFi y BT, pero primero se han centrado en algunos problemas de estabilidad de WiFi.

Hola, ¿alguna actualización sobre esto?

Comenzando con la imagen Raspbian Stretch más reciente, ejecute:

sudo apt-get update
sudo apt-get install bluez bluez-firmware

Esto traerá un nuevo firmware Bluetooth y un BlueZ actualizado que, juntos, deberían mejorar la coexistencia de WiFi y Bluetooth.

Mientras lo hace, obtenga el último kernel para mejorar la confiabilidad de Bluetooth:

sudo apt-get install raspberrypi-bootloader raspberrypi-kernel

Me encantaría ver un video lado a lado del rendimiento de BT / WiFi
juntos. Si alguien no ha hecho uno, tendré que trabajar en él.

El 7 de noviembre de 2017 a las 12:15 p.m., "Phil Elwell" [email protected] escribió:

Mientras lo hace, obtenga el último kernel para Bluetooth mejorado
fiabilidad:

sudo apt-get install raspberrypi-bootloader raspberrypi-kernel

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/raspberrypi/linux/issues/1402#issuecomment-342554756 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AZCYY6u0Q45M19rAdGFM0WP4q6VXP0Zeks5s0JBOgaJpZM4IExoX
.

@pelwell Actualicé bluez bluez-firmware raspberrypi-bootloader raspberrypi-kernel a la última versión, como me aconsejó.

Sin embargo, sigo teniendo problemas con el sonido transmitido a través de bluetooth al raspberry zero W cuando el wifi está activo. Si apago el wifi ( sudo iwconfig wlan0 txpower off ), funciona bien y no se producen más crujidos.

Por favor, avíseme si puedo ser de ayuda.

Estoy usando bt-speaker. Problema relacionado reportado aquí: https://github.com/lukasjapan/bt-speaker/issues/4

¿Estás diciendo que no viste ninguna mejora?

desafortunadamente, no hay mejora :(

@pelwell Solo para que lo sepas, aquí tienes las versiones instaladas:

bluez              5.43-2+rpt2+deb9u2
bluez-firmware              1.2-3+rpt1
raspberrypi-kernel              1.20171029-1
raspberrypi-bootloader          1.20171029-1

¿Alguien tiene este mismo tipo de problema con los controladores de PS3 (a través de bluetooth) al usar Retropie con wifi habilitado en el rpi 3? Tengo lo que parece ser una interferencia aleatoria en la que a veces los controladores funcionan bien y, a veces, es como si no presionara nada en absoluto. ¡Hace que sea un poco difícil jugar de esa manera!

Hoy actualicé un Pi Zero W a todo lo último y puedo confirmar que el problema aún existe.
pi<strong i="6">@raspberrypi</strong>:~ $ dpkg -l | grep -i bluetooth ii bluealsa 0.6 armhf Bluetooth ALSA Audio backend ii bluez 5.43-2+rpt2+deb9u2 armhf Bluetooth tools and daemons ii bluez-firmware 1.2-3+rpt2 all Firmware for Bluetooth devices ii libbluetooth3:armhf 5.43-2+rpt2+deb9u2 armhf Library to use the BlueZ Linux Bluetooth stack ii lxplug-bluetooth 0.4 armhf Bluetooth plugin for lxpanel ii pi-bluetooth 0.1.6 armhf Raspberry Pi 3 bluetooth ii pulseaudio-module-bluetooth 10.0-1+deb9u1 armhf Bluetooth module for PulseAudio sound server

El BCM43438 parece tener problemas con múltiples conexiones, ya sea con BT + WiFi o con dos conexiones BT:

Al apagar WiFi ( ifconfig wlan0 down o dtparam=pi3-disable-wifi ), el audio Bluetooth A2DP funciona bastante bien. Sin embargo, cuando dos dispositivos están conectados, el audio comienza a tartamudear.

Con un adaptador Bluetooth USB externo, varios dispositivos pueden conectarse a través de A2DP y transmitir audio y eventos simultáneamente.

Así que supongo que esto es una limitación del chip, no una cosa de software ... (pero me encantaría que se demuestre que estoy equivocado en una futura actualización del kernel)

Asegúrese de estar ejecutando el último firmware de BT ( sudo apt-get update; sudo apt-get install bluez-firmware ); ha habido algunas mejoras.

Lo hice por última vez hace 2 días, ¿ha cambiado desde entonces?

-Ron

De: Phil Elwell [email protected]
Enviado: miércoles 24 de enero de 2018 a las 5:32 a.m.
Para: raspberrypi / linux
Cc: Ron Kuper; Manual
Asunto: [Externo] Re: [raspberrypi / linux] El audio Bluetooth Pi3 tartamudea con Wifi habilitado (# 1402)

Asegúrese de estar ejecutando el último firmware de BT (sudo apt-get update; sudo apt-get install bluez-firmware); ha habido algunas mejoras.

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub https://github.com/raspberrypi/linux/issues/1402#issuecomment-360088465 , o silencie el hilo https://github.com/notifications/unsubscribe-auth/AC8KdHhcuhMFBE5j42nTMhwc5NJTfxocks5tNwa4

No, ese será el último (1.2-3 + rpt1).

¡Gracias! Mientras tanto, compré un dongle wifi USB como solución.

¿Alguien sabe si se supone que el controlador del chipset (en teoría) debe tomar medidas para evitar la interferencia de RF entre estas 2 radios?

-Ron

De: Phil Elwell [email protected]
Enviado: miércoles, 24 de enero de 2018 7:20 a.m.
Para: raspberrypi / linux
Cc: Ron Kuper; Manual
Asunto: [Externo] Re: [raspberrypi / linux] El audio Bluetooth Pi3 tartamudea con Wifi habilitado (# 1402)

No, ese será el último (1.2-3 + rpt1).

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub https://github.com/raspberrypi/linux/issues/1402#issuecomment-360113610 , o silencie el hilo https://github.com/notifications/unsubscribe-auth/AC8KdIfVVwDf2lOlcGQTppx5A0jxxzv4WgaJXt .

Se supone que sí (hay un canal de coexistencia entre lo que son esencialmente dos dispositivos separados en el mismo paquete), y este firmware es una mejora significativa con respecto al firmware de envío original, pero compartir una antena parece ser un desafío.

@spalthammer escribió un script que serviría como una buena solución:

Escribí un pequeño script para usar inotify para encender y apagar wlan0 si bluetooth se conecta / desconecta. Ok es
una solución pero puedo vivir con ella.

`#! / bin / bash

si bien es cierto
hacer
RES = inotifywait -q -e CREAR, ELIMINAR / dev / input /
caso "$ RES" en
"/ dev / input / DELETE event1")
ifconfig wlan0 up
;;
"/ dev / input / CREATE event1")
ifconfig wlan0 abajo
;;
esac
hecho &
'
¿Alguien puede explicarle a un novato cómo implementar este script? Esto funcionaría muy bien para mí, ya que no necesito wifi mientras se reproduce el bluetooth. Sin embargo, todavía quiero poder usar ssh / vnc para mi Pi3 cuando el dispositivo BT se desconecta.

@lexanix

instalar inotify
cmd: sudo apt-get install inotify-tools
cp inotify.txt a /etc/inet.d/inotify (¡cambie el nombre de inotify.txt a inotify!)

inotify.txt

hazlo ejecutable
cmd: sudo chmod u + x /etc/init.d/inotify
crear enlaces simbólicos para iniciar el script en el arranque
cmd: sudo update-rc.d inotify por defecto

Espero que esto ayude.

@spalthammer ¡ Gracias por tu respuesta! desafortunadamente, esto parece no funcionar para mí. Hice todo lo que dijiste pero no pasa nada. inotify-tools está actualizado en mi Pi3.

lo que traté de hacer:
(Obviamente cambié el error tipográfico de "inet.d" a init.d)
-lo hizo ejecutable con chmod + x solo porque u + x no funcionó
-intenté ejecutar el script directamente desde la terminal (sin reiniciar) lo cual hizo ya que agregué una línea para devolver un eco y funcionó
-hecho que arranque al inicio desde /etc/rc.local
Sin embargo, el wifi aún permanece encendido cuando conecto mi teléfono a través de bluetooth ...

Estoy ejecutando la última versión de Raspbian. Mi teléfono transmite música al Pi a través de BT, que luego emite como una señal FM en el GPIO. Durante ese tiempo no necesito ningún wifi habilitado ya que la música comienza a tartamudear. Sin embargo, para poder volver a conectarme a mi Pi con SSH / VNC después de deshabilitar el wifi, hice un pequeño script "sudo ifconfig wlan0 up" que lo habilita automáticamente de nuevo después de cortar la energía y dejar que se reinicie. Esto parece estar funcionando por ahora, pero me gustaría tener el script inotify mucho más elegante ejecutándose hasta que sepamos qué está mal con nuestro chipset BT + WiFi.

@lexanix ,
lo siento por el error tipográfico.
sudo chmod u+x /etc/init.d/inotify debería funcionar. Asegúrese de que /etc/init.d/inotify sea propiedad de root y pueda ejecutarlo.
Si tiene más de un dispositivo de entrada conectado, digamos teclado, mouse y tarjeta de sonido USB, el número del dispositivo de entrada puede ser diferente. En el script, estoy esperando eventos en input1, que se ajusta a mi configuración. Detenga el guión con
sudo killall -9 inotify
y correr
sudo inotifywait -q -e CREATE,DELETE /dev/input
Conéctese al dispositivo bluetooth y anote el número de su dispositivo de entrada. Cambie el script y reinicie.
Revisé el guión dos veces. Incluso si no es perfecto, funciona como se esperaba.

Saludos

La conexión BT no es estable durante la reproducción A2DP. BT a menudo se desconecta y requiere reiniciar el sistema para recuperarse.
¿Puedes dar la solución?

@spalthammer ¡genial! tu script funciona como se esperaba
la solución perfecta para mí (Zero W con altavoz phat; ahora usando interfaces internas de Bluetooth y WiFi alternadas)
no más grietas mientras se reproduce música :-)

¿Será esto mejor con la nueva Raspberry Pi 3 B +?

@spalthammer

Gracias por la gran solución. Es justo lo que necesito.

Aunque solo tengo una conexión Bluetooth, obtengo lo siguiente cuando lo hago

root<strong i="9">@Ipad2GMA</strong>:/etc/init.d# sudo inotifywait -q -e CREATE,DELETE /dev/input
/dev/input/ CREATE event0

Entonces, como sugirió, edité inotify y cambié de event1 a event0. ¡Funciona muy bien ahora!

Pero me preocupa que eso cambie. Si solo tengo la conexión BT única, ¿será siempre event0?

¡Gracias!

@davthomaspilot ,

el número X en eventX depende del número de dispositivos de entrada, no del número de conexiones bluetooth. Por lo tanto, a menos que cambie la configuración de su hardware, digamos que si no agrega otro dispositivo de entrada, como una tarjeta de sonido USB o un teclado, el número no debería cambiar. Si desea saber más sobre sus dispositivos de entrada conectados, el comando:

cat /proc/bus/input/devices

le dará una descripción general.

Ragards.

¡Esta solución me funcionó muy bien! Pero, parece que ya no lo necesito, por alguna razón ...

Acabo de obtener otro pi zero w. Descargué la imagen jessie stretch e hice la actualización, actualización. Estoy usando un pHat DAC y las instrucciones de configuración de Bluetooth de aquí:

[https://www.sigmdel.ca/michel/ha/rpi/bluetooth_01_en.html]

¿Es posible que haya una solución que recogí en la actualización o actualización? ¿O quizás mi nuevo rpi tiene una solución de hardware?

Estoy clonando la imagen en mi pi que no tartamudea y la voy a probar en la que necesitaba la solución de Spalthammer. Y probaré la imagen que está en el rpi entrecortado en el nuevo hardware y deshabilitaré la solución alternativa para ver si el nuevo hardware se entretiene con esa imagen.

Descubrí que solo tengo el problema si dejo bluetoothctl ejecutándose. Tanto en el nuevo hardware / "software" como en el antiguo, no obtengo ninguna interrupción del flujo de Bluetooth A2DP a menos que esté en bluetoothctl.

Esto es stretch-lite, sin pulso de audio. Quizás eso sea significativo.

@pelwell , ¿Alguna idea de si esto se puede resolver como parte del nuevo firmware WiFi de cypress como se menciona aquí?
https://www.raspberrypi.org/forums/viewtopic.php?f=117&t=208090
Saludos,

@StudentSA No lo parece. Al menos no del todo. Estoy experimentando este problema en un Zero W con 2018-04-18-raspbian-stretch-lite.

bluez                  5.43-2+rpt2+ armhf
bluez-firmware         1.2-3+rpt5   all
raspberrypi-bootloader 1.20180417-1 armhf
raspberrypi-kernel     1.20180417-1 armhf

Posiblemente uno de esos problemas que nunca se solucionará ...

Decidí profundizar un poco en los controladores. La lectura del código me dio una idea de algunos de los parámetros del módulo que son compatibles, y con algo de experimentación y un enfoque de escopeta, parece que he conseguido que bluetooth + wifi funcionen perfectamente en conjunto entre sí.

Pude realizar una prueba de velocidad desde el pi a través de wifi, mientras mi teléfono reproducía audio A2DP a través del pi, y no obtuve ni una sola falla.

Creé un archivo /etc/modules.d/bt-wifi-fix.conf

options brcmfmac fcmode=2
options brcmfmac feature_disable=0x96
#options brcmfmac debug=0x00000004

debug=0x00000004 habilita el registro de nivel de información, que no es realmente necesario.

fcmode=2 parece habilitar algún tipo de control de flujo de hardware, que pareció mejorar un poco las cosas, pero aún así no es genial.

feature_disable=0x96 es la opción que realmente pareció solucionarlo. No estoy seguro, pero creo que 0x96 está tratando de deshabilitar todas las funciones opcionales, por eso dije arriba 'enfoque de escopeta'. Con un poco de paciencia, probablemente sea posible reducir esto a un pequeño subconjunto de características.

Hasta ahora, esto me ha funcionado perfectamente. Informaré si puedo reducir las cosas aún más.

EDITAR: Tengo un poco de falla cuando comienzo una transmisión por primera vez, pero absolutamente nada que parezca depender de si estoy usando wifi o no.

Ese es un gran punto de datos, gracias por mirarlo y manténganos actualizados sobre cualquier progreso adicional.

@pelwell Phil, ¿viste esto? Podría valer la pena informar a Cypress.

Eso parece muy simple: si Cypress está contento con él y es tan efectivo, podemos hacer que esos sean los valores predeterminados para los núcleos Pi.

¿Es suficiente simplemente crear /etc/modules.d/bt-wifi-fix.conf con el contenido que indicó? ¿O debo cambiar algo más para que surta efecto?

Simplemente cree el archivo como se describe y reinicie.

Ok, busqué en Google y encontré cosas para /etc/modules-load.d, pero no /etc/modules.d

Agregué el archivo en un Pi Zero W. Transmitiré por bluetooth por un tiempo y veré si escucho tartamudeos mientras está conectado el wifi.

¿Hay alguna forma de comprobar que se ha utilizado bt-wifi-fix.conf, además de comprobar si "no hay hipo"?

¡Gracias!

Si incluye options brcmfmac debug=0x00000004 (sin el comentario # ) entonces debería ver algún resultado de diagnóstico en el registro del kernel, como lo ve dmesg .

Ok, intenté esto:

 dmesg | grep brcmfmac
[   11.083290] brcmfmac: F1 signature read @0x18000000=0x1541a9a6
[   11.103157] brcmfmac: brcmf_fw_map_chip_to_name: using brcm/brcmfmac43430-sdio.bin for chip 0x00a9a6(43430) rev 0x000001
[   11.103836] usbcore: registered new interface driver brcmfmac
[   11.563229] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Oct 23 2017 03:55:53 version 7.45.98.38 (r674442 CY) FWID 01-e58d219f
[   11.575677] brcmfmac: brcmf_c_preinit_dcmds: CLM version = API: 12.2 Data: 7.11.15 Compiler: 1.24.2 ClmImport: 1.24.1 Creation: 2014-05-26 10:53:55 Inc Data: 9.10.39 Inc Compiler: 1.29.4 Inc ClmImport: 1.36.3 Creation: 2017-10-23 03:47:14
[   18.913833] brcmfmac: power management disabled
[   27.484932] brcmfmac: power management disabled

Entonces, haz el

administración de energía deshabilitada

¿Los mensajes indican que se está recogiendo el .conf?

Si no es así, ¿hay algo más por lo que pueda hacer grep?

Probado en un ZeroW con un kernel 4.14.41 (SO personalizado) Aunque muchas veces mejor, todavía hay algunos tartamudeos ... pero casi tolerables.

Ejecuté iperf3 de regreso a mi servidor mientras reproducía la transmisión a2dp ... el wifi estaba presionando
unos 30 MBit / s en iperf3.

Planes para probar en un pi3 y pi3b + (el 3b + ya puede funcionar bien si el wifi está conectado en un canal de 5Ghz)

@davthomaspilot Estoy intentando esto yo mismo ahora, y el contenido del archivo sugerido parece correcto, pero aunque el nombre del directorio me parece familiar, no está presente en mi sistema Raspbian - /lib/modprobe.d es lo habitual (y quizás _correct_) place - por lo que sugiero usar el nombre /lib/modprobe.d/bt-wifi-fix.conf archivo

Comience con las líneas fcmode y feature_disable comentadas y tome la salida de dmesg | cut -c16- | grep brcmfmac . Luego, descomente uno o ambos, reinicie y compare la salida de dmesg (y la calidad de transmisión).

¡Gracias! Yo haré eso.

Espero que esto ayude más que hacer "iwconfig wlan0 power off" en /etc/rc.local.

Con el ahorro de energía wifi desactivado, las interrupciones de la transmisión solo ocurren una vez cada minuto o dos. Esto es con nada más que una sesión ssh en el wifi.
Se necesitarán algunas "estadísticas" para ver si hay una mejora adicional. Lo intentaré en el Pi Zero W.

Aquí hay una diferencia que compara cuando las líneas están comentadas versus no (usando /lib/modprobe.d, NO /etc/modules.d:

> brcmfmac: brcmf_feat_attach Features: 0x96, disable: 0x96
34c35,36
< brcmfmac: brcmf_fws_attach FWS queueing will be avoided
---
> brcmfmac: brcmf_fws_attach added MAC-OTHER
> brcmfmac: brcmf_fws_attach enabled bdcv2 tlv signaling [4f]
50,51d51
< brcmfmac: brcmf_p2p_add_vif adding vif "p2p-dev-wlan0" (type=10)
< brcmfmac: brcmf_add_if allocate non-netdev interface
54c54
< brcmfmac: brcmf_cfg80211_connect ie (d949d258), ie_len (22)
---
> brcmfmac: brcmf_cfg80211_connect ie (d96ac658), ie_len (22)

Probando la calidad de la transmisión ahora ...

Todavía tartamudea. Es realmente difícil saber si es significativamente mejor que lo que tengo. Un tartamudeo una vez cada minuto o dos.

Nuevamente, esto es con wifi habilitado, pero prácticamente sin tráfico wifi.

Actualmente, mi solución es desactivar el wifi mientras el bluetooth está conectado. Realmente no me importan los tartamudeos cuando estoy conectado por wifi, pero sería bueno hacerlo sin tener que desconectar primero el Bluetooth.

Prueba con un pi3B + en un canal de 2.4Ghz.

El parámetro "options brcmfmac fcmode = 2" bloquea el controlador wifi en un pi3B + tan pronto como BT comienza a enviar datos a través de la conexión Bluetooth. Utilizando un perfil A2DP.

Estoy ejecutando solo con las opciones brcmfmac feature_disable = 0x96 en pi3B + y es bastante estable, a menos que presione la conexión wifi con iperf, entonces obtengo un tartamudeo significativo. No hay efectos secundarios aparentes con este parámetro cuando está en un canal de 5Ghz. Bluetooth es muy estable en este caso, e iperf3 empuja 120Mbit / s

Por lo tanto, no es para tirar una llave en las obras, pero honestamente no puedo reproducir este problema en la última imagen de Stretch con la actualización del firmware bluez y la actualización bluetoothctr. Tengo 2 tarjetas SD, una desde que publiqué originalmente en abril de 2017 con Jessie y PulseAudio. y creé una segunda tarjeta SD hoy con Stretch (9.4) y ALSA blue.

En Stretch, las cosas son perfectas, estoy reproduciendo una transmisión en línea (es decir, usando wifi) a través de mi altavoz Bluetooth al 100%. La vieja tarjeta con Jessie todavía cruje mal cuando Wlan0 está arriba.

Crédito a este tipo que detalló algunos trucos en la configuración:
Michel

Probé usando vlc, por lo que debe especificar qué dispositivo alsa usar así:
--aout = alsa --alsa-audio-device = "bluealsa"

Alguien puede probar esto desde una instalación nueva y asesorarlo.

bluez 5.43-2 + rpt2 + deb9u2 armhf
bluez-firmware 1.2-3 + rpt6 todos
bluealsa 0.7 armhf
bluetoothctl: 5.49
raspberrypi-bootloader 1.20180417-1 armhf
raspberrypi-kernel 1.20180417-1 armhf

no olvide iniciar bluealsa después de reiniciar o iniciarlo automáticamente: sudo systemctl enable bluealsa)

¿Cómo instalaste bluetoothctl: 5.49? Espero no compilar a partir del código fuente.

Sí, de la fuente (según el enlace compartido) ¿por qué la preocupación en torno a esto?

Solo me gusta tener actualizaciones usando el repositorio, también para evitar paquetes necesarios solo para construirlo. ¿Dónde se encuentra el enlace en tu publicación?

En realidad, hay una versión 5.50 lanzada hace 7 semanas. Si va por esta ruta, puede valer la pena intentarlo. Pero sí, tendremos que esperar a 5.49+ para entrar en el flujo oficial de apt-get.

Puedo confirmar que no tartamudea con Bluez 5.50.

Frio. Veré qué se necesitaría para actualizar la compilación de Raspbian.

Estos son los pasos:

1. Instale las dependencias.
   sudo apt install libdbus-1-dev libglib2.0-dev libudev-dev libical-dev libreadline-dev

1. Descargue la última versión del código fuente de BlueZ.
   wget http://www.kernel.org/pub/linux/bluetooth/bluez-5.50.tar.xz

2. Descomprime el archivo descargado.
   tar -xf bluez-5.49.tar.xz && cd bluez-5.50/

3. Configure.
   ./configure --prefix=/usr --mandir=/usr/share/man --sysconfdir=/etc --localstatedir=/var --enable-experimental

4. Compila el código fuente.
   make -j4

5. Instalar en pc.
   sudo make install

6. El usuario debe agregarse al grupo de bluetooth.
   sudo adduser pi bluetooth

7. Es necesario restaurar el archivo de configuración de Bluetooth de Dbus que se sobrescribió en la instalación de BlueZ.
   sudo nano /etc/dbus-1/system.d/bluetooth.conf

Agregue esto en la sección <policy user="root"> :
<allow send_interface="org.bluez.AlertAgent1"/>
<allow send_interface="org.bluez.ThermometerWatcher1"/>
<allow send_interface="org.bluez.HeartRateWatcher1"/>
<allow send_interface="org.bluez.CyclingSpeedWatcher1"/>

y esto después:
<!-- allow users of bluetooth group to communicate -->
<policy group="bluetooth">
<allow send_destination="org.bluez"/>
</policy>

1. Reiniciar Raspberry Pi
   sudo reboot

@amilino Aún no me funciona. Sigue tartamudeando con el wifi encendido y cuando está apagado. Probé casi todo en este hilo, incluso cambié de un rpi b + con un dongle bt a un rpi 3 b + con bluetooth integrado y todavía hay tartamudeo.

En realidad, no del todo tartamudeante. Parece obtener una gran cantidad de datos, reproducirlos demasiado rápido y faltar algunos bits, luego sentarse y esperar la siguiente porción.

Tengo la misma configuración que mencionó @StudentSA , excepto el último Bluez 5.50. También seguí este tutorial: https://gist.github.com/mill1000/74c7473ee3b4a5b13f6325e9994ff84c. Toqué las mismas canciones que antes tartamudeaba y ahora están funcionando sin problema.

@amilino Funcionó perfectamente, gracias.

El único efecto secundario de este tutorial es que el audio no se reproduce si conecta la máquina Linux en RPI Bluetooth. Si alguien conoce algún tutorial mejor, hágamelo saber.

Cypress ha estado investigando la interferencia de WiFi / BT y ha creado algunos nuevos ajustes de archivo "NVRAM" que, según ellos, han "solucionado por completo la tartamudez del audio". Se pueden utilizar los mismos ajustes en el 43430 (3B, ZeroW) y el 43455 (3B +).

1. Busque su archivo de texto "NVRAM" - está en /lib/firmware/brcm/brcmfmac<dev>-sdio.txt , donde <dev> es 43430 o 43455 respectivamente. Haga una copia de seguridad en un lugar seguro para que sea más fácil deshacer los cambios (o recuperarse de un error).

2. Abra el archivo en un editor de texto, desplácese hasta la parte inferior (simplemente para mayor claridad; esta configuración probablemente podría ir a cualquier parte) y agregue lo siguiente:

   # Experimental Bluetooth coexistence parameters from Cypress
   btc_mode=1
   btc_params8=0x4e20
   btc_params1=0x7530
   

3. Reiniciar.

Como se me explicó, estas configuraciones colectivamente permiten a Bluetooth más tiempo en el aire al permitir que WiFi duerma por más tiempo y reducir el tiempo máximo que se puede hacer esperar a Bluetooth.

Informe sus hallazgos, ya sean positivos o negativos, para ayudarnos a decidir si los convertimos en los nuevos valores predeterminados.

He estado siguiendo este hilo con interés. He estado usando un Pi ZeroW / Raspbian Lite para reproducir transmisiones de Internet a través de bluealsa a un altavoz bluetooth usando Mopidy. Hasta hoy, nada en este hilo ha resuelto el problema de la tartamudez.

bluez 5.50 - sin diferencia
deshabilitar WiFi y usar un adaptador USB ethernet: algunos cambian pero aún tartamudean cada pocos minutos

Cambiar la configuración de la NVRAM parece perfecto hasta ahora. He vuelto a usar WiFi y no hay tartamudeo en el audio bluetooth. Todavía usando bluez 5.50. Informaré si tartamudeo.

Resultados positivos hasta ahora. También estoy usando Bluez 5.50 también. Tablero - RPi3

Eliminé los parámetros de modprobe anteriores que se presentaron como una solución. Hasta ahora no hay tartamudeo. Usando iperf3, definitivamente puedes verlo robando tiempo a la radio wifi. Pero sin tartamudear, incluso cuando se transfieren datos adicionales.

Mientras juegas bluetooth,

[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  22.8 MBytes  19.2 Mbits/sec    0             sender
[  4]   0.00-10.00  sec  22.7 MBytes  19.1 Mbits/sec                  receiver

Detener la reproducción y desconectar el altavoz.

[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  55.3 MBytes  46.4 Mbits/sec    0             sender
[  4]   0.00-10.00  sec  54.9 MBytes  46.0 Mbits/sec                  receiver

Bluetooth desactivado a través de dtoverlay

[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  58.1 MBytes  48.8 Mbits/sec    0             sender
[  4]   0.00-10.00  sec  57.0 MBytes  47.8 Mbits/sec                  receiver

Funciona para mí raspi 3B, sin tartamudeo, incluso moviendo un archivo grande a través de wifi mientras se reproduce audio (a2dp), pero veo toneladas de
"Bluetooth: hci0: Error en el reensamblaje de la trama (-84)" en milisegundos.

$ dmesg
[ 2331.758484] Bluetooth: hci0: Frame reassembly failed (-84)
[ 2331.758689] Bluetooth: hci0: Frame reassembly failed (-84)
[ 2331.758750] Bluetooth: hci0: Frame reassembly failed (-84)
[ 2331.758833] Bluetooth: hci0: Frame reassembly failed (-84)

He estado probando esto durante unas horas. Es mejor de lo que era, pero no es perfecto. Ahora obtengo, a menudo de 20 a 30 minutos de reproducción continua, pero luego el tartamudeo comienza de nuevo y no desaparece hasta que paro y reinicio la transmisión de audio. También mi sesión de ssh se detiene por un momento cuando comienza la tartamudez. No es almacenamiento en búfer de audio, porque puse el registro en mi reproductor para indicarme cuándo se está almacenando en búfer.

Quizás deberías cambiarte a RPi3 b +, no tengo ningún problema.

Quizás deberías cambiarte a RPi3 b +, no tengo ningún problema.

Pero no es exactamente el punto, ¿verdad? Se dijo que los cambios "arreglan completamente" la tartamudez del audio. Solo estoy informando que ese no parece ser el caso. El 3B + usa un conjunto de chips diferente del W, por lo que quizás sea necesario modificar un poco la configuración.

Sí, estoy de acuerdo, pero mirando el tema del problema está relacionado con RPi3. De todos modos, esta discusión es demasiado larga, tal vez sería bueno tener una nueva edición separada relacionada con Pi W.

Esta solución también funciona para ZeroW. Llevo jugando más de 2 horas sin problemas.

Creo que los problemas que he estado experimentando en ZeroW probablemente se deben a que Bluetooth no tiene el mismo rango que el Bluetooth de mi iMac. Al acercar el altavoz al Pi, he estado reproduciendo radio por Internet durante 4 horas sin problemas. Tendré que reubicar el Pi para que la señal llegue a la cocina :)

Gracias por todos los comentarios, que sugieren que estas configuraciones son al menos una gran mejora sin regresiones. Siéntase libre de intervenir si sus experiencias sugieren lo contrario, pero estoy planeando hacer que estos sean los nuevos valores predeterminados.

Puedo agregar una observación más con un resultado positivo. He estado usando Bluetooth y Wi-Fi simultáneamente en mi ZeroW durante aproximadamente una hora sin tartamudear. Definitivamente un +1 al hacer de este el nuevo valor predeterminado.

¿Discute aquí solo el problema cuando se usa rPi como fuente a2dp o también como sumidero a2dp?

Estoy tratando de usar mi rPi3 como receptor de bluetooth (es decir, intento reproducir audio desde mi teléfono a mi rPi) y la tartamudez es tan intensa que apenas reconoces las canciones reproducidas. No se utiliza Wi-Fi. Lo intenté con un adaptador BT externo, sin suerte. Sin embargo, con diferentes adaptadores bt, el tartamudeo era diferente (como si se usara un tamaño de búfer diferente).

¿Debo informar un problema diferente?

@edio He estado usando el RPi ZeroW como receptor, transmitiendo audio desde mi teléfono al RPi a través de Bluetooth. Hasta ayer, yo también tenía un tartamudeo horrible, pero la solución sugerida más recientemente parece haberlo resuelto.

La solución presentada por @ paul-1 funciona para mí, en la placa Pi 3+. Puedo usar Wi-Fi normalmente y disfrutar de una buena transmisión de audio BT

Hola,
¿Alguien tiene alguna idea de cómo usar la solución NVRAM en un sistema Libreelec con un sistema squashFS de solo lectura? Según tengo entendido, es de solo lectura porque la siguiente distribución sobrescribe los archivos del sistema.

@bwims

RPi3:

mkdir /storage/.config/firmware/brcm
cp /usr/lib/firmware/brcm/brcmfmac43430-sdio.txt /storage/.config/firmware/brcm

RPi3 +:

mkdir /storage/.config/firmware/brcm
cp /usr/lib/firmware/brcm/brcmfmac43455-sdio.txt /storage/.config/firmware/brcm

Ahora edite el archivo en /storage/.config/firmware/brcm y reinicie.

O puede usar una compilación de prueba reciente de LibreELEC 9.0 con Kodi 18 que ya incluye esta corrección: https://forum.kodi.tv/showthread.php?tid=298461

¿Alguien en este hilo todavía tiene abandonos ocasionales después de que se aplicó la corrección? No es tan terrible como el tartamudeo que tenía inicialmente, pero aún así el receptor de bluetooth es bastante inutilizable para mí, ya que cada dos segundos tengo ráfagas de clics, aproximadamente cada uno correspondiente a una serie de registros en la salida de audio de pulso

E: [bluetooth] module-bluez5-device.c: SBC decoding error (-2)
E: [bluetooth] module-bluez5-device.c: SBC decoding error (-2)
E: [bluetooth] module-bluez5-device.c: SBC decoding error (-2)
E: [bluetooth] module-bluez5-device.c: SBC decoding error (-3)
E: [bluetooth] module-bluez5-device.c: SBC decoding error (-2)
E: [bluetooth] module-bluez5-device.c: SBC decoding error (-2)
E: [bluetooth] module-bluez5-device.c: SBC decoding error (-2)
E: [bluetooth] module-bluez5-device.c: SBC decoding error (-3)
E: [bluetooth] module-bluez5-device.c: SBC decoding error (-2)

y de bluez obtengo

Aug 26 17:49:07 mu kernel: Bluetooth: hci0: Frame reassembly failed (-84)
Aug 26 17:49:07 mu kernel: Bluetooth: hci0: Frame reassembly failed (-90)
Aug 26 17:49:07 mu kernel: Bluetooth: hci0: Frame reassembly failed (-84)
Aug 26 17:49:07 mu kernel: Bluetooth: hci0: Frame reassembly failed (-84)
Aug 26 17:49:07 mu kernel: Bluetooth: hci0: SCO packet for unknown connection handle 50346

Recibo períodos de hasta un minuto de clics y estallidos, luego desaparece, a menudo durante varias horas. Es peor cuando el altavoz está más lejos del Pi.

@MilhouseVH ¡ muchas gracias por eso! Me dejó aquí lo que otros podrían encontrar útil.

Para su información, en libreELEC (Rpi 3+), la solución cura la tartamudez, pero introduce un retraso de audio inaceptable si la película se transmite a través de WiFi. Supongo que es una limitación de la plataforma.

¿Está fijo el retardo de audio? ¿Puedes corregirlo usando retardo de audio?
https://kodi.wiki/view/Video_playback#Audio_and_Subtitle_Settings

Moví mis datos del wlan0 incorporado a eth0 y se resolvieron los problemas de bluetooth. Desafortunadamente no podemos tener nuestro pastel y comérnoslo también :(
Tendré que probar la sugerencia de NVRAM anterior cuando tenga la oportunidad.

Sigo tartamudeando después de probar todo tipo de correcciones en mi RPi 3+. Desactivará el wifi por completo y usará cable. :(

Bien. Estoy feliz de ser otro punto de datos. La solución de NVRAM cambió por completo mi proyecto por capricho construyendo una fuente A2DP usando mi zero-w. Comencé el proyecto ayer y hasta que encontré este hilo, tanto pulseaudio como bluez-alsa estaban completamente inutilizables mientras se usaba wifi. No tener wifi también sería un obstáculo. Muchas gracias a las personas que investigaron las fuentes de los chips y encontraron la solución.

Todavía tengo un poco de estallidos y sibilancias cuando la CPU se sobrecarga (como ejecutar actualizaciones mientras juego bluetooth) pero aparte de eso, es una máquina totalmente diferente. Para el registro, estoy ejecutando Arch 4.14.90, Bluez 5.50 y Pulseaudio 12.2. Lo que significa que esto debería funcionar en el futuro previsible y no es una solución que implique ejecutar software incompatible realmente antiguo. <3

Edité la configuración en los archivos NVRAM:
/usr/lib/firmware/updates/brcm/brcmfmac43430-sdio.txt
/usr/lib/firmware/updates/brcm/brcmfmac43455-sdio.txt

@acegallagher : No entiendo tu comentario. Se agradecería cualquier explicación.

Si tiene algún tipo de solución, ¿qué pasos necesita para tenerlo en RPI?

@pelwell

Los archivos NVRAM actualizados han estado en actualizaciones de Raspbian desde agosto de 2018. Alternativamente, puede descargarlos directamente:

• 43438 para Pi 3B y Pi Zero W: https://raw.githubusercontent.com/RPi-Distro/firmware-nonfree/master/brcm/brcmfmac43430-sdio.txt
• 43455 para Pi3 3B + y Pi 3A +: https://raw.githubusercontent.com/RPi-Distro/firmware-nonfree/master/brcm/brcmfmac43455-sdio.txt

Cópielos en la carpeta / lib / firmware / brcm (necesitará sudo cp ... ).

Lo siento, pero eso no funciona. Todavía tengo tartamudeo con Wifi.

Es una pena. ¿Reinició después de la instalación?

Desafortunadamente, existen límites a lo que se puede lograr con una antena compartida. ¿Ha intentado cambiar la distancia del Pi al AP y / o el dispositivo BT?

Sí, he luchado con esto durante algunos meses. Cambié al cable de red y ya no hubo problemas.

Hola,
Con el /usr/lib/firmware/updates/brcm/brcmfmac43430-sdio.txt actualizado y un amigo, y sí, reinicié :-), todavía escucho fallas en el audio USB que no están allí con el audio integrado (cada 5 segundos más o menos).
No usa wifi, todo ethernet.

Si, por otro lado, primero hago ifconfig wlan0, ¡entonces todo está bien ...!
oh, no, no lo es. solo mucho menos

¿Está informando tartamudeo de audio USB con Ethernet en un problema sobre audio Bluetooth con WiFi?

¡Ups!

Este problema de Bluetooth + WiFi está causando problemas con mi teclado al presionar varias teclas para 1 tecla hacia abajo hacia arriba.

@ pratt-jeremy ¿Es un teclado inalámbrico?

Tengo el mismo problema. Ejecutando Arch en un Pi B3, B3 + y Zero. Todos presentan los mismos síntomas: juego entrecortado con a2dp. Arch no ha actualizado el firmware como se indica aquí, pero primero lo hice manualmente. Si utilizo el BT integrado en estas 3 máquinas, Bluealsa se queja de que el búfer no funciona y reproduce música a borbotones. El diario muestra un búfer en ejecución. Si utilizo una llave USB, todo funciona como se esperaba. ¿Podemos intentar algo más? fwiw, mi kernel es 4.19.32

Me parece claro que poner bluetooth y wifi en un RPi es como hacer un bolso de seda con la oreja de una cerda.

El equipo de desarrollo de Raspberry Pi debería afirmar que reproducir audio a través de bluetooth mientras se reproduce un video a través de wifi simplemente no es compatible debido a la falta de potencia / ancho de banda.

Desde el primer día, el Pi ha sido promocionado como un reemplazo actualizado del micro de la BBC, para enseñar a los niños en las escuelas. Kodi fue una gran ventaja. Acabo de renunciar a esta idea. Quería enviar películas a un pi-top con un enlace bluetooth al sistema de audio de mi caravana, pero ahora solo conecto un disco duro de película en un puerto USB. Sin wifi, sin tartamudeo. Triste, pero no demasiado inconveniente.

¿Es este el comando apropiado que se debe ejecutar para que funcione el BT integrado?
/ usr / bin / btattach -B / dev / ttyAMA0 -P bcm -S 3000000
Este es el comando en el archivo de servicio para Arch Linux con la instalación predeterminada de Bluez 5.50

Entonces, tengo transmisión de audio a un B3 + con wifi habilitado y activo (estoy conectado a través de ssh). Estoy ejecutando Arch Linux. Tuve que instalar bluez-utils-compat para instalar el comando hciattach. Creo que Raspian ya tiene esto ...

cat /proc/asound/card0/pcm0p/sub0/hw_params 
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 44100 (352800/8)
period_size: 4410
buffer_size: 22050

El paquete Bluez 5.50 predeterminado tiene btattach que Arch usa para encender el adaptador BT. Esto no funcionó. Todo lo que obtuve fue un sonido de tartamudeo. Este el paquete Arch pi-bluetooth requiere que el comando sea:
ExecStart=/usr/bin/btattach -B /dev/ttyAMA0 -P bcm -S 3000000
El comando que funcionó fue de una versión anterior del paquete:
ExecStart=/usr/bin/hciattach -n /dev/ttyAMA0 bcm43xx 921600 noflow -
No pretendo saber si esto es 'correcto' o lo que sea, solo que esta es la primera vez que he tenido una reproducción fluida de bluetooth usando el adaptador integrado.

Solo para evitar confusiones. Cypress compró la tecnología Broadcom WiFi en junio de 2016. Desde entonces

• BCM43438 es CYW43438
• BCM43455 es CYW43455

@ pratt-jeremy ¿Es un teclado inalámbrico?

@ JamesH65 sí, es un teclado bluetooth. Veo que esto era para audio, pero pensé en mencionarlo. Una vez que apagué el wifi, el teclado bluetooth funcionó perfectamente. No hay caracteres repetidos que no presioné.

¿Presumiblemente tu distribución está completamente actualizada?

¿Presumiblemente tu distribución está completamente actualizada?

Estaba actualizado cuando publiqué aquí, probablemente esté desactualizado ya que fue en marzo. Actualizaré y veré si todavía está sucediendo.

En un RPI4 con WiFi suave bloqueado en rfkill. Todavía entrecortado en Pulseaudio A2DP.