Linux: L'audio Bluetooth Pi3 bégaie avec le Wifi activé

J'ai eu exactement le même problème. La désactivation de WLAN0 a résolu les problèmes audio. Cependant, j'aimerais beaucoup pouvoir utiliser le wifi ...

C'est la même chose ici. Il m'a fallu 3 jours, 2 distributions pour comprendre que c'était la construction du WiFi. La même erreur apparaît lorsque j'utilise une clé WiFi directement sur les ports USB. Lorsque j'utilise un câble de connexion USB avec la clé USB, tout fonctionne correctement. Donc, je pense simplement que cela vient de l'antenne intégrée que les deux services 2,4 GHz se brouillent. : - /

J'ai pu faire fonctionner A2DP en désactivant le wifi embarqué et en utilisant un adaptateur USB Wi-Pi, sans câble d'extension.

Cela soulève une question plutôt intéressante: la puce WiFi embarquée prend-elle en charge la coexistence Bluetooth, le pilote le prend-il en charge et fonctionne-t-il correctement? D'après ce que j'ai vu à partir de plusieurs sources, la latence est considérablement meilleure lorsque vous désactivez le WiFi intégré ou désactivez le Bluetooth intégré et utilisez un adaptateur USB à la place, et cela me semble être la puce intégrée n'implémente pas correctement la coexistence BT ou le pilote ne la prend pas correctement en charge.

Le BCM43438 dispose d'une interface de coexistence entre les interfaces WiFi et Bluetooth - aucune prise en charge logicielle n'est requise.

@Ferroin D'après mon expérience, je dirais / fondamentalement / oui, même si je ne suis pas une source faisant autorité et que je n'exige pas grand-chose du côté Bluetooth .... Tout en développant des applications centrales et périphériques Bluetooth LE sur un Pi 3 je exécutez une session VNC X, 2x sessions SSH et faites monter le partage NFS via WiFi et tout va bien.

+1 à ce sujet, comme je viens de le découvrir ce soir. A pris wlan0 vers le bas et l'audio a bien joué. Quelqu'un a-t-il eu un nouveau mot depuis août sur ce qui se passe ici et s'il y a une solution?

+1 moi aussi, "ifdown wlan0" et pulseaudio diffusent bien via a2dp

+1, mis à jour aujourd'hui, utilisant un haut-parleur Bluetooth Anker Sound Core. Joue à merveille si je désactive le wifi, mais c'est une solution de contournement assez importante. C'est ennuyeux mais réalisable pour ce projet (OK, je vais me connecter via HDMI au lieu de vncserver, je suppose ) mais j'attends moi aussi un correctif car cela limite sérieusement ma capacité à rendre mes projets mobiles. VNCserver est un must.

+1 qui m'a donné des maux de tête pour découvrir ce problème!

J'avais besoin du WiFi alors je viens de:
1) Utilisez un dongle USB comme adaptateur WiFi
2) Désactivez l'adaptateur WiFi intégré dans / etc / network / interfaces

Plus de problèmes de son.

Je suis ravi de voir tout progrès à ce sujet, mais pour rappel, vous pouvez vous abonner à ce fil et ajouter une réaction au message original. Il n'est pas recommandé de publier une réponse de +1.

A convenu qu'aucun WiFi ne paralyse la base Pi3. L'ajout d'un dongle USB bat l'un des gros gains avec le Pi3 du WiFi / BT embarqué. :-(

J'ai également testé le comportement et confronté au même problème que celui signalé ici. Vous prévoyez d'ajouter un adaptateur USB WiFi supplémentaire pour résoudre le problème. J'espère que pi prendrait en charge le deuxième WiFi sans trop de problèmes.

Je suppose que le Zero W souffrira des mêmes problèmes concernant Bluetooth et WLAN, car il utilise la même puce?
Cependant, utiliser des périphériques USB comme solutions de contournement n'est pas si simple avec le Zero W.

Est-ce que cela arrive à tout le monde Raspberry Pi? Comment la musique est-elle jouée? (Pi Hat DAC, cartes son, BCM?) Pourquoi utilisez-vous le Wifi?

Parce que je n'ai eu aucun problème avec mon Pi3

Seulement un problème lorsque les deux vont. WiFi transmettant activement, puis essayez d'utiliser Bluetooth. Bluetooth + LAN ne pose aucun problème. Ainsi, la plupart des gens et des applications ne verront pas le problème.

J'ai ajouté un récepteur WiFi secondaire et l'ai rendu principal et en utilisant le WiFi intégré comme récepteur Bluetooth. C'est un moyen le moins cher de faire fonctionner cela.

Bluetooth + LAN ne pose aucun problème.

Veuillez me montrer le port LAN sur le Pi0W.

Quelqu'un a-t-il essayé de renommer pulseaudio pour avoir une priorité plus élevée?

Oui, j'ai essayé avec une priorité plus élevée sans différence perceptible dans le résultat.

Salut,
Pouvez-vous s'il vous plaît me faire savoir une configuration réalisable si vous en avez une pour
le problème ci-dessus, c'est-à-dire Wifi - nécessaire, couplage de haut-parleurs Bluetooth dans A2DP
mode.
D'après votre profil, il semble que vous ayez beaucoup joué dans ce domaine
surface.

Merci.

À votre santé,
Pradeep
http://pradeepclicks.com/

Le lundi 6 mars 2017 à 21:29, Brett Reinhard [email protected]
a écrit:

Quelqu'un a-t-il essayé de renommer pulseaudio pour avoir une priorité plus élevée?

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/raspberrypi/linux/issues/1402#issuecomment-284439625 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ADb1rV3_oFd2_qM8-2yHoDdLGeFK3d5dks5rjC1ngaJpZM4IExoX
.

J'essaye également de résoudre ce problème. L'agitation semble changer un peu entre les différents haut-parleurs / écouteurs BT, mais il est toujours là en utilisant un dongle WiFi et en désactivant le WiFi intégré. Même en utilisant un dongle BT, le saccadé est toujours présent lors de la lecture d'un mp3 local ou de l'utilisation de Pithos (Pandora). J'ai également utilisé un fichier mp3 à débit binaire inférieur et le clapiness s'est amélioré.

J'ai téléchargé quelques exemples de fichiers de 16 à 64 kbps et les ai lus en utilisant VLC sur RPi3. J'utilise pulseaudio et je me connecte à des écouteurs Bluetooth bon marché.
http://www.digitalprosound.com/Htm/WebAudio/2000/Oct/MP3bitrates3.htm

Avec uniquement une activité WiFi en arrière-plan, chaque fichier est lu, mais présente une certaine agitation avec l'augmentation du débit binaire. Ensuite, j'ai exécuté une mise à jour apt-get et pendant son exécution, j'ai joué le fichier 16k. Très saccadé. Pareil pour les autres. En fait, l'activité wifi avait plus d'effet que le débit du fichier.

Maintenant, connectez un dongle WiFi et désactivez le Wifi intégré (sudo ifdown wlan0). Réessayer.
Tous les fichiers sont parfaitement fluides. Qu'en est-il lors d'un téléchargement via Wifi? Aussi fluide à 64 kbps.
Vous utilisez Pithos (Pandora)? Lisse. Ce n’était pas le cas hier soir, je ne suis donc pas convaincu d’avoir une solution solide.

Je rencontre le même problème.

Je l'ai résolu en utilisant un dongle Bluetooth qui est un succès complet.
Technologies enfichables USB-BT4LE

Toujours pas satisfait de cela, quel est l'intérêt d'avoir des fonctionnalités qui ne peuvent pas être utilisées.

Une chose que vous devez vous assurer est que vous désactivez la numérisation Bluetooth (scan désactivé) lorsque vous êtes dans l'invite bluetoothctl. Cela a résolu mon problème et j'ai pu diffuser correctement avec un Pi Zero W, Pi3, en utilisant le wifi / BT intégré et le Pi Zero + Redbear IoT PiHat.

@Michiman : Je suis sûr à 100% que je l'ai essayé sans scanner en même temps. avait encore le problème. J'utilise cependant rpi3.

+1
même ici, c'est certainement la combinaison du wifi embarqué + bluetooth.
Configuration: pi zéro w + phat dac

Activation Bluetooth + wifi à bord -> le son bégaie très mal
wifi embarqué désactivé -> l'audio joue parfaitement sans saccade

Je suppose que je dois commencer à étudier comment tout cela fonctionne à un niveau bas - ce qui constitue un beau défi pour apprendre cela correctement

J'ai également eu de terribles problèmes de son en essayant de diffuser de l'audio à l'aide de didacticiels a2dp basés sur pulseaudio.
J'ai essayé des suggestions de réglage des tailles de tampon et de désactivation du WLAN interne.
La qualité du son s'est grandement améliorée, mais toujours pas au point que je l'utiliserais comme un véritable appareil d'écoute - au mieux, j'aurais un pop ou un bégaiement toutes les quelques secondes.

J'ai trouvé un autre projet github qui résout le problème en évitant complètement pulseaudio:
https://github.com/lukasjapan/bt-speaker
Après avoir désactivé le WLAN interne, l'audio est tout à fait raisonnable en utilisant cette méthode, et pas besoin de se connecter au démarrage (je l'ai en arrière-plan de mon image de retropie).

@maklotski , Nous avons déjà établi que le problème est causé lorsque le Wi-Fi et le Bluetooth sont

Nous avons publié toutes les informations utiles dont nous disposons, c'est-à-dire pas beaucoup. Cypress (anciennement Broadcom) a deux piles de pilotes parallèles - dhd et brcmfmac. Ils sont censés être sur le point de terminer un pilote dhd mis à jour qui améliore la coexistence, mais a) il est toujours en cours de test et b) nous utilisons brcmfmac. Dès qu'il y aura un pilote brcmfmac amélioré, nous le sortirons.

Le simple fait d'ajouter +1 à ce problème ne sert à rien. Cela ne fait que rallonger la liste des commentaires sans raison. Dès que nous aurons des informations, elles seront publiées.

+1 pour continuer à mettre cela sur le radar et, espérons-le, augmenter la priorité
pour une solution

Ce fil de discussion github sera mis à jour lorsque des informations pertinentes sur le problème seront disponibles. Nous sommes quelque peu dépendants de Broadcom (maintenant Cypress) pour fournir des mises à jour de pilotes car la prise en charge de la coexistence sur la puce est fonction du micrologiciel ou de la configuration du micrologiciel de la puce.

Dégrader le rapport signal / bruit du thread avec des réponses spammées est juste irritant. Les commentaires qui n'apportent rien à la discussion entourant l'enquête ou la résolution du problème sont susceptibles d'être supprimés sommairement.

J'ai écrit un petit script pour utiliser inotify pour activer et désactiver wlan0 si bluetooth se connecte / se déconnecte. Ok c'est
une solution de contournement mais je peux vivre avec.

`#! / bin / bash

alors que c'est vrai
faire
RES = inotifywait -q -e CREATE,DELETE /dev/input/
case "$ RES" dans
"/ dev / input / DELETE event1")
ifconfig wlan0 up
;;
"/ dev / input / CREATE event1")
ifconfig wlan0 vers le bas
;;
esac
terminé &
»

Alors, voici le travail (tout le temps) autour de moi que j'aimerais partager au prix de se moquer.
Exécutez pacat /dev/zero en arrière-plan
Maintenant, jouez un peu d'audio et après que le crépitement s'arrête + -30 secondes, jouez un peu plus d'audio et profitez de la lecture claire jusqu'à ce que vous arrêtiez de pacat.
Si vous vous inquiétez du fait que tous les zéros survolent Bluetooth, envisagez peut-être d'installer "pv" avec:
sudo apt-get install pv
Exécutez ce qui suit en arrière-plan à la place cat /dev/zero | pv -qL 2k | pacat pour limiter les zéros à un certain débit.
Voudrais savoir comment cela fonctionne pour vous.

Intéressant, tout. J'ai travaillé sur un Pi Zero / W sans tête - No X11. Et je peux avoir deux / trois shells en wifi, et Bluetooth est aussi propre que possible. J'ai remarqué qu'une interrogation excessive du périphérique Bluetooth (c'est-à-dire obtenir des informations Bluetooth) provoque un bégaiement. Avez-vous essayé de démarrer en CLI?

Eh bien, je viens de réaliser que le commentaire suivant n'était pas vraiment utile sans contexte. Désolé, j'ai frappé au clavier toute la nuit ----

1 - Pi Zero / W et Pi 3 identiques en termes de Bluetooth / Wifi, du moins en ce qui concerne le noyau.
2 - Exécution de Jessie Lite - récemment mis à jour, et noyau 4.9.29+
3 - Exécution de NetBeans sur le bureau et débogage à distance sur Pi.
4 - Test de stress Fréquence d'images avec un écran TFT --- vraiment le lancement de ce bus SPI.
5 - Interrogation des événements d'entrée pour l'écran tactile et transfert des résultats vers stderr, qui est acheminé vers NetBeans - test de la gigue sur l'écran tactile
6 - Exécution du programme d'exemple mpg123_to_out123 à partir de l'archive tar mpg123 via Bluetooth et lecture de "An Innocent Man" de Billy Joel depuis la carte SD.
7 - Pas de X11 en vue.

Courant aussi lisse qu'une tarte, à saveur de framboise. Cela fait si longtemps que je fredonne Billy Joel dans mon sommeil.
J'ai remarqué que le fait de forcer une requête sur l'état de la connexion Bluetooth rendait les choses mauvaises.

Suggérez d'éliminer autant de code "autre" que possible.

Salut,
il y a certainement un problème sérieux avec le Bluetooth PI (Zero W).

J'ai déplacé un script python qui détecte les téléphones via Bluetooth d'un CHIP vers un Pi Zero W.
Le résultat était fou, il a bloqué tout mon Wi-Fi domestique lors de l'accès au Bluetooth :-(

Le script utilise la commande suivante pour détecter si un téléphone est à portée:
result = bluetooth.lookup_name (mac, timeout = 5)

Je lance cela en boucle avec deux téléphones. La boucle démarre toutes les 15 secondes et teste les deux téléphones.
J'ai d'abord notifié que a) SSH via Wifi ne répondait parfois pas et b) ma lumière LED WiFi ne répondait pas parfois après la configuration du Pi Zero W.
Étrange, alors j'ai essayé de cingler les lumières Wifi, résultat: Timeouts pendant environ 5 secondes toutes les 15 secondes.
Ensuite, j'ai essayé de cingler le PI Zero W: temps de ping d'environ 2000 à 4000 ms pendant ces fenêtres de 5 secondes, parfois même des délais d'attente.

J'ai donc désactivé le script exécutant la détection Bluetooth: tout allait bien.
Redémarrage du script: les délais d'attente se sont produits à nouveau.

C'est fou! La recherche bluetooth pour les téléphones (c'est essentiellement un "êtes-vous là?" À un appareil bluetooth couplé) casse essentiellement tout mon Wifi domestique.
Je sais que Bluetooth et Wifi sont sur la même fréquence. Mais Bluetooth est normalisé pour utiliser des sauts de fréquence étendus pour éviter de telles interférences. Pas si sur le Pi Zero W?

C'est certainement reproductible, essayez simplement le script python ci-dessous.

Ma meilleure estimation sur la raison: la radio Bluetooth perturbe le Wifi, pas l'inverse. La raison pourrait être un problème dans la pile Bluetooth concernant le saut de fréquence. Cela expliquerait également les problèmes audio bluetooth signalés: lorsque le bluetooth reste sur une fréquence, le wifi est plus susceptible de perturber son signal.
Cependant, je me trompe peut-être, je connais assez bien le WiFi car j'ai fait mon doctorat sur un sujet traitant du Phy Layer de Wiifi, mais je ne suis pas un expert du Bluetooth Phy.

Un court script de test python qui reproduit le problème. Envoyez simplement un ping au Pi lors de son exécution.

temps d'importation
importer le bluetooth
mac = "00: 00: 00: 00: 00: 00"
tandis que Vrai:
print ("Rechercher Bluetooth pour% s ..."% mac)
essayer:
result = bluetooth.lookup_name (mac, timeout = 5)
sauf bluetooth.btcommon.BluetoothError comme e:
print ("\ nERORR: échec de la demande Bluetooth, erreur:% s"% e)
print ("Résultat:% s est:% s"% (mac, résultat))
temps de sommeil (15)

Demain, (lundi soir HNE), si vous le souhaitez, je posterai un youtube montrant à quel point cela fonctionne. Cependant, il suffit de doubler / tripler la confirmation (il y a à peine 5 minutes) - les seuls problèmes surviennent lors de "Découvrable" et "Analyse". Si vous rendez votre appareil non découvrable et que vous ne scannez pas activement (découvrant) WiFi et Bluetooth fonctionnent très bien ensemble sur un Pi Zero W.Je reçois un ping constant de 4-5 ms sur WiFi lorsque je suis connecté via Bluetooth et ssh. Besoin de comprendre comment enregistrer le son d'une vidéo YouTube, mais je peux clairement l'entendre sans gigue.

FWIW - Je travaille sur une application Bluetooth Audio, donc cela me préoccupe vraiment. Dans mon application, je sondais les informations de l'appareil connecté pour obtenir RSSI, etc. J'ai dû retirer le sondage, à cause des problèmes déjà remarqués par tant de gens ici.

À moins que vous ne contrôliez toutes les applications de votre session susceptibles de faire un sondage (D-Bus) sur la connexion Bluetooth, vous ne pouvez pas les exclure comme étant complices des problèmes. Je n'utilise pas X11 - je suis donc beaucoup plus proche du matériel et de ce qui se passe. Certes, PulseAudio est toujours une "boîte noire", mais à part ça, je contrôle fondamentalement toute l'affaire et cela fonctionne plutôt bien.

Maintenant, je ne dis pas que le micrologiciel n'a pas de problèmes, mais en réalité, les applications devraient mieux se comporter.

Hey,
Je serais vraiment intéressé par une vidéo youtube si vous avez le temps :)
J'utilise aussi un Pi Zero W, mais quand je désactive le Wifi, il bégaie encore un peu ...

Bonjour, juste une note - ma Zero W souffre du même problème - sauter l'audio BT lors du streaming par wifi - même pour la version 9.1 / Stretch de Raspbian

Cypress espère améliorer la «coexistence» entre WiFi et BT, mais ils se sont d'abord concentrés sur certains problèmes de stabilité WiFi.

Salut, des mises à jour à ce sujet?

En commençant par l'image Raspbian Stretch la plus récente, exécutez:

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

Cela entraînera un nouveau micrologiciel Bluetooth et un BlueZ mis à jour qui, ensemble, devraient améliorer la coexistence WiFi et Bluetooth.

Pendant que vous y êtes, obtenez le dernier noyau pour une fiabilité Bluetooth améliorée:

sudo apt-get install raspberrypi-bootloader raspberrypi-kernel

J'aimerais voir une vidéo côte à côte des performances de BT / WiFi
ensemble. Si quelqu'un n'en a pas fait, je vais devoir y travailler.

Le 7 novembre 2017 à 12 h 15, "Phil Elwell" [email protected] a écrit:

Pendant que vous y êtes, obtenez le dernier noyau pour un Bluetooth amélioré
fiabilité:

sudo apt-get install raspberrypi-bootloader raspberrypi-kernel

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/raspberrypi/linux/issues/1402#issuecomment-342554756 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AZCYY6u0Q45M19rAdGFM0WP4q6VXP0Zeks5s0JBOgaJpZM4IExoX
.

@pelwell J'ai mis à niveau bluez bluez-firmware raspberrypi-bootloader raspberrypi-kernel vers la dernière version, comme vous l'avez conseillé.

Cependant, je suis toujours confronté à un problème avec le son diffusé via Bluetooth vers le raspberry zéro W lorsque le wifi est activé. Si j'arrête le wifi ( sudo iwconfig wlan0 txpower off ), cela fonctionne bien et plus aucun crépitement ne se produit.

Faites-moi savoir si je peux vous aider.

J'utilise bt-speaker. Problème lié signalé ici: https://github.com/lukasjapan/bt-speaker/issues/4

Êtes-vous en train de dire que vous n'avez vu aucune amélioration?

malheureusement, aucune amélioration :(

@pelwell Juste pour que vous sachiez, voici les versions installées:

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

Quelqu'un a-t-il ce même type de problème avec les contrôleurs PS3 (via Bluetooth) utilisant Retropie avec le wifi activé sur le rpi 3? J'ai ce qui semble être des interférences aléatoires où parfois les contrôleurs fonctionnent bien et parfois c'est comme si je n'avais rien appuyé du tout. Cela rend un peu difficile de jouer à des jeux de cette façon!

Aujourd'hui, j'ai mis à jour un Pi Zero W à toutes les dernières et je peux confirmer que le problème existe toujours.
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

Le BCM43438 semble avoir des problèmes de connexions multiples, soit avec BT + WiFi, soit avec deux connexions BT:

Lors de la désactivation du WiFi ( ifconfig wlan0 down ou dtparam=pi3-disable-wifi ), l'audio Bluetooth A2DP fonctionne très bien. Cependant, lorsque deux appareils sont connectés, le son commence à bégayer.

Avec un adaptateur Bluetooth USB externe, plusieurs appareils peuvent se connecter via A2DP et diffuser de l'audio, un événement simultanément.

Donc je suppose que c'est une limitation de la puce, pas une chose logicielle ... (mais j'aimerais avoir tort dans une future mise à jour du noyau)

Assurez-vous que vous utilisez le dernier firmware BT ( sudo apt-get update; sudo apt-get install bluez-firmware ) - il y a eu quelques améliorations.

Je l'ai fait pour la dernière fois il y a 2 jours, cela a-t-il changé depuis?

-Ron

De: Phil Elwell [email protected]
Envoyé: mercredi 24 janvier 2018 05h32
À: raspberrypi / linux
Cc: Ron Kuper; Manuel
Objet: [Externe] Re: [raspberrypi / linux] L'audio Bluetooth Pi3 bégaie avec le Wi-Fi activé (# 1402)

Assurez-vous que vous utilisez le dernier firmware BT (sudo apt-get update; sudo apt-get install bluez-firmware) - il y a eu quelques améliorations.

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, visualisez-le sur GitHub https://github.com/raspberrypi/linux/issues/1402#issuecomment-360088465 , ou désactivez le fil https://github.com/notifications/unsubscribe-auth/AC8KdHhcuhMFBE5j42nTMfahwocks5NJ .

Non - ce sera le dernier (1.2-3 + rpt1).

Merci! En attendant, j'ai acheté un dongle wifi USB comme solution de contournement.

Est-ce que quelqu'un sait si le pilote du chipset est censé (en théorie) prendre des mesures pour éviter les interférences RF entre ces 2 radios?

-Ron

De: Phil Elwell [email protected]
Envoyé: mercredi 24 janvier 2018 07:20 AM
À: raspberrypi / linux
Cc: Ron Kuper; Manuel
Objet: [Externe] Re: [raspberrypi / linux] L'audio Bluetooth Pi3 bégaie avec le Wi-Fi activé (# 1402)

Non - ce sera le dernier (1.2-3 + rpt1).

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, visualisez-le sur GitHub https://github.com/raspberrypi/linux/issues/1402#issuecomment-360113610 , ou désactivez le fil https://github.com/notifications/unsubscribe-auth/AC8KdIfVVwDf2lOlcGQxxTppx5Ax5Awk .

Il est censé le faire (il existe un canal de coexistence entre ce qui est essentiellement deux appareils séparés dans le même package), et ce firmware est une amélioration significative par rapport au firmware d'origine, mais le partage d'une antenne semble être un défi.

@spalthammer a écrit un script qui servirait de solution de contournement intéressante:

J'ai écrit un petit script pour utiliser inotify pour activer et désactiver wlan0 si bluetooth se connecte / se déconnecte. Ok c'est
une solution de contournement mais je peux vivre avec.

`#! / bin / bash

alors que c'est vrai
faire
RES = inotifywait -q -e CREATE, DELETE / dev / input /
case "$ RES" dans
"/ dev / input / DELETE event1")
ifconfig wlan0 up
;;
"/ dev / input / CREATE event1")
ifconfig wlan0 vers le bas
;;
esac
terminé &
»
Quelqu'un peut-il expliquer à un débutant comment mettre en œuvre ce script? Cela fonctionnerait très bien pour moi car je n'ai pas besoin de wifi pendant la lecture du bluetooth. Cependant, je souhaite toujours pouvoir utiliser ssh / vnc pour mon Pi3 lorsque le périphérique BT se déconnecte.

@lexanix

installer inotify
cmd: sudo apt-get install inotify-tools
cp inotify.txt en /etc/inet.d/inotify (renommez inotify.txt en inotify!)

inotify.txt

le rendre exécutable
cmd: sudo chmod u + x /etc/init.d/inotify
créer des liens symboliques pour démarrer le script au démarrage
cmd: sudo update-rc.d inotify par défaut

J'espère que cela t'aides.

@spalthammer merci pour votre réponse! malheureusement, cela ne semble pas fonctionner pour moi. J'ai fait tout ce que tu as dit mais rien ne se passe. inotify-tools est à jour sur mon Pi3.

ce que j'ai essayé de faire:
(J'ai évidemment changé la faute de frappe de "inet.d" en init.d)
- l'a rendu exécutable avec chmod + x seulement puisque u + x ne fonctionnait pas
-essayé d'exécuter le script directement à partir du terminal (sans redémarrage), ce qu'il a fait depuis que j'ai ajouté une ligne pour renvoyer un écho et cela a fonctionné
-fait démarrer au démarrage de /etc/rc.local
Cependant, le wifi reste toujours activé lorsque je connecte mon téléphone via bluetooth ...

J'utilise la dernière version de Raspbian. Mon téléphone diffuse de la musique sur le Pi via BT, qui émet ensuite un signal FM sur le GPIO. Pendant ce temps, je n'ai pas besoin d'activer le wifi car la musique commence à bégayer. Cependant, pour pouvoir toujours me reconnecter à mon Pi avec SSH / VNC après avoir désactivé le wifi, j'ai créé un petit script "sudo ifconfig wlan0 up" qui le réactive automatiquement après avoir coupé l'alimentation et le laisser redémarrer. Cela semble fonctionner pour le moment, mais j'aimerais que le script inotify beaucoup plus élégant s'exécute jusqu'à ce que nous sachions ce qui ne va pas avec notre chipset BT + WiFi.

@lexanix ,
désolé pour la faute de frappe.
sudo chmod u+x /etc/init.d/inotify devrait fonctionner. Veuillez vous assurer que /etc/init.d/inotify est détenu et exécutable par root.
Si vous avez plus d'un périphérique d'entrée connecté, disons clavier, souris et carte son USB, le numéro du périphérique d'entrée peut être différent. Dans le script, j'attends des événements sur input1, ce qui correspond à ma configuration. Veuillez arrêter le script avec
sudo killall -9 inotify
et courir
sudo inotifywait -q -e CREATE,DELETE /dev/input
Connectez-vous au périphérique Bluetooth et notez le numéro de votre périphérique d'entrée. Modifiez le script et redémarrez.
J'ai revérifié le script. Même si ce n'est pas parfait, cela fonctionne comme prévu.

Cordialement

La connexion BT n'est pas stable pendant la lecture A2DP. BT est souvent déconnecté et nécessite un redémarrage du système pour récupérer.
pouvez-vous donner la solution.

@spalthammer super! votre script fonctionne comme prévu
solution parfaite pour moi (Zero W avec haut-parleur phat; utilise maintenant les interfaces Bluetooth et WiFi internes en alternance)
plus de fissures pendant la lecture de la musique :-)

Est-ce que ce sera mieux avec le nouveau Raspberry Pi 3 B +?

@spalthammer

Merci pour l'excellente solution de contournement. C'est juste ce dont j'ai besoin.

Même si je n'ai qu'une seule connexion Bluetooth, j'obtiens ce qui suit quand je le fais

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

Donc, comme vous l'avez suggéré, j'ai édité inotify et changé de event1 en event0. Cela fonctionne très bien maintenant!

Mais je m'inquiète de ce changement. Si je n'ai qu'une seule connexion BT, sera-ce toujours event0?

Merci!

@davthomaspilot ,

le nombre X dans eventX dépend du nombre de périphériques d'entrée et non du nombre de connexions Bluetooth. Donc, à moins que vous ne changiez votre configuration matérielle, par exemple si vous n'ajoutez pas d'autre périphérique d'entrée tel qu'une carte son USB ou un clavier, le numéro ne devrait pas changer. Si vous souhaitez en savoir plus sur les périphériques d'entrée connectés, la commande:

cat /proc/bus/input/devices

vous donnera un aperçu.

Ragards.

Cette solution de contournement a très bien fonctionné pour moi! Mais, il semble que je n'en ai plus besoin, pour une raison quelconque ...

Je viens de recevoir un autre pi zéro w. Téléchargé l'image de Jessie Stretch et fait la mise à jour, mise à niveau. J'utilise un pHat DAC et les instructions de configuration Bluetooth à partir d'ici:

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

Est-il possible qu'il y ait un correctif que j'ai choisi dans la mise à niveau ou la mise à jour? Ou peut-être que mon nouveau rpi a un correctif matériel?

Je clone l'image sur mon pi qui ne bégaye pas et je vais l'essayer sur celle qui nécessitait la solution de contournement de Spalthammer. Et, je vais essayer l'image qui est dans le rpi bégaiement sur le nouveau matériel, et désactiver la solution de contournement pour voir si le nouveau matériel bégaie avec cette image.

J'ai trouvé que je n'ai le problème que si je laisse bluetoothctl en cours d'exécution. Sur le nouveau matériel / "logiciel" et l'ancien, je n'obtiens aucune interruption du flux bluetooth A2DP sauf si je suis en bluetoothctl.

C'est stretch-lite, sans impulsion audio. C'est peut-être important.

@pelwell , Une idée si cela est éventuellement résolu dans le cadre du nouveau firmware WiFi de Cypress comme mentionné ici?
https://www.raspberrypi.org/forums/viewtopic.php?f=117&t=208090
Cordialement,

@StudentSA Ça n'en a pas l'air. Du moins pas entièrement. Je rencontre ce problème sur un Zero W exécutant 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

Peut-être l'un de ces problèmes qui ne sera jamais résolu ...

J'ai décidé de creuser un peu les pilotes. La lecture du code m'a donné un aperçu de certains des paramètres de module pris en charge, et avec une certaine expérimentation et une approche fusil à pompe, il semble que le bluetooth + wifi fonctionne parfaitement en conjonction les uns avec les autres.

J'ai pu effectuer un test de vitesse à partir du pi via le wifi, tandis que mon téléphone diffusait de l'audio A2DP via le pi, et je n'ai pas eu un seul problème.

J'ai créé un fichier /etc/modules.d/bt-wifi-fix.conf

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

debug=0x00000004 active la journalisation du niveau d'informations, ce qui n'est pas vraiment nécessaire.

fcmode=2 semble activer une sorte de contrôle de flux matériel, ce qui semblait améliorer un peu les choses, mais toujours pas génial.

feature_disable=0x96 est l'option qui semblait vraiment résoudre le problème. Je ne suis pas certain, mais je pense que 0x96 essaie de désactiver toutes les fonctionnalités optionnelles, d'où la raison pour laquelle j'ai dit «approche fusil à pompe» ci-dessus. Avec un peu de patience, il est probablement possible de réduire cela à un petit sous-ensemble de fonctionnalités.

Jusqu'à présent, cela a parfaitement fonctionné pour moi - je ferai rapport si je suis en mesure de préciser davantage les choses.

EDIT: Je reçois un peu de pépin lorsque je lance un flux pour la première fois, mais absolument rien qui semble dépendre du fait que j'utilise le wifi ou non.

C'est un excellent point de données, merci de votre recherche et veuillez nous tenir au courant de tout progrès ultérieur.

@pelwell Phil, avez-vous vu ça? Cela vaut peut-être la peine de faire un rapport à Cypress.

Cela semble très simple - si Cypress en est satisfait et si efficace, nous pouvons en faire les valeurs par défaut pour les noyaux Pi.

Est-il suffisant de créer simplement /etc/modules.d/bt-wifi-fix.conf avec le contenu que vous avez indiqué? Ou dois-je changer quelque chose d'autre pour qu'il prenne effet?

Créez simplement le fichier comme décrit et redémarrez.

Ok, j'ai googlé et j'ai trouvé des trucs pour /etc/modules-load.d, mais pas /etc/modules.d

J'ai ajouté le fichier sur un Pi Zero W.Je vais diffuser sur bluetooth pendant un moment et voir si j'entends des bégaiements lorsque le wifi est connecté.

Existe-t-il un moyen de vérifier que bt-wifi-fix.conf a été utilisé, autre que de tester "pas de hoquet"?

Merci!

Si vous incluez options brcmfmac debug=0x00000004 (sans le commentaire # ) alors vous devriez voir une sortie de diagnostic dans le journal du noyau, comme vu par dmesg .

Ok, j'ai essayé ceci:

 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

Alors, fais le

gestion de l'alimentation désactivée

les messages indiquent que le .conf est en cours de récupération?

Sinon, y a-t-il autre chose pour lequel je peux grep?

Testé sur un ZeroW exécutant un noyau 4.14.41 (OS personnalisé) Bien que bien meilleur, il y a encore des bégaiements ..... mais presque tolérables.

J'ai exécuté iperf3 sur mon serveur tout en jouant au flux a2dp .... le wifi poussait
environ 30MBit / s sur iperf3.

Prévoit de tester sur un pi3 et pi3b + (Le 3b + peut déjà bien jouer si le wifi est connecté sur le canal 5Ghz)

@davthomaspilot J'essaie juste moi-même maintenant, et le contenu du fichier suggéré semble correct, mais bien que le nom du répertoire semble familier, il n'est pas présent sur mon système Raspbian - /lib/modprobe.d est l'habituel (et peut-être _correct_) place - donc je suggère d'utiliser le nom /lib/modprobe.d/bt-wifi-fix.conf fichier

Commencez par les lignes fcmode et feature_disable commentées et récupérez la sortie de dmesg | cut -c16- | grep brcmfmac . Décommentez ensuite l'un d'entre eux ou les deux, redémarrez et comparez la sortie dmesg (et la qualité du streaming).

Merci! Je ferai ça.

J'espère que cela aide plus que de faire "iwconfig wlan0 power off" dans /etc/rc.local.

Avec l'économie d'énergie wifi désactivée, les bégaiements de streaming ne se produisent peut-être qu'une fois toutes les minutes ou deux. C'est avec rien d'autre qu'une session ssh sur le wifi.
Il faudra quelques "statistiques" pour voir s'il y a une amélioration supplémentaire. Je vais essayer le Pi Zero W.

Voici une comparaison entre les lignes commentées et non (en utilisant /lib/modprobe.d, PAS /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)

Test de la qualité du streaming maintenant ...

Il bégaye toujours. Il est vraiment difficile de dire si c'est nettement mieux que ce que j'ai. Un bégaiement une fois toutes les minutes ou deux.

Encore une fois, c'est avec le wifi activé, mais pratiquement pas de trafic wifi.

Actuellement, ma solution de contournement consiste à désactiver le wifi lorsque le bluetooth est connecté. Je ne me soucie vraiment pas des bégaiements lorsque je suis connecté au wifi, mais ce serait bien de me connecter au wifi sans avoir à déconnecter Bluetooth au préalable.

Test avec un pi3B + sur un canal 2.4Ghz.

Le paramètre "options brcmfmac fcmode = 2" plante le pilote wifi sur un pi3B + dès que BT commence à transmettre des données via la connexion Bluetooth. Utilisation d'un profil A2DP.

Je cours avec seulement les options brcmfmac feature_disable = 0x96 sur le pi3B + et c'est assez stable, à moins que je ne pousse la connexion wifi avec iperf, alors j'obtiens un bégaiement significatif. Aucun effet secondaire apparent avec ce paramètre sur un canal 5Ghz. Le Bluetooth est très stable dans ce cas, et l'iperf3 poussant 120Mbit / s

Donc, ne pas jeter une clé dans les travaux, mais honnêtement, je ne peux pas reproduire ce problème sur la dernière img de Stretch avec la mise à jour du firmware bluez et la mise à jour bluetoothctr. J'ai 2 cartes SD, une depuis la publication initiale en avril 2017 avec Jessie et PulseAudio. et j'ai créé aujourd'hui une 2ème carte SD exécutant Stretch (9.4) et ALSA blue.

Sur Stretch, les choses sont parfaites, je joue un flux en ligne (c'est-à-dire en utilisant le wifi) via mon haut-parleur Bluetooth à 100%. L'ancienne carte avec Jessie crépite toujours mal lorsque Wlan0 est activé.

Merci à ce mec qui a détaillé quelques astuces dans la configuration:
Michel

J'ai testé en utilisant vlc, vous devez donc spécifier quel périphérique alsa utiliser comme suit:
--aout = alsa --alsa-audio-device = "bluealsa"

Quelqu'un peut-il essayer cela à partir d'une nouvelle installation et vous conseiller.

bluez 5.43-2 + rpt2 + deb9u2 armhf
bluez-firmware 1.2-3 + rpt6 tous
bluealsa 0.7 armhf
bluetoothctl: 5,49
raspberrypi-bootloader 1.20180417-1 armhf
raspberrypi-kernel 1.20180417-1 armhf

n'oubliez pas de démarrer bluealsa après un redémarrage ou de le démarrer automatiquement: sudo systemctl enable bluealsa)

Comment avez-vous installé bluetoothctl: 5.49? J'espère ne pas compiler à partir du code source.

Yip, De la source (selon le lien partagé) pourquoi l'inquiétude autour de cela?

J'aime juste avoir des mises à jour en utilisant le référentiel, également pour éviter les paquets nécessaires uniquement pour le construire. Où se trouve le lien dans votre message?

Il existe en fait une version 5.50 publiée il y a 7 semaines. Si vous empruntez cette voie, cela vaut peut-être la peine d'essayer. Mais oui, nous devrons attendre la version 5.49+ pour entrer dans le flux officiel apt-get.

Je peux confirmer qu'il n'a pas de bégaiement avec Bluez 5.50.

Cool. Je vais examiner ce qu'il faudrait pour mettre à jour la version Raspbian.

Voici les étapes:

1. Installez les dépendances.
   sudo apt install libdbus-1-dev libglib2.0-dev libudev-dev libical-dev libreadline-dev

1. Téléchargez la dernière version du code source BlueZ.
   wget http://www.kernel.org/pub/linux/bluetooth/bluez-5.50.tar.xz

2. Décompressez le fichier téléchargé.
   tar -xf bluez-5.49.tar.xz && cd bluez-5.50/

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

4. Compilez le code source.
   make -j4

5. Installer.
   sudo make install

6. L'utilisateur doit être ajouté au groupe Bluetooth.
   sudo adduser pi bluetooth

7. Le fichier de configuration Dbus Bluetooth qui a été écrasé dans l'installation de BlueZ doit être restauré.
   sudo nano /etc/dbus-1/system.d/bluetooth.conf

Ajoutez ceci dans la section <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"/>

et ceci après:
<!-- allow users of bluetooth group to communicate -->
<policy group="bluetooth">
<allow send_destination="org.bluez"/>
</policy>

1. Redémarrez Raspberry Pi
   sudo reboot

@amilino Ne fonctionne toujours pas pour moi. Toujours bégayant avec le wifi activé et lorsqu'il est éteint. J'ai essayé à peu près tout dans ce fil, même passé d'un rpi b + avec un dongle bt à un rpi 3 b + avec bluetooth intégré et il y a toujours du bégaiement.

Pas vraiment bégayant, en fait. Il semble obtenir un morceau de données, le lire trop vite avec des bits manquants, puis s'asseoir et attendre le morceau suivant.

J'ai la même configuration que @StudentSA mentionnée, sauf le dernier Bluez 5.50. J'ai également suivi ce tutoriel: https://gist.github.com/mill1000/74c7473ee3b4a5b13f6325e9994ff84c. J'ai joué les mêmes chansons qui bégayaient auparavant et maintenant elles fonctionnent sans problème.

@amilino a parfaitement fonctionné, merci.

Le seul effet secondaire de ce didacticiel est que l'audio n'est pas lu si vous connectez une machine Linux sur RPI Bluetooth. Si quelqu'un connaît un meilleur tutoriel, merci de me le faire savoir.

Cypress s'est penché sur les interférences WiFi / BT et a mis au point de nouveaux paramètres de fichier "NVRAM" qui, selon eux, ont "complètement corrigé le bégaiement audio". Les mêmes paramètres peuvent être utilisés sur le 43430 (3B, ZeroW) et le 43455 (3B +).

1. Localisez votre fichier texte "NVRAM" - il est dans /lib/firmware/brcm/brcmfmac<dev>-sdio.txt , où <dev> est respectivement 43430 ou 43455. Faites une copie de sauvegarde dans un endroit sûr pour faciliter l'annulation des modifications (ou récupérer après une erreur).

2. Ouvrez le fichier dans un éditeur de texte, faites défiler vers le bas (uniquement par souci de propreté - ces paramètres pourraient probablement aller n'importe où) et ajoutez ce qui suit:

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

3. Redémarrez.

Comme il m'a été expliqué, ces paramètres permettent collectivement à Bluetooth plus de temps d'antenne en permettant au WiFi de dormir plus longtemps et en réduisant le temps maximum que Bluetooth peut attendre.

Veuillez rapporter vos résultats, qu'ils soient positifs ou négatifs, pour nous aider à décider s'il faut en faire les nouvelles valeurs par défaut.

J'ai suivi ce fil avec intérêt. J'utilise un Pi ZeroW / Raspbian Lite pour lire des flux Internet via bluealsa vers un haut-parleur Bluetooth utilisant Mopidy. Jusqu'à aujourd'hui, rien dans ce fil n'a résolu le problème du bégaiement.

bluez 5.50 - aucune différence
désactivation du WiFi et utilisation d'un adaptateur Ethernet USB - certains changent mais bégayent toujours toutes les quelques minutes

Changer les paramètres NVRAM - semble parfait jusqu'à présent. Je suis de retour à l'utilisation du WiFi et il n'y a pas de bégaiement dans l'audio Bluetooth. Toujours en utilisant bluez 5.50. Je ferai rapport si je bégaie.

Résultats positifs à ce jour. J'utilise également Bluez 5.50 également. Carte - RPi3

J'ai supprimé les paramètres modprobe précédents qui ont été présentés comme une solution. Jusqu'à présent, pas de bégaiement. En utilisant iperf3, vous pouvez certainement le voir voler du temps à la radio wifi. Mais pas de bégaiement, même lorsque vous transmettez des données supplémentaires.

Lors de la lecture 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

Arrêt de la lecture et déconnexion du haut-parleur.

[ 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 désactivé via 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

Fonctionne pour moi raspi 3B, pas de bégaiement, même en déplaçant un gros fichier via wifi tout en jouant de l'audio (a2dp), mais je vois des tonnes de
"Bluetooth: hci0: échec du réassemblage du cadre (-84)" en millisecondes!

$ 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)

J'essaye ça depuis quelques heures maintenant. C'est mieux qu'il ne l'était, mais ce n'est pas parfait. J'obtiens maintenant, souvent 20 à 30 minutes de lecture continue, mais ensuite le bégaiement recommence et ne disparaîtra pas unitl J'arrête et redémarre le flux audio. De plus, ma session ssh s'arrête un moment lorsque le bégaiement commence. Ce n'est pas une mise en mémoire tampon audio, car j'ai mis la journalisation dans mon lecteur pour me dire quand elle est mise en mémoire tampon.

Peut-être devriez-vous passer au RPi3 b +, je n'ai aucun problème.

Peut-être devriez-vous passer au RPi3 b +, je n'ai aucun problème.

Ce n'est pas exactement le but, n'est-ce pas? On a dit que les changements "corrigeaient complètement" le bégaiement audio. Je signale simplement que cela ne semble pas être le cas. Le 3B + utilise un chipset différent du W, donc peut-être que les paramètres doivent être légèrement modifiés.

Oui, je suis d'accord, mais en regardant le sujet du problème, il est lié à RPi3. Cette discussion est de toute façon trop longue, peut-être qu'il serait bon d'ouvrir un nouveau numéro distinct lié à Pi W.

Cette solution fonctionne également pour un ZeroW. Je joue depuis plus de 2 heures sans problème.

Je pense que les problèmes que j'ai rencontrés sur ZeroW sont probablement dus au fait que le Bluetooth n'a pas tout à fait la même portée que le Bluetooth sur mon iMac. En rapprochant le haut-parleur du Pi, je joue maintenant à la radio Internet depuis 4 heures sans problème. Je vais devoir re-situer le Pi pour que le signal atteigne la cuisine :)

Merci pour tous les commentaires, qui suggèrent que ces paramètres sont au moins une grande amélioration sans régressions. N'hésitez pas à intervenir si vos expériences suggèrent le contraire, mais je prévois d'en faire les nouvelles valeurs par défaut.

Je peux ajouter une autre observation avec un résultat positif. J'utilise simultanément Bluetooth et Wi-Fi sur ma ZeroW depuis environ une heure maintenant sans bégaiement. Certainement un +1 pour en faire la nouvelle valeur par défaut.

Discutez-vous ici uniquement du problème lorsque rPi est utilisé comme source a2dp ou aussi comme récepteur a2dp?

J'essaie d'utiliser mon rPi3 comme récepteur Bluetooth (c'est-à-dire que j'essaye de lire l'audio de mon téléphone vers mon rPi), et le bégaiement est si intense que vous reconnaissez à peine les chansons jouées. Le Wi-fi n'est pas utilisé. J'ai essayé avec un adaptateur BT externe - pas de chance. Cependant, avec différents adaptateurs bt, le bégaiement était différent (comme si une taille de tampon différente était utilisée).

Dois-je signaler un problème différent?

@edio J'utilise le RPi ZeroW comme évier, diffusant l'audio de mon téléphone vers le RPi via Bluetooth. Jusqu'à hier, j'avais aussi un bégaiement horrible, mais la solution la plus récemment suggérée semble l'avoir résolu.

La solution présentée par @ paul-1 fonctionne pour moi, sur la carte Pi 3+. Je peux utiliser le Wi-Fi normalement et profiter d'un bon flux audio BT

Bonjour,
Quelqu'un a-t-il une idée de la façon d'utiliser la solution NVRAM sur un système Libreelec avec un système squashFS en lecture seule? Si je comprends bien, il est en lecture seule car la prochaine distribution écrase les fichiers système.

@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

Modifiez maintenant le fichier dans /storage/.config/firmware/brcm et redémarrez.

Ou vous pouvez utiliser une version de test récente de LibreELEC 9.0 avec Kodi 18 qui inclut déjà ce correctif: https://forum.kodi.tv/showthread.php?tid=298461

Quelqu'un dans ce fil a-t-il encore des abandons occasionnels après l'application du correctif? Ce n'est pas aussi terrible que le bégaiement que j'ai eu au départ, mais le récepteur bluetooth est tout de même assez inutilisable pour moi, car toutes les deux secondes, j'ai des rafales de clics, chacun correspondant à une série d'enregistrements en sortie pulseudio

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)

et de bluez je reçois

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

J'obtiens des périodes allant jusqu'à une minute de clics et de pops, puis ça disparaît, souvent pendant plusieurs heures. C'est pire lorsque le haut-parleur est plus éloigné du Pi.

@MilhouseVH merci beaucoup pour cela! Cela me permet de voir ici ce que d'autres pourraient trouver utile.

Pour info sur libreELEC (Rpi 3+), le correctif guérit le bégaiement mais introduit un retard audio inacceptable si le film est diffusé via WiFi. Je suppose que c'est une limitation de la plate-forme.

Le retard audio est-il corrigé? Pouvez-vous corriger cela en utilisant le retard audio?
https://kodi.wiki/view/Video_playback#Audio_and_Subtitle_Settings

J'ai déplacé mes données du wlan0 intégré à eth0 et les problèmes de bluetooth ont été résolus. Malheureusement, nous ne pouvons pas avoir notre gâteau et le manger aussi :(
Je devrai essayer la suggestion NVRAM ci-dessus lorsque j'en aurai l'occasion.

Je continue à bégayer après avoir essayé toutes sortes de correctifs sur mon RPi 3+. Désactivera complètement le wifi et utilisera le fil. :(

Bien. Je suis heureux d'être un autre point de données. Le correctif NVRAM a totalement changé mon projet sur un coup de tête en créant une source A2DP en utilisant mon zéro-w. J'ai commencé le projet hier et jusqu'à ce que je tombe sur ce fil, pulseaudio et bluez-alsa étaient complètement inutilisables pendant l'utilisation du wifi. Ne pas avoir de wifi serait également un spectacle. Merci beaucoup aux personnes qui ont fouillé les sources de puces et trouvé le correctif.

J'ai encore un petit bruit et une respiration sifflante lorsque le processeur est surchargé (comme exécuter des mises à jour tout en jouant en Bluetooth), mais à part cela, c'est une machine totalement différente. Pour mémoire, j'utilise Arch 4.14.90, Bluez 5.50 et Pulseaudio 12.2. Cela signifie que cela devrait fonctionner dans un avenir prévisible et n'est pas une solution qui implique d'exécuter de très vieux logiciels incompatibles. <3

J'ai modifié les paramètres dans les fichiers NVRAM:
/usr/lib/firmware/updates/brcm/brcmfmac43430-sdio.txt
/usr/lib/firmware/updates/brcm/brcmfmac43455-sdio.txt

@acegallagher : Je ne comprends pas votre commentaire. Toute explication serait appréciée.

Si vous avez une sorte de solution, quelles sont les étapes nécessaires pour l'avoir sur RPI?

@pelwell

Les fichiers NVRAM mis à jour sont dans les mises à jour de Raspbian depuis août 2018. Vous pouvez également les télécharger directement:

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

Copiez-les dans le dossier / lib / firmware / brcm (vous aurez besoin de sudo cp ... ).

Désolé mais ça ne marche pas. J'ai encore du bégaiement avec le Wifi.

C'est une honte. Avez-vous redémarré après l'installation?

Malheureusement, il y a des limites à ce qui peut être réalisé avec une antenne partagée. Avez-vous essayé de changer la distance entre le Pi et l'AP et / ou le périphérique BT?

Oui, j'ai du mal avec ça depuis quelques mois maintenant. Je suis passé au câble réseau et plus aucun problème.

Salut,
Avec la mise à jour /usr/lib/firmware/updates/brcm/brcmfmac43430-sdio.txt et un ami, et oui j'ai redémarré :-), j'entends toujours des sous-débits sur l'audio USB qui ne sont pas là avec l'audio intégré (toutes les 5 secondes ou plus).
Ne pas utiliser le wifi, tout Ethernet.

Si par contre je fais ifconfig wlan0 en premier, alors tout va bien ...!
oh, non, ce n'est pas le cas. juste beaucoup moins

Vous signalez un audio USB saccadé avec Ethernet dans un problème concernant l'audio Bluetooth avec WiFi?

Oops!

Ce problème Bluetooth + WiFi pose des problèmes avec mon clavier effectuant plusieurs frappes pour 1 touche vers le haut.

@ pratt-jeremy Est-ce un clavier sans fil?

J'ai le même problème. Exécution d'Arch sur un Pi B3, B3 + et Zero. Tous présentent les mêmes symptômes: jeu saccadé avec a2dp. Arch n'a pas mis à jour le micrologiciel comme indiqué ici, mais je l'ai d'abord fait manuellement. Si j'utilise le BT intégré sur ces 3 machines, Bluealsa se plaint de la mémoire tampon en cours d'exécution et il joue de la musique par à-coups. Le journal montre un tampon en cours d'exécution. Si j'utilise une clé USB, tout fonctionne comme prévu. Pouvons-nous essayer autre chose? fwiw, mon noyau est 4.19.32

Il me semble clair que mettre le bluetooth et le wifi sur un RPi, c'est comme faire un sac à main en soie avec l'oreille d'une truie.

L'équipe de développement de Raspberry Pi devrait déclarer que la lecture audio via Bluetooth tout en lisant une vidéo via wifi n'est tout simplement pas prise en charge en raison d'un manque de puissance / bande passante.

Depuis le premier jour, le Pi a été présenté comme un remplacement mis à jour du micro de la BBC, pour enseigner aux enfants dans les écoles. Kodi était un bonus majeur. Je viens de renoncer à cette idée. Je voulais servir des films sur un pi-top avec un lien bluetooth vers le système audio de ma caravane, mais maintenant je branche simplement un disque dur de film dans un port USB. Pas de Wifi, pas de bégaiement. Triste, mais pas trop gênant.

Est-ce la commande appropriée à exécuter pour faire fonctionner le BT intégré?
/ usr / bin / btattach -B / dev / ttyAMA0 -P bcm -S 3000000
Il s'agit de la commande dans le fichier de service pour Arch Linux avec l'installation par défaut de Bluez 5.50

J'ai donc du streaming audio sur un B3 + avec wifi activé et actif (je suis connecté via ssh). J'utilise Arch Linux. J'ai dû installer bluez-utils-compat pour installer la commande hciattach. Je crois que Raspian a déjà ça ...

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

Le package Bluez 5.50 par défaut contient btattach qu'Arch utilise pour activer l'adaptateur BT. Cela n'a pas fonctionné. Tout ce que j'ai, c'est un son bégaiement. Le package pi-bluetooth Arch appelle pour que la commande soit:
ExecStart=/usr/bin/btattach -B /dev/ttyAMA0 -P bcm -S 3000000
La commande qui fonctionnait provenait d'une ancienne version du package:
ExecStart=/usr/bin/hciattach -n /dev/ttyAMA0 bcm43xx 921600 noflow -
Je ne prétends pas savoir si c'est `` correct '' ou quoi que ce soit, juste que c'est la première fois que je joue en Bluetooth en utilisant l'adaptateur intégré.

Juste pour éviter les confusions. La technologie WiFi Broadcom a été achetée par Cypress en juin 2016. Depuis lors

• BCM43438 est CYW43438
• BCM43455 est CYW43455

@ pratt-jeremy Est-ce un clavier sans fil?

@ JamesH65 oui, c'est un clavier Bluetooth, je vois que c'était pour l'audio, mais j'ai pensé que je le mentionnerais. Une fois que j'ai éteint le wifi, le clavier Bluetooth fonctionnait parfaitement. Aucun caractère répété sur lequel je n'ai pas appuyé.

Vraisemblablement, votre distribution est entièrement à jour?

Vraisemblablement, votre distribution est entièrement à jour?

Il était à jour lorsque j'ai posté ici, il est probablement obsolète maintenant car il était en mars. Je vais le mettre à jour et voir si cela se produit toujours.

Sur un RPI4 avec logiciel WiFi bloqué dans rfkill. Toujours saccadé sur Pulseaudio A2DP.