Linux: O áudio do bluetooth Pi3 trava com Wifi habilitado

Eu tenho exatamente o mesmo problema. Desativar WLAN0 corrigiu os problemas de áudio. No entanto, gostaria muito de poder usar o wi-fi ...

O mesmo está aqui. Levei 3 dias, 2 distros para descobrir que era a compilação em wi-fi. O mesmo erro aparece quando eu uso um stick WiFi diretamente nas portas USB. Quando eu uso um cabo de conexão USB com o stick USB, tudo funciona bem. Então eu simplesmente acho que vem da antena construída que os dois serviços de 2,4 GHz interferem um no outro. : - /

Consegui fazer o A2DP funcionar desativando o wi-fi on-board e usando um adaptador USB Wi-Pi, sem nenhum cabo de extensão.

Isso levanta uma questão bastante interessante: o chip WiFi on-board suporta a coexistência de Bluetooth, o driver suporta isso e funciona corretamente? Com base no que vi de várias fontes, há uma latência consideravelmente melhor quando você desativa o WiFi on-board ou desativa o Bluetooth on-board e usa um adaptador USB, e isso me soa como o chip on-board não implementa corretamente a coexistência BT, ou o driver não a suporta adequadamente.

O BCM43438 possui uma interface de coexistência entre as interfaces WiFi e Bluetooth - nenhum suporte de software é necessário.

@Ferroin Pela minha experiência, eu diria / fundamentalmente / sim, embora eu não seja uma fonte autorizada e não exija muito do lado do Bluetooth ... Enquanto desenvolvia aplicativos Bluetooth LE centrais e periféricos em um Pi 3 I execute uma sessão VNC X, 2x sessões SSH e tenha o compartilhamento NFS montado, tudo via WiFi e tudo ok.

+1 sobre isso, como acabei de descobrir esta noite. Retirou wlan0 e o áudio foi reproduzido perfeitamente. Alguém recebeu alguma notícia desde agosto sobre o que está acontecendo aqui e se há uma solução?

+1 eu também, "ifdown wlan0" e pulsos de áudio bem via a2dp

+1, recentemente atualizado hoje, usando um alto-falante bluetooth Anker Sound Core. Funciona perfeitamente se eu desligar o wi-fi, mas é uma grande solução alternativa. É irritante, mas viável para este projeto (OK, tudo bem, vou conectar via HDMI em vez de vncserver. Acho que ), mas também estou esperando uma correção, pois isso limita seriamente minha capacidade de tornar meus projetos móveis. VNCserver é uma obrigação.

1 que me deu dores de cabeça ao descobrir este problema!

Eu precisava de WiFi, então:
1) Use um dongle USB como adaptador WiFi
2) Desative o adaptador WiFi integrado em / etc / network / interfaces

Não há mais problemas de som.

Estou animado para ver qualquer progresso nisso, mas como um lembrete, você pode se inscrever neste tópico e adicionar uma reação à postagem original. Não é recomendado para postar uma resposta de +1.

Concordou que nenhum WiFi está prejudicando a base Pi3. Adicionar um dongle USB derrota um dos grandes ganhos com o Pi3 de WiFi / BT onboard. :-(

Eu também testei o comportamento e enfrento o mesmo problema relatado aqui. Planejando adicionar um adaptador WiFi USB adicional para superar o problema. Espero que o pi suporte um segundo WiFi sem muitos problemas.

Eu acho que o Zero W vai sofrer dos mesmos problemas em relação ao Bluetooth e WLAN, já que está usando o mesmo chip?
Usar dispositivos USB como soluções alternativas não é tão fácil com o Zero W, entretanto.

Isso está acontecendo com Raspberry Pi de todos? Como a música está sendo tocada? (Pi hat DACs, placas de som, BCM?) Para que você está usando o Wifi?

Porque eu não tive problemas com meu Pi3

Apenas um problema quando ambos estão indo. WiFi transmitindo ativamente e, em seguida, tente usar o Bluetooth. Bluetooth + LAN não é problema. Portanto, a maioria das pessoas e aplicativos não verão o problema.

Eu adicionei um receptor WiFi secundário e o tornei primário usando WiFi embutido como receptor bluetooth. Esta é a maneira mais barata de fazer isso funcionar.

Bluetooth + LAN não é problema.

Por favor, mostre-me a porta LAN no Pi0W.

Alguém tentou reniciar pulseaudio para ter uma prioridade mais alta?

Sim, tentei com maior prioridade, sem diferença perceptível no resultado.

Oi,
Você pode me informar uma configuração viável, se você tiver uma para
o problema acima, ou seja, Wifi - necessário, emparelhamento de alto-falantes Bluetooth em A2DP
modo.
Pelo seu perfil, parece que você brincou muito com isso
área.

Obrigado.

Felicidades,
Pradeep
http://pradeepclicks.com/

Na segunda-feira, 6 de março de 2017 às 21h29, Brett Reinhard [email protected]
escrevi:

Alguém tentou reniciar pulseaudio para ter uma prioridade mais alta?

-
Você está recebendo isto porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/raspberrypi/linux/issues/1402#issuecomment-284439625 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/ADb1rV3_oFd2_qM8-2yHoDdLGeFK3d5dks5rjC1ngaJpZM4IExoX
.

Também estou tentando resolver esse problema. A instabilidade parece mudar um pouco entre os diferentes alto-falantes / fones de ouvido BT, mas ainda está lá usando um dongle WiFi e desabilitando o WiFi integrado. Mesmo usando um dongle BT, a distorção ainda está lá durante a reprodução de um mp3 local ou usando Pithos (Pandora). Eu também usei um arquivo mp3 com taxa de bits inferior e a distorção melhorou.

Baixei alguns arquivos de amostra de 16 a 64kbps e os reproduzi usando o VLC no RPi3. Estou executando o pulseaudio e conectando alguns fones de ouvido bluetooth baratos.
http://www.digitalprosound.com/Htm/WebAudio/2000/Oct/MP3bitrates3.htm

Com apenas atividade WiFi em segundo plano, cada arquivo foi reproduzido, mas exibiu alguma instabilidade com o aumento da taxa de bits. Então, eu executei um apt-get update e enquanto ele estava rodando joguei o arquivo de 16k. Muito instável. O mesmo vale para os outros. Na verdade, a atividade do wi-fi teve mais efeito do que a taxa de bits do arquivo.

Agora anexe um dongle WiFi e desative o Wifi integrado (sudo ifdown wlan0). Tente novamente.
Todos os arquivos completamente lisos. Que tal fazer um download por Wifi? Também suave a 64 kbps.
Executando Pithos (Pandora)? Suave. Não foi o que aconteceu na noite passada, então não estou convencido de que tenho uma solução sólida.

Eu experimento o mesmo problema.

Resolvi usando um dongle Bluetooth que foi um sucesso total.
Plugable Technologies USB-BT4LE

Ainda não estou satisfeito com isso, qual é o ponto de ter recursos que não podem ser usados.

Uma coisa que você deve ter certeza é desligar a varredura bluetooth (varredura desativada) enquanto estiver no prompt bluetoothctl. Isso resolveu meu problema e consegui transmitir bem com um Pi Zero W, Pi3, usando o wi-fi / BT integrado e o Pi Zero + redbear IoT PiHat.

@Michiman : Tenho 100% de certeza que experimentei sem digitalizar ao mesmo tempo. ainda tinha o problema. Estou usando rpi3 embora.

+1
mesmo aqui é definitivamente a combinação de wi-fi + bluetooth onboard.
Configuração: pi zero w + phat dac

Bluetooth + wi-fi habilitado a bordo -> o áudio trava muito mal
wi-fi integrado desativado -> o áudio reproduz perfeitamente sem gaguejar

Acho que preciso começar a investigar como tudo isso funciona em um nível baixo - o que é um bom desafio para aprender isso corretamente

Eu também tive problemas terríveis de som ao tentar transmitir áudio usando tutoriais a2dp baseados em pulseaudio.
Tentei sugestões de tamanhos de buffer de ajuste e desabilitação de WLAN interna.
A qualidade do som melhorou muito, mas ainda não a ponto de eu usar isso como um dispositivo de escuta real - na melhor das hipóteses, eu ouviria um estouro ou gagueira a cada poucos segundos.

Eu encontrei outro projeto github que supera o problema evitando inteiramente o pulseaudio:
https://github.com/lukasjapan/bt-speaker
Depois de desabilitar a WLAN interna, o áudio é bastante razoável usando esse método, e não há necessidade de fazer o login na inicialização (eu o tenho em execução no fundo da minha imagem retropie).

@maklotski , Já estabelecemos que o problema é causado quando o Wi-Fi e o Bluetooth estão

Publicamos todas as informações úteis de que dispomos, ou seja, não muitas. Cypress (era Broadcom) tem duas pilhas de driver paralelas - dhd e brcmfmac. Eles estão supostamente perto de terminar um driver dhd atualizado que melhora a coexistência, mas a) ainda está sendo testado eb) usamos brcmfmac. Assim que houver um driver brcmfmac melhorado, iremos implementá-lo.

Simplesmente adicionar +1 a este problema é inútil. Isso apenas torna a lista de comentários mais longa sem motivo. Assim que tivermos alguma informação ela será postada.

+1 para continuar colocando isso no radar e, com sorte, aumentando a prioridade
para uma correção

Este tópico do github será atualizado quando informações relevantes ao problema estiverem disponíveis. Dependemos um pouco da Broadcom (agora Cypress) que fornece atualizações de driver, pois o suporte de coexistência no chip é uma função do firmware do chip ou da configuração do firmware.

Degradar a relação sinal-ruído do segmento com respostas de spam é simplesmente irritante. Comentários que não oferecem nada para a discussão em torno da investigação ou resolução do problema provavelmente serão sumariamente excluídos.

Eu escrevi um pequeno script para usar o inotify para ligar e desligar o wlan0 se o bluetooth se conectar / desconectar. Ok é
uma solução alternativa, mas posso viver com isso.

`#! / bin / bash

enquanto verdadeiro
Faz
RES = inotifywait -q -e CREATE,DELETE /dev/input/
caso "$ RES" em
"/ dev / input / DELETE event1")
ifconfig wlan0 up
;;
"/ dev / input / CREATE event1")
ifconfig wlan0 down
;;
esac
feito &
`

Portanto, aqui está o trabalho (em todo o caso) que eu gostaria de compartilhar à custa de ser ridicularizado.
Execute pacat /dev/zero em segundo plano
Agora reproduza um pouco de áudio e depois que o crepitar parar + -30 segundos, toque um pouco mais de áudio e aproveite a reprodução nítida até que você pare o pacat.
Se você está preocupado com todos os zeros voando sobre o bluetooth, talvez considere instalar "pv" com:
sudo apt-get install pv
Execute o seguinte em segundo plano em vez de cat /dev/zero | pv -qL 2k | pacat para limitar os zeros a uma determinada taxa de bits.
Gostaria de saber como isso funciona para você.

Interessante, todos. Tenho trabalhado em um Pi Zero / W sem cabeça - No X11. E eu posso ter dois / três shells de ssh passando por wi-fi e o Bluetooth é o mais limpo possível. Eu percebi que a pesquisa excessiva do dispositivo Bluetooth (ou seja, obter informações do Bluetooth) causa gagueira. Você tentou apenas inicializar no cli?

Bem, acabei de perceber que o seguinte comentário não foi realmente útil sem contexto. Desculpe, bati no teclado a noite toda ----

1 - Pi Zero / W e Pi 3 idênticos em termos de Bluetooth / Wifi, pelo menos no que diz respeito ao kernel.
2 - Executando Jessie Lite - atualizado recentemente e kernel 4.9.29+
3 - Executando o NetBeans no desktop e depuração remota no Pi.
4 - Teste de estresse Frame rates com um display TFT --- realmente acionando o barramento SPI.
5 - Sondagem de eventos de entrada para tela de toque e resultados de despejo para stderr, que é canalizado para o NetBeans - testando jitter na tela de toque
6 - Executando o programa de exemplo mpg123_to_out123 do tarball mpg123 sobre Bluetooth tocando "An Innocent Man" de Billy Joel no cartão SD.
7 - Nenhum X11 à vista.

Correndo suave como uma torta, com sabor de framboesa. Venho fazendo isso há tanto tempo que murmuro Billy Joel enquanto durmo.
Observei que forçar uma consulta sobre o status da conexão Bluetooth tornou as coisas ruins.

Sugira eliminar o máximo possível de "outros" códigos.

Oi,
definitivamente há um problema sério com o Bluetooth PI (Zero W).

Mudei um script python que detecta telefones via bluetooth de um CHIP para um Pi Zero W.
O resultado foi louco, ele bloqueou todo o meu Wifi doméstico quando o Bluetooth foi acessado :-(

O script usa o seguinte comando para detectar se um telefone está ao alcance:
resultado = bluetooth.lookup_name (mac, tempo limite = 5)

Eu corro isso em um loop com dois telefones. O loop começa a cada 15 segundos e testa os dois telefones.
Notifiquei pela primeira vez que a) SSH por Wifi às vezes não respondia eb) minha luz LED de WiFi às vezes não respondia depois de configurar o Pi Zero W.
Estranho, então tentei fazer o ping das luzes Wifi, resultado: tempos limite de cerca de 5 segundos a cada 15 segundos.
Em seguida, tentei executar o ping do PI Zero W: tempos de ping de cerca de 2.000 a 4.000 ms durante essas janelas de 5 segundos, às vezes até mesmo tempos limite.

Então, desativei o script de detecção de bluetooth: Tudo estava bem.
Reiniciando o script: Os tempos limite ocorreram novamente.

Isso é loucura! A varredura bluetooth para os telefones (é basicamente um "você está aí?" Para um dispositivo bluetooth emparelhado) basicamente quebra todo o wi-fi doméstico.
Eu sei que Bluetooth e Wifi estão na mesma frequência. Mas o Bluetooth é padronizado para usar saltos de frequência extensos para evitar essa interferência. Não é assim no Pi Zero W?

É definitivamente reproduzível, tente o script python abaixo.

Meu melhor palpite sobre o motivo: o rádio bluetooth atrapalha o Wifi, e não o contrário. O motivo pode ser um problema na pilha bluetooth em relação ao salto de frequência. Isso também explicaria os problemas de áudio do bluetooth relatados: quando o bluetooth permanece em uma frequência, é mais provável que o wi-fi perturbe o sinal.
No entanto, posso estar errado, conheço WiFi muito bem porque fiz meu PhD em um tópico que trata da Camada Phy de Wiifi, mas não sou especialista em Phy Bluetooth.

Um pequeno script de teste python que reproduz o problema. Basta executar ping no Pi enquanto o executa.

tempo de importação
importar bluetooth
mac = "00: 00: 00: 00: 00: 00"
enquanto verdadeiro:
imprimir ("Pesquisar Bluetooth para% s ..."% mac)
experimentar:
resultado = bluetooth.lookup_name (mac, tempo limite = 5)
exceto bluetooth.btcommon.BluetoothError como e:
imprimir ("\ nERORR: falha na solicitação de Bluetooth, erro:% s"% e)
print ("Resultado:% s é:% s"% (mac, resultado))
tempo.sono (15)

Amanhã, (segunda-feira à noite EST), se quiser, vou postar um youtube mostrando como funciona. No entanto, apenas confirmação dupla / tripla (apenas 5 minutos atrás) - os únicos problemas ocorrem durante "Detectável" e "Varredura". Se você tornar seu dispositivo não detectável e não ativamente escaneando (descobrindo) WiFi e Bluetooth funcionam bem juntos em um Pi Zero W. Recebo um ping constante de 4-5 ms em WiFi enquanto conectado via Bluetooth e ssh. Preciso descobrir como gravar som para um vídeo do youtube, mas posso ouvi-lo sem interferências.

FWIW - Estou trabalhando em um aplicativo de áudio Bluetooth, então isso realmente me preocupa. No meu aplicativo, eu estava pesquisando as informações do dispositivo conectado para obter RSSI, etc. Tive que tirar a pesquisa, por causa dos problemas já notados por tantas pessoas aqui.

A menos que você esteja no controle de todos os aplicativos em sua sessão que podem fazer uma votação (D-Bus) na conexão Bluetooth, você não pode descartá-los como cúmplices dos problemas. Não estou executando o X11 - portanto, estou muito mais próximo do hardware e do que acontece. O PulseAudio ainda é uma "caixa preta", mas, tirando isso, estou basicamente no controle de todo o negócio e funciona muito bem.

Agora - não estou dizendo que o firmware não tenha problemas, mas na realidade, os aplicativos deveriam se comportar melhor.

Ei,
Eu estaria muito interessado em um vídeo do youtube se você tiver tempo :)
Também estou usando um Pi Zero W, mas quando desabilito o Wifi ele ainda gagueja um pouco ...

Olá, só uma observação - meu Zero W sofre do mesmo problema - pulando áudio BT ao fazer streaming por wi-fi - mesmo para versão 9.1 / Stretch do Raspbian

A Cypress espera melhorar a "coexistência" entre o WiFi e o BT, mas eles se concentraram primeiro em alguns problemas de estabilidade do WiFi.

Olá, alguma atualização sobre isso?

Começando com a imagem Raspbian Stretch mais recente, execute:

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

Isso irá trazer um novo firmware Bluetooth e um BlueZ atualizado que, juntos, devem melhorar a coexistência de WiFi e Bluetooth.

Enquanto você faz isso, obtenha o kernel mais recente para aumentar a confiabilidade do Bluetooth:

sudo apt-get install raspberrypi-bootloader raspberrypi-kernel

Adoraria ver um vídeo lado a lado do desempenho do BT / WiFi
juntos. Se alguém não fez um, terei que trabalhar nisso.

Em 7 de novembro de 2017, às 12h15, "Phil Elwell" [email protected] escreveu:

Enquanto você está nisso, obtenha o kernel mais recente para Bluetooth aprimorado
confiabilidade:

sudo apt-get install raspberrypi-bootloader raspberrypi-kernel

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/raspberrypi/linux/issues/1402#issuecomment-342554756 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AZCYY6u0Q45M19rAdGFM0WP4q6VXP0Zeks5s0JBOgaJpZM4IExoX
.

@pelwell Eu atualizei

No entanto, ainda estou enfrentando problemas com o som transmitido por bluetooth para o raspberry zero W quando o wi-fi está ativo. Se eu desligar o wifi ( sudo iwconfig wlan0 txpower off ), ele funcionará bem e não haverá mais estalos.

Por favor, deixe-me saber se eu puder ajudar em alguma coisa.

Estou usando alto-falante bt. Problema relacionado relatado aqui: https://github.com/lukasjapan/bt-speaker/issues/4

Você está dizendo que não viu nenhuma melhora?

infelizmente, nenhuma melhoria :(

@pelwell Só para você saber, aqui estão as versões instaladas:

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

Alguém está tendo esse mesmo tipo de problema com os controladores PS3 (via bluetooth) usando Retropie com wi-fi habilitado na rpi 3? Eu tenho o que parece ser uma interferência aleatória onde às vezes os controladores funcionam bem e às vezes é como se eu não tivesse pressionado nada. Torna um pouco difícil jogar dessa forma!

Hoje atualizei um Pi Zero W com tudo o mais recente e posso confirmar que o problema ainda 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

O BCM43438 parece ter problemas com conexões múltiplas, seja com BT + WiFi ou com duas conexões BT:

Ao desligar o WiFi ( ifconfig wlan0 down ou dtparam=pi3-disable-wifi ), o áudio Bluetooth A2DP funciona perfeitamente. No entanto, quando dois dispositivos são conectados, o áudio começa a falhar muito.

Com um adaptador Bluetooth USB externo, vários dispositivos podem se conectar via A2DP e transmitir áudio, evento simultaneamente.

Portanto, presumo que seja uma limitação do chip, não uma coisa do software ... (mas adoraria ser provado que estou errado em uma atualização futura do kernel)

Certifique-se de estar executando com o firmware BT mais recente ( sudo apt-get update; sudo apt-get install bluez-firmware ) - houve algumas melhorias.

A última vez que fiz isso há 2 dias, mudou desde então?

-Ron

De: Phil Elwell [email protected]
Enviado: quarta-feira, 24 de janeiro de 2018 às 5:32
Para: raspberrypi / linux
Cc: Ron Kuper; Manual
Assunto: [Externo] Re: [raspberrypi / linux] O áudio bluetooth Pi3 trava com Wifi ativado (# 1402)

Certifique-se de estar executando o firmware BT mais recente (sudo apt-get update; sudo apt-get install bluez-firmware) - houve algumas melhorias.

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub https://github.com/raspberrypi/linux/issues/1402#issuecomment-360088465 ou ignore o tópico https://github.com/notifications/unsubscribe-auth/AC8KdHhcuhMFBE5j42nTMhwc5NJTfahxExocksJt .

Não - esse será o mais recente (1.2-3 + rpt1).

Obrigado! Nesse ínterim, comprei um dongle wi-fi USB como solução alternativa.

Alguém sabe por acaso se o driver do chipset deve (em teoria) tomar medidas para evitar interferência de RF entre esses 2 rádios?

-Ron

De: Phil Elwell [email protected]
Enviado: quarta-feira, 24 de janeiro de 2018 7:20
Para: raspberrypi / linux
Cc: Ron Kuper; Manual
Assunto: [Externo] Re: [raspberrypi / linux] O áudio bluetooth Pi3 trava com Wifi ativado (# 1402)

Não - esse será o mais recente (1.2-3 + rpt1).

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub https://github.com/raspberrypi/linux/issues/1402#issuecomment-360113610 ou desative o thread https://github.com/notifications/unsubscribe-auth/AC8KdIfVVwDf2lOlcGQTppx5A0jxxNZbA0jxxNZbAx5A0jxxNZv4A0

É suposto que sim (há um canal de coexistência entre o que são essencialmente dois dispositivos separados no mesmo pacote), e este firmware é uma melhoria significativa em relação ao firmware original de remessa, mas compartilhar uma antena parece ser um desafio.

@spalthammer escreveu um script que serviria como uma boa solução alternativa:

Eu escrevi um pequeno script para usar o inotify para ligar e desligar o wlan0 se o bluetooth se conectar / desconectar. Ok é
uma solução alternativa, mas posso viver com isso.

`#! / bin / bash

enquanto verdadeiro
Faz
RES = inotifywait -q -e CREATE, DELETE / dev / input /
caso "$ RES" em
"/ dev / input / DELETE event1")
ifconfig wlan0 up
;;
"/ dev / input / CREATE event1")
ifconfig wlan0 down
;;
esac
feito &
`
Alguém pode explicar a um novato como implementar esse script? Isso funcionaria muito bem para mim, pois não preciso de wi-fi enquanto o bluetooth está jogando. No entanto, ainda quero a capacidade de usar ssh / vnc para meu Pi3 quando o dispositivo BT for desconectado.

@lexanix

instalar inotify
cmd: sudo apt-get install inotify-tools
cp inotify.txt para /etc/inet.d/inotify (renomeie de inotify.txt para inotify!)

inotify.txt

torná-lo executável
cmd: sudo chmod u + x /etc/init.d/inotify
crie links simbólicos para iniciar o script na inicialização
cmd: sudo update-rc.d inotify defaults

Espero que isto ajude.

@spalthammer, obrigado por sua resposta! infelizmente, isso parece não estar funcionando para mim. Fiz tudo que você disse, mas nada está acontecendo. inotify-tools está atualizado no meu Pi3.

o que tentei fazer:
(Obviamente, mudei o erro de digitação de "inet.d" para init.d)
- tornou executável com chmod + x apenas porque u + x não funcionou
- tentei executar o script diretamente do terminal (sem reinicializar), o que fiz desde que adicionei uma linha para retornar um eco e funcionou
-fez inicializar no início de /etc/rc.local
No entanto, o wi-fi ainda permanece ligado quando eu conecto meu telefone via bluetooth ...

Estou executando a versão mais recente do Raspbian. Meu telefone transmite música para o Pi através de BT, que então sai como um sinal FM no GPIO. Durante esse tempo, não preciso de nenhum wi-fi habilitado, pois a música começa a falhar. No entanto, para ainda ser capaz de reconectar ao meu Pi com SSH / VNC depois de desabilitar o wi-fi, fiz um pequeno script "sudo ifconfig wlan0 up" que o habilita automaticamente novamente depois que desligo a energia e o deixo reiniciar. Isso parece estar funcionando por enquanto, mas eu gostaria de ter o script inotify muito mais elegante em execução até que saibamos o que há de errado com nosso chipset BT + WiFi.

@lexanix ,
desculpe pelo erro de digitação.
sudo chmod u+x /etc/init.d/inotify deve funcionar. Certifique-se de que /etc/init.d/inotify pertence e pode ser executado pelo root.
Se você tiver mais de um dispositivo de entrada conectado, digamos, teclado, mouse e placa de som USB, o número do dispositivo de entrada pode ser diferente. No script, estou esperando por eventos em input1, que se ajusta à minha configuração. Por favor, pare o script com
sudo killall -9 inotify
e corra
sudo inotifywait -q -e CREATE,DELETE /dev/input
Conecte-se ao dispositivo bluetooth e anote o número do seu dispositivo de entrada. Altere o script e reinicie.
Verifiquei novamente o script. Mesmo que não seja perfeito, funciona como esperado.

Saudações

A conexão BT não é estável durante a reprodução de A2DP. A BT freqüentemente se desconecta e requer a reinicialização do sistema para se recuperar.
você pode dar a solução.

@spalthammer ótimo! seu script funciona como esperado
solução perfeita para mim (Zero W com alto-falante phat; agora usando interfaces Bluetooth internas e interfaces WiFi alternadas)
não há mais rachaduras enquanto a música toca :-)

Isso ficará melhor com o novo Raspberry Pi 3 B +?

@spalthammer

Obrigado pela ótima solução alternativa. É exatamente o que preciso.

Embora eu tenha apenas uma conexão Bluetooth, recebo o seguinte quando faço

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

Então, como você sugeriu, eu editei o inotify e mudei de event1 para event0. Funciona muito bem agora!

Mas, eu me preocupo com essa mudança. Se eu tiver apenas uma única conexão BT, será sempre evento0?

Obrigado!

@davthomaspilot ,

o número X em eventX depende do número de dispositivos de entrada e não do número de conexões bluetooth. Portanto, a menos que você altere a configuração do hardware, digamos, se não adicionar outro dispositivo de entrada, como uma placa de som USB ou um teclado, o número não deve ser alterado. Se você quiser saber mais sobre seus dispositivos de entrada conectados, o comando:

cat /proc/bus/input/devices

lhe dará uma visão geral.

Ragards.

Esta solução alternativa funcionou muito bem para mim! Mas, parece que eu não preciso mais disso, por algum motivo -

Acabei de receber outro pi zero w. Baixei a imagem de Jessie Stretch e fiz a atualização, atualização. Estou usando um DAC pHat e as instruções de configuração do Bluetooth aqui:

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

É possível que haja uma correção que peguei na atualização ou atualização? Ou talvez meu novo rpi tenha uma correção de hardware?

Estou clonando a imagem do meu pi que não gagueja e vou testá-la naquele que precisava de uma solução alternativa para o martelo de spalt. E tentarei a imagem que está no rpi trêmulo no novo hardware e desabilitarei a solução alternativa para ver se o novo hardware trava com essa imagem.

Descobri que só tenho o problema se deixar o bluetoothctl em execução. Tanto no novo hardware / "software" quanto no antigo, não recebo nenhuma interrupção do stream bluetooth A2DP, a menos que esteja no bluetoothctl.

Isso é extensível, sem áudio de pulso. Talvez isso seja significativo.

@pelwell , Alguma ideia se isso foi possivelmente resolvido como parte do novo firmware WiFi da cypress, conforme mencionado aqui?
https://www.raspberrypi.org/forums/viewtopic.php?f=117&t=208090
Saudações,

@StudentSA Não parece. Ao menos não inteiramente. Estou tendo este problema em um Zero W executando 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

Possivelmente um daqueles problemas que nunca serão corrigidos ...

Decidi me aprofundar um pouco nos motoristas. A leitura do código me deu algumas dicas sobre alguns dos parâmetros do módulo que são suportados e, com alguma experimentação e uma abordagem rápida, parece que o bluetooth + wi-fi funcionou perfeitamente em conjunto um com o outro.

Consegui realizar um teste de velocidade do pi pelo wi-fi, enquanto meu telefone reproduzia áudio A2DP pelo pi e não obtive nenhuma falha.

Eu criei um arquivo /etc/modules.d/bt-wifi-fix.conf

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

debug=0x00000004 ativa o registro de nível de informação, o que não é realmente necessário.

fcmode=2 parece permitir algum tipo de controle de fluxo de hardware, que parecia tornar as coisas um pouco melhores, mas ainda não muito bom.

feature_disable=0x96 é a opção que parecia realmente consertá-lo. Não tenho certeza, mas _cheio_ 0x96 está tentando desabilitar todos os recursos opcionais, por isso eu disse 'abordagem rápida' acima. Com alguma paciência, provavelmente, é possível restringir isso a um pequeno subconjunto de recursos.

Até agora, isso tem funcionado perfeitamente para mim - vou relatar se for capaz de restringir mais as coisas.

EDIT: Eu fico com alguns problemas quando eu inicio um stream pela primeira vez, mas absolutamente nada que pareça dependente de estar usando wi-fi ou não.

Esse é um grande ponto de dados, obrigado por olhar para ele e mantenha-nos atualizados sobre qualquer progresso futuro.

@pelwell Phil, você viu isso? Pode valer a pena informar a Cypress.

Isso parece muito simples - se Cypress estiver satisfeito com ele e for tão eficaz, podemos torná-los os padrões para os kernels Pi.

É suficiente simplesmente criar /etc/modules.d/bt-wifi-fix.conf com o conteúdo que você indicou? Ou devo mudar alguma coisa para que tenha efeito?

Basta criar o arquivo conforme descrito e reiniciar.

Ok, pesquisei no Google e encontrei coisas para /etc/modules-load.d, mas não /etc/modules.d

Adicionei o arquivo em um Pi Zero W. Vou transmitir por bluetooth por um tempo e ver se ouço gagueira enquanto o wi-fi conectado.

Existe uma maneira de verificar se o bt-wifi-fix.conf foi usado, além de testar "sem soluços?"

Obrigado!

Se você incluir options brcmfmac debug=0x00000004 (sem o comentário # ), você deverá ver alguma saída de diagnóstico no log do kernel, conforme visualizado por dmesg .

Ok, eu tentei isso:

 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

Então, faça o

gerenciamento de energia desabilitado

mensagens indicam que o .conf está sendo selecionado?

Se não, há algo mais que eu possa pesquisar?

Testado em um ZeroW executando um kernel 4.14.41 (sistema operacional personalizado) Embora muitas vezes melhor, ainda há alguma falha ... mas quase tolerável.

Eu executei o iperf3 de volta para o meu servidor enquanto reproduzia o stream a2dp .... o wi-fi estava empurrando
cerca de 30 MBit / s no iperf3.

Planos para testar em um pi3 e pi3b + (o 3b + já pode tocar bem se o wi-fi estiver conectado em um canal de 5 Ghz)

@davthomaspilot Estou tentando fazer isso sozinho agora, e o conteúdo do arquivo sugerido parece correto, mas embora o nome do diretório pareça familiar, ele não está presente no meu sistema Raspbian - /lib/modprobe.d é o normal (e talvez _correto_) lugar - então eu sugiro usar o nome de arquivo /lib/modprobe.d/bt-wifi-fix.conf .

Comece com as linhas fcmode e feature_disable comentadas e pegue a saída de dmesg | cut -c16- | grep brcmfmac . Em seguida, descomente um ou ambos, reinicie e compare a saída do dmesg (e a qualidade do streaming).

Obrigado! Eu farei isso.

Espero que isso ajude mais do que "iwconfig wlan0 power off" em /etc/rc.local.

Com a economia de energia do wi-fi desativada, as falhas de streaming acontecem apenas uma vez a cada minuto ou dois. Isso acontece com nada além de uma sessão ssh no wi-fi.
Serão necessárias algumas "estatísticas" para ver se há uma melhoria adicional. Vou experimentar o Pi Zero W.

Aqui está uma comparação entre quando as linhas são comentadas e não (usando /lib/modprobe.d, NÃO /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)

Testando qualidade de streaming agora ...

Ainda gagueja. É realmente difícil dizer se é significativamente melhor do que o que eu tenho. Uma gagueira a cada minuto ou dois.

Novamente, isso é com wi-fi habilitado, mas praticamente nenhum tráfego wi-fi.

Atualmente, minha solução alternativa é desativar o wi-fi enquanto o bluetooth está conectado. Eu realmente não me importo com gagueira quando estou conectado ao wi-fi, mas seria bom conectar o wi-fi sem primeiro ter que desconectar o Bluetooth.

Testando com um pi3B + em um canal de 2,4 GHz.

O parâmetro "options brcmfmac fcmode = 2" trava o driver wi-fi em um pi3B + assim que o BT começa a enviar dados pela conexão Bluetooth. Usando um perfil A2DP.

Estou executando apenas com as opções brcmfmac feature_disable = 0x96 no pi3B + e é bastante estável, a menos que eu empurre a conexão wi-fi com iperf, então recebo alguns gaguejos significativos. Nenhum lado aparente afeta com este parâmetro quando em um canal de 5 GHz. Bluetooth é muito estável neste caso, e iperf3 passando de 120Mbit / s

Então, para não jogar uma chave inglesa nas obras, eu honestamente não posso reproduzir esse problema no último img do Stretch com a atualização do firmware bluez e atualização bluetoothctr. Eu tenho 2 cartões SD, um desde que postei originalmente em abril de 2017 executando Jessie e PulseAudio. e criei um segundo cartão SD hoje executando Stretch (9.4) e ALSA blue.

No Stretch, as coisas estão perfeitas, estou reproduzindo uma transmissão online (ou seja, usando wi-fi) através do meu alto-falante Bluetooth 100%. O cartão antigo com Jessie ainda estala mal quando Wlan0 está ativo.

Crédito para este cara que detalhou alguns truques na configuração:
Michel

Eu testei usando vlc, então você precisa especificar qual dispositivo ALSA usar, assim:
--aout = alsa --alsa-audio-device = "bluealsa"

Por favor, alguém pode tentar isso a partir de uma nova instalação e aconselhar.

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

não se esqueça de iniciar o bluealsa após uma reinicialização ou inicializá-lo automaticamente: sudo systemctl enable bluealsa)

Como você instalou o bluetoothctl: 5.49? Espero não compilar a partir do código-fonte.

Sim, da fonte (conforme o link compartilhado) por que a preocupação em torno disso?

Eu só gosto de ter atualizações usando repositório, também para evitar pacotes necessários apenas para construí-lo. Onde o link está localizado em sua postagem?

Na verdade, existe uma versão 5.50 lançada há 7 semanas. Se você está indo por esse caminho, pode valer a pena tentar. Mas sim, teremos de esperar por 5.49+ para entrar no fluxo oficial do apt-get.

Posso confirmar que não tem falhas com o Bluez 5.50.

Legal. Analisarei o que seria necessário para atualizar a compilação Raspbian.

Aqui estão as etapas:

1. Instale as dependências.
   sudo apt install libdbus-1-dev libglib2.0-dev libudev-dev libical-dev libreadline-dev

1. Baixe a última versão do código-fonte do BlueZ.
   wget http://www.kernel.org/pub/linux/bluetooth/bluez-5.50.tar.xz

2. Descompacte o arquivo baixado.
   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. Compile o código-fonte.
   make -j4

5. Instalar.
   sudo make install

6. O usuário precisa ser adicionado ao grupo bluetooth.
   sudo adduser pi bluetooth

7. O arquivo de configuração Dbus Bluetooth que foi substituído na instalação do BlueZ precisa ser restaurado.
   sudo nano /etc/dbus-1/system.d/bluetooth.conf

Adicione isto na seção <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"/>

e isso depois:
<!-- allow users of bluetooth group to communicate -->
<policy group="bluetooth">
<allow send_destination="org.bluez"/>
</policy>

1. Reiniciar Raspberry Pi
   sudo reboot

@amilino Ainda não está funcionando para mim. Ainda gaguejando com o wi-fi ligado e quando desligado. Tentei quase tudo neste tópico, até mudei de um rpi b + com um dongle bt para um rpi 3 b + com bluetooth integrado e ainda há gagueira.

Não exatamente gaguejando, na verdade. Parece obter um pedaço de dados, reproduzi-lo muito rápido, com alguns pedaços faltando, depois sentar e esperar pelo próximo pedaço.

Eu tenho a mesma configuração que @StudentSA mencionou, exceto o Bluez 5.50 mais recente. Eu também segui este tutorial: https://gist.github.com/mill1000/74c7473ee3b4a5b13f6325e9994ff84c. Toquei as mesmas músicas que gaguejavam antes e agora estão funcionando sem problemas.

@amilino Funcionou perfeitamente, obrigado.

O único efeito colateral deste tutorial é que o áudio não é reproduzido se você conectar a máquina Linux no RPI Bluetooth. Se alguém souber de algum tutorial melhor por favor me avise.

A Cypress está investigando a interferência de WiFi / BT e apresentou algumas novas configurações de arquivo "NVRAM" que afirmam ter "consertado completamente a falha de áudio". As mesmas configurações podem ser usadas no 43430 (3B, ZeroW) e no 43455 (3B +).

1. Localize seu arquivo de texto "NVRAM" - ele está em /lib/firmware/brcm/brcmfmac<dev>-sdio.txt , onde <dev> é 43430 ou 43455 respectivamente. Faça uma cópia de backup em algum lugar seguro para facilitar a desfazer as alterações (ou recuperar de um erro).

2. Abra o arquivo em um editor de texto, role para baixo até o final (apenas para fins de organização - essas configurações provavelmente podem ir a qualquer lugar) e acrescente o seguinte:

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

3. Reinicialize.

Como me foi explicado, essas configurações coletivamente permitem mais tempo de antena ao Bluetooth, permitindo que o WiFi durma por mais tempo e reduzindo o tempo máximo que o Bluetooth pode esperar.

Relate suas descobertas, sejam positivas ou negativas, para nos ajudar a decidir se devemos tornar esses os novos valores padrão.

Tenho seguido este tópico com interesse. Estou usando um Pi ZeroW / Raspbian Lite para reproduzir streams de internet através do bluealsa para um alto-falante bluetooth usando o Mopidy. Até hoje nada neste tópico resolveu o problema da gagueira.

bluez 5,50 - sem diferença
desativando o WiFi e usando um adaptador Ethernet USB - algumas mudanças, mas ainda trêmula a cada poucos minutos

Alterar as configurações de NVRAM - parece perfeito até agora. Voltei a usar o WiFi e não há gagueira no áudio do bluetooth. Ainda usando o bluez 5.50. Vou relatar se tiver alguma gagueira.

Resultados positivos até agora. Também estou usando o Bluez 5.50. Placa - RPi3

Eu removi os parâmetros modprobe anteriores que foram sugeridos como uma solução. Até agora, sem gagueira. Usando o iperf3, você pode definitivamente vê-lo roubando tempo do rádio wifi. Mas sem gagueira, mesmo ao enviar dados extras.

Ao jogar 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

Parando a reprodução e desconectando o alto-falante.

[ 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 desativado 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

Funciona para mim raspi 3B, sem gagueira, até movendo um arquivo grande por wi-fi enquanto reproduz áudio (a2dp), mas estou vendo toneladas de
"Bluetooth: hci0: Falha na remontagem do quadro (-84)" em milissegundos!

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

Estou tentando isso há algumas horas. Está melhor do que antes, mas não é perfeito. Agora tenho, geralmente, 20 a 30 minutos de reprodução contínua, mas a gagueira começa novamente e não vai embora até que eu pare e reinicie o fluxo de áudio. Além disso, minha sessão de ssh para por um momento quando a gagueira começa. Não é buffer de áudio, porque coloquei o log no meu player para me dizer quando ele está armazenando.

Talvez você deva mudar para RPi3 b +, não tenho nenhum problema.

Talvez você deva mudar para RPi3 b +, não tenho nenhum problema.

Não é exatamente o ponto, é? As mudanças foram ditas para "consertar completamente" a gagueira de áudio. Estou apenas relatando que não parece ser o caso. O 3B + usa um chipset diferente do W, então talvez as configurações precisem de alguns ajustes.

Sim concordo, mas olhando o assunto assunto está relacionado ao RPi3. De qualquer forma, esta discussão é muito longa, talvez fosse bom abrir uma nova edição separada relacionada a Pi W.

Esta solução também funciona para ZeroW. Jogo há mais de 2 horas sem problemas.

Acho que os problemas que tenho enfrentado no ZeroW provavelmente se devem ao Bluetooth não ter o mesmo alcance do Bluetooth do meu iMac. Colocando o alto-falante mais perto do Pi, estou tocando rádio de internet há 4 horas sem problemas. Terei que reposicionar o Pi para que o sinal alcance a cozinha :)

Obrigado por todos os comentários, que sugerem que essas configurações são, pelo menos, uma grande melhoria sem regressões. Sinta-se à vontade para intervir se suas experiências sugerirem o contrário, mas estou planejando tornar esses os novos padrões.

Posso acrescentar mais uma observação com resultado positivo. Estou usando Bluetooth e Wi-Fi simultaneamente no meu ZeroW por cerca de uma hora sem gaguejar. Definitivamente, um +1 por tornar este o novo padrão.

Você discute aqui apenas o problema quando o rPi é usado como fonte a2dp ou também como coletor a2dp?

Estou tentando usar meu rPi3 como um coletor de bluetooth (ou seja, tento reproduzir áudio do meu telefone para meu rPi), e a gagueira é tão intensa que você mal reconhece as músicas tocadas. Wi-fi não é usado. Tentei com um adaptador BT externo - sem sorte. No entanto, com diferentes adaptadores bt, a gagueira era diferente (como se um tamanho de buffer diferente fosse usado).

Devo relatar um problema diferente?

@edio Tenho usado o RPi ZeroW como coletor, transmitindo áudio do meu telefone para o RPi via Bluetooth. Até ontem, eu também tinha uma gagueira horrível, mas a solução sugerida mais recentemente parece ter resolvido.

A solução apresentada por @ paul-1 funciona para mim, no painel Pi 3+. Posso usar o Wi-Fi normalmente e desfrutar de um bom fluxo de áudio BT

Olá,
alguém tem alguma ideia de como usar a solução NVRAM em um sistema Libreelec com um sistema squashFS somente leitura? Pelo que entendi, é somente leitura porque a próxima distribuição substitui os arquivos do 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

Agora edite o arquivo em /storage/.config/firmware/brcm e reinicie.

Ou você pode usar uma versão de teste LibreELEC 9.0 recente com Kodi 18 que já inclui esta correção: https://forum.kodi.tv/showthread.php?tid=298461

Alguém neste tópico ainda tem desistências ocasionais após a aplicação da correção? Não é tão terrível quanto a gagueira que tive inicialmente, mas ainda assim o coletor de bluetooth é bastante inutilizável para mim, já que a cada dois segundos eu recebo rajadas de cliques, aproximadamente cada um correspondendo a uma série de registros na saída de 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)

e do bluez eu recebo

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

Eu recebo períodos de até um minuto de cliques e estalos, então ele vai embora, geralmente por várias horas. É pior quando o falante está mais longe do Pi.

@MilhouseVH muito obrigado por isso! Deixe-me ver aqui o que outros podem achar útil.

Para sua informação, em libreELEC (Rpi 3+), a correção cura a gagueira, mas introduz um atraso de áudio inaceitável se o filme estiver sendo veiculado por WiFi. Acho que é uma limitação da plataforma.

O atraso de áudio foi corrigido? Você pode corrigir isso usando atraso de áudio?
https://kodi.wiki/view/Video_playback#Audio_and_Subtitle_Settings

Mudei meus dados do wlan0 integrado para o eth0 e os problemas de bluetooth foram resolvidos. Infelizmente não podemos ter nosso bolo e comê-lo também :(
Terei que tentar a sugestão NVRAM acima quando tiver uma chance.

Ainda estou tendo gagueira depois de tentar todos os tipos de correções no meu RPi 3+. Desativará o wi-fi completamente e usará o fio. :(

Bem. Estou feliz por ser outro ponto de dados. A correção da NVRAM mudou totalmente meu projeto por um capricho de construir uma fonte A2DP usando meu zero-w. Eu comecei o projeto ontem e até encontrar este tópico tanto pulseaudio quanto bluez-alsa estavam completamente inutilizáveis ​​enquanto o wifi estava em uso. Não ter wi-fi também seria um obstáculo. Muito obrigado às pessoas que vasculharam as fontes de chips e encontraram a solução.

Eu ainda tenho um pequeno estalo e chiado quando a CPU fica sobrecarregada (como a execução de atualizações ao jogar bluetooth), mas fora isso, é uma máquina totalmente diferente. Para registro, estou executando Arch 4.14.90, Bluez 5.50 e Pulseaudio 12.2. O que significa que isso deve funcionar em um futuro próximo e não é uma solução que envolve a execução de software incompatível realmente antigo. <3

Eu editei as configurações dos arquivos NVRAM:
/usr/lib/firmware/updates/brcm/brcmfmac43430-sdio.txt
/usr/lib/firmware/updates/brcm/brcmfmac43455-sdio.txt

@acegallagher : Não entendo seu comentário. Qualquer explicação seria apreciada.

Se você tem algum tipo de solução quais etapas são necessárias para ter isso no RPI?

@pelwell

Os arquivos NVRAM atualizados estão nas atualizações Raspbian desde agosto de 2018. Alternativamente, você pode baixá-los diretamente:

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

Copie-os para a pasta / lib / firmware / brcm (você precisará sudo cp ... ).

Desculpe, mas isso não funciona. Ainda tenho gagueira com Wifi.

Isso é uma vergonha. Você reiniciou após a instalação?

Infelizmente, há limites para o que pode ser alcançado com uma antena compartilhada. Você já tentou alterar a distância do Pi ao AP e / ou ao dispositivo BT?

Sim, tenho lutado com isso há alguns meses. Mudei para o cabo de rede e sem problemas mais.

Oi,
Com o /usr/lib/firmware/updates/brcm/brcmfmac43430-sdio.txt atualizado e amigo, e sim reiniciei :-), ainda ouço underruns no áudio USB que não estão lá com o áudio on-board (a cada 5 segundos ou então).
Não usando wi-fi, tudo ethernet.

Se por outro lado eu fizer ifconfig wlan0 down primeiro, então está tudo bem ...!
oh, não, não é. apenas muito menos

Você está relatando falha de áudio USB com Ethernet em um problema de áudio Bluetooth com WiFi?

oops!

Esse problema de Bluetooth + WiFi está causando problemas com meu teclado ao pressionar várias vezes uma tecla para cima.

@ pratt-jeremy Isso é um teclado sem fio?

Eu tenho o mesmo problema. Executando o arco em um Pi B3, B3 + e Zero. Todos exibem os mesmos sintomas: jogo instável com a2dp. Arch não atualizou o firmware conforme listado aqui, mas eu fiz isso manualmente primeiro. Se eu usar o BT onboard nessas 3 máquinas, Bluealsa reclama de buffer under run e toca música em jorros. O diário mostra um buffer em execução. Se eu usar um dongle USB, tudo funcionará conforme o esperado. Podemos tentar mais alguma coisa? fwiw, meu kernel é 4.19.32

Parece claro para mim que colocar bluetooth e wi-fi em um RPi é como fazer uma bolsa de seda com a orelha de uma porca.

A equipe de desenvolvimento do Raspberry Pi deve afirmar que reproduzir áudio por bluetooth enquanto reproduz um vídeo por wi-fi é simplesmente incompatível devido à falta de potência / largura de banda.

Desde o primeiro dia, o Pi tem sido apresentado como um substituto atualizado para o micro da BBC, para ensinar crianças nas escolas. Kodi foi um grande bônus. Acabei de desistir dessa ideia. Eu queria servir filmes em um pi-top com um link bluetooth para o sistema de áudio da minha caravana, mas agora basta conectar um disco rígido de filme em uma porta USB. Sem Wifi, sem gagueira. Triste, mas não muito inconveniente.

Este é o comando apropriado a ser executado para fazer o BT integrado funcionar?
/ usr / bin / btattach -B / dev / ttyAMA0 -P bcm -S 3000000
Este é o comando no arquivo de serviço para Arch Linux com a instalação padrão do Bluez 5.50

Portanto, tenho streaming de áudio para um B3 + com wi-fi habilitado e ativo (estou logado via ssh). Estou executando o Arch Linux. Eu tive que instalar bluez-utils-compat para obter o comando hciattach instalado. Eu acredito que Raspian já tem isso ...

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

O pacote padrão do Bluez 5.50 tem btattach que o Arch usa para ligar o adaptador BT. Isso não funcionou. Tudo o que consegui foi um som gaguejante. Este pacote do Arch pi-bluetooth exige que o comando seja:
ExecStart=/usr/bin/btattach -B /dev/ttyAMA0 -P bcm -S 3000000
O comando que funcionou era de uma versão mais antiga do pacote:
ExecStart=/usr/bin/hciattach -n /dev/ttyAMA0 bcm43xx 921600 noflow -
Eu não tenho a pretensão de saber se isso é 'correto' ou algo assim, apenas que esta é a primeira vez que tenho um bluetooth de reprodução suave usando o adaptador integrado.

Apenas para evitar confusões. A tecnologia Broadcom WiFi foi comprada pela Cypress em junho de 2016. Desde então

• BCM43438 é CYW43438
• BCM43455 é CYW43455

@ pratt-jeremy Isso é um teclado sem fio?

@ JamesH65 sim, é um teclado bluetooth, vi que era para áudio, mas pensei em mencioná-lo. Assim que desliguei o wi-fi, o teclado bluetooth funcionou perfeitamente. Sem caracteres repetidos que não pressionei.

Presumivelmente, sua distribuição está totalmente atualizada?

Presumivelmente, sua distribuição está totalmente atualizada?

Estava atualizado quando postei aqui, provavelmente está desatualizado já que estava em março. Vou atualizar e ver se ainda está acontecendo.

Em um RPI4 com WiFi bloqueado por software em rfkill. Ainda instável no Pulseaudio A2DP.