squeezelite esp32
v4.3#SqueezeAmp#master-v4.3
Mais e mais pessoas parecem usar isso sem um servidor LMS, apenas para BT, AirPlay ou Spotify. Tudo bem, mas entenda que o squeezeliteESP32 é principalmente um reprodutor Logitech Media Server e foi projetado em torno desse conceito. Todos os outros são complementos costurados, portanto, outros modos têm suas deficiências. Portanto, certifique-se de ler isto antes de abrir um problema
Squeezelite-esp32 é um conjunto de software de áudio feito para rodar nos chipsets esp32 e esp32-s3 wifi (b/g/n) e bluetooth do espressif. Ele oferece os seguintes recursos
Dependendo do hardware conectado ao esp32, você pode enviar áudio para um DAC local, para SPDIF ou para um alto-falante Bluetooth. O hardware mínimo necessário é um módulo WROVER com 4 MB de Flash e 4 MB de PSRAM (https://www.espressif.com/en/products/modules/esp32). Com esse módulo independente, basta ligar a energia e você poderá transmitir para um alto-falante Bluetooth. Você também pode enviar áudio para a maioria dos DAC I2S, bem como para receptores SPDIF usando apenas um cabo ou transdutor óptico.
Mas o squeezelite-esp32 é altamente extensível e você pode adicionar
Outros recursos incluem
Para controlar o equalizador ou usar o display no LMS, é necessário um novo modelo de player e isso é fornecido através de um plugin que faz parte dos repositórios de terceiros do LMS
(opiniões apresentadas aqui então I = @philippe44) A construção principal do squeezelite-esp32 é um núcleo interno de 16 bits com todos os cálculos em 32 bits ou precisão flutuante. Esta é uma escolha de design que fiz para preservar o desempenho da CPU (já está sobrecarregando bastante o chipset esp32) e otimizar o uso de memória, pois temos apenas 4 MB de RAM utilizável. Alguns podem comentar corretamente que o módulo WROVER possui 8MB de RAM, mas o processador só consegue endereçar 4MB e os 4MB restantes devem ser paginados por blocos menores e não tenho paciência para isso.
Agora, quando fiz a portabilidade do squeezelite para o esp32, também tornei o núcleo de 16 ou 32 bits compatível em tempo de compilação. Até agora, funciona em 32 bits, mas menos testes foram feitos. Você pode optar por compilá-lo no modo de 32 bits. Não estou muito interessado em amostras acima de 16 bits porque não traz nada (tenho formação em engenharia em teoria da informação).
| Capacidade | 16 bits | 32 bits | comentário |
|---|---|---|---|
| taxa máxima de amostragem | 192 mil | 96 mil | 192k é muito desafiador, especialmente quando combinado com display |
| profundidade máxima de bits | 16 | 24 | 24 bits são truncados no modo de 16 bits |
| SPDIF | 16 bits | 20 bits | |
| mp3, aac, opus, ogg/vorbis | 48k | 48k | |
| alac, flac, ogg/flac | 96 mil | 96 mil | |
| pcm, wav, aif | 192 mil | 96 mil | |
| equalizador | S | N | Máximo de 48kHz (após reamostragem) - equalização ignorada em faixas >48k |
| reamostragem | S | N | |
| desbotamento cruzado | 10s | <5s | depende do tamanho do buffer e da taxa de amostragem |
O esp32 deve rodar a 240 MHz, com E/S Quad-SPI a 80 MHz e clock de 40 MHz. Ainda assim, é muito para rodar, principalmente sabendo que possui Flash serial e PSRAM, então parabéns ao Espressif pela otimização do chipset. Agora, ter toda a decodificação, reamostragem, equalização, ganho, exibição, espectro/vu é um equilíbrio muito (muito) delicado entre o uso de RAM interna/externa, prioridades de tarefas e manipulação de buffer. Não é perfeito e quanto mais você leva o sistema ao limite, maior é o risco de alguns arquivos não serem reproduzidos (veja abaixo). Em geral, a exibição sempre terá a prioridade mais baixa e você notará lentidão na rolagem e nas taxas de atualização do VU/Espectro. Agora, até mesmo o thread de exibição tem alguma seção crítica e afeta os recursos. Por exemplo, um display colorido de 16 bits de profundidade com baixa velocidade SPI pode impedir o funcionamento de 24/96 flac, mas ainda funciona com pcm 24/96
No modo de 16 bits, embora 192 kHz seja relatado como taxa máxima, é altamente recomendado limitar a taxa de amostragem relatada a 96k (-Z 96000). Observe que alguns fluxos on-line de alta velocidade de 24/96k podem falhar devido ao desempenho da pilha TCP/IP. Geralmente é devido ao fato de que o servidor envia pequenos pacotes de dados e o esp32 não consegue receber áudio codificado com rapidez suficiente, independentemente das configurações de prioridade da tarefa (tentei ajustar isso um pouco). A melhor opção nesse caso é permitir que o LMS faça proxy do fluxo, pois ele fornecerá pedaços maiores e um fluxo "mais suave" que poderá então ser manipulado.
Observe também que alguns codecs consomem mais CPU do que outros ou não foram tão otimizados. Fiz o meu melhor para ajustá-los, mas esse nível de otimização inclui escrever algumas montagens que são dolorosas. Um codec muito exigente é o AAC quando os arquivos são codificados com SBR. Ele permite a reconstrução da parte superior do espectro e, portanto, uma taxa de amostragem mais alta, mas a especificação do codec é tal que isso é opcional, você pode simplesmente decodificar a banda inferior e aceitar uma taxa de amostragem mais baixa - Veja a opção AAC_DISABLE_SBR abaixo.
IMPORTANTE: no esp32 (não no esp32-s3), usar o Spotify com SPDIF produz áudio interrompido quando as "estatísticas" estão habilitadas. Você DEVE desativá-los
Qualquer hardware baseado em esp32 com pelo menos 4 MB de flash e 4 MB de PSRAM será capaz de rodar o squeezelite-esp32 e existem várias placas que incluem esse chip. Alguns são mencionados abaixo, mas qualquer um deve funcionar. Você pode encontrar várias ajudas e instruções aqui
Para maior clareza, os módulos WROOM NÃO funcionam porque não incluem PSRAM. Alguns designs podem adicioná-lo externamente, mas é (muito) improvável.
Pela descrição acima, um módulo WROVER é suficiente para executar o Squeezelite-esp32, mas isso requer alguns ajustes para estendê-lo para ter áudio analógico ou botões de hardware (por exemplo)
Observe que ao enviar para um alto-falante Bluetooth (fonte), apenas 44,1 kHz pode ser usado, então você deixa o LMS fazer a reamostragem, mas deve certificar-se de que ele envia apenas faixas de 44,1 kHz ou ativar a reamostragem interna (usando a opção -R). . Se você conectar um DAC, a escolha das taxas de amostragem dependerá de suas capacidades. Veja abaixo para mais detalhes.
A maioria dos DAC funcionará imediatamente com simplesmente uma conexão I2S, mas alguns exigem que comandos específicos sejam enviados usando I2C. Consulte a opção DAC abaixo para entender como enviar esses comandos dedicados. Há suporte integrado para TAS575x, TAS5780, TAS5713 e AC101 DAC.
Os módulos baseados em esp32-s3 como este também são suportados, mas requerem esp-idf 4.4. Ainda não faz parte dos lançamentos oficiais, mas compila e executa. O s3 não possui áudio bluetooth. Observe que o desempenho da CPU é bastante aprimorado.
Este é o principal companheiro de hardware do Squeezelite-esp32 e foi desenvolvido em conjunto. Detalhes sobre recursos podem ser encontrados aqui e aqui.
Se você deseja reconstruir, use o arquivo de configuração squeezelite-esp32-SqueezeAmp-sdkconfig.defaults .
NB: Você pode usar os binários pré-construídos SqueezeAMP4MBFlash que possuem todas as E/S de hardware configuradas corretamente. Você também pode usar o binário genérico I2S4MBFlash, caso em que os parâmetros NVS devem ser definidos para obter exatamente o mesmo comportamento
12=green,13=red,34=jack,2=spkfaultchannel=7,scale=20.24model=TAS57xx,bck=33,ws=25,do=32,sda=27,scl=26,mute=14:0bck=33,ws=25,do=15 O IR pode ser usado como um sinal de despertar usando (definindo sleep_config com wake=0:0 ). É um pull-up, portanto permanece em 1 quando não recebe nada, o que significa que não pode ser usado em conjunto com outros IOs de ativação. Consulte Dormindo para obter mais detalhes sobre a limitação de despertar após múltiplas entradas.
Este alto-falante portátil alimentado por bateria é compatível com squeezelite-esp32, para o qual há uma versão dedicada fornecida com cada atualização. Se você deseja reconstruir, use o arquivo de configuração squeezelite-esp32-Muse-sdkconfig.defaults .
NB: Você pode usar os binários pré-construídos Muse4MBFlash que tem todas as E/S de hardware configuradas corretamente. Você também pode usar o binário genérico I2S4MBFlash, caso em que os parâmetros NVS devem ser definidos para obter exatamente o mesmo comportamento
musechannel=5,scale=7.48,atten=3,cells=1"mosi=15,miso=2,clk=14 (este provavelmente é opcional)model=I2S,bck=5,ws=25,do=26,di=35,i2c=16,sda=18,scl=23,mck=0{"init":[ {"reg":0,"val":128}, {"reg":0,"val":0}, {"reg":25,"val":4}, {"reg":1,"val":80}, {"reg":2,"val":0}, {"reg":8,"val":0}, {"reg":4,"val":192}, {"reg":0,"val":18}, {"reg":1,"val":0}, {"reg":23,"val":24}, {"reg":24,"val":2}, {"reg":38,"val":9}, {"reg":39,"val":144}, {"reg":42,"val":144}, {"reg":43,"val":128}, {"reg":45,"val":128}, {"reg":27,"val":0}, {"reg":26,"val":0}, {"reg":2,"val":240}, {"reg":2,"val":0}, {"reg":29,"val":28}, {"reg":4,"val":48}, {"reg":25,"val":0}, {"reg":46,"val":33}, {"reg":47,"val":33} ]}[{"gpio":32, "pull":true, "debounce":10, "normal":{"pressed":"ACTRLS_VOLDOWN"}}, {"gpio":19, "pull":true, "debounce":40, "normal":{"pressed":"ACTRLS_VOLUP"}}, {"gpio":12, "pull":true, "debounce":40, "long_press":1000, "normal":{"pressed":"ACTRLS_TOGGLE"},"longpress":{"pressed":"ACTRLS_POWER"}}]Funciona com módulo ESP32-A1S que inclui codec de áudio e saída de fone de ouvido. Você ainda precisa usar uma placa de demonstração como esta ou um amplificador externo se desejar conexão direta de alto-falante. Observe que existe uma versão com codec AC101 e outra com ES8388 com provavelmente duas variantes - essas placas são uma bagunça (veja abaixo)
A placa mostrada acima possui o seguinte conjunto IO
(observe que alguns GPIO precisam de pullups)
Então uma possível configuração seria
21=amp,22=green:0,39=jack:0 [{ "gpio" : 5 , "normal" :{ "pressed" : " ACTRLS_TOGGLE " }},{ "gpio" : 18 , "pull" : true , "shifter_gpio" : 5 , "normal" :{ "pressed" : " ACTRLS_VOLUP " }, "shifted" :{ "pressed" : " ACTRLS_NEXT " }}, { "gpio" : 23 , "pull" : true , "shifter_gpio" : 5 , "normal" :{ "pressed" : " ACTRLS_VOLDOWN " }, "shifted" :{ "pressed" : " ACTRLS_PREV " }}]para AC101
model=AC101,bck=27,ws=26,do=25,di=35,sda=33,scl=32para ES8388 (parece que existem variantes com o mesmo número de versão - uma bagunça total)
model=ES8388,bck=5,ws=25,do=26,sda=18,scl=23,i2c=16 oumodel=ES8388,bck=27,ws=25,do=26,sda=33,scl=32,i2c=16Este é um smartwatch divertido baseado em ESP32. Possui tela 240x240 ST7789 e áudio integrado. Não é muito útil ouvir nada, mas funciona. Este é um exemplo de dispositivo que requer um conjunto de comandos I2C para seu DAC/APU (veja abaixo). Existe uma opção de construção se você decidir reconstruir tudo sozinho, caso contrário, a opção padrão I2S funciona com os seguintes parâmetros
model=I2S,bck=26,ws=25,do=33,i2c=53,sda=21,scl=22 { "init" : [ { "reg" : 41 , "val" : 128 }, { "reg" : 18 , "val" : 255 } ], "poweron" : [ { "reg" : 18 , "val" : 64 , "mode" : " or " } ], "poweroff" : [ { "reg" : 18 , "val" : 191 , "mode" : " and " } ] }dc=27,data=19,clk=18SPI,driver=ST7789,width=240,height=240,cs=5,back=12,speed=16000000,HFlip,VFlipSqueezelite-esp32 requer chipset esp32 e 4 MB PSRAM. ESP32-WROVER atende a esses requisitos. Para obter uma saída de áudio, um DAC I2S pode ser usado. DACs PCM5102 I2S baratos funcionam, mas muitos outros também funcionam. Os DACs PCM5012 podem ser conectados via:
I2S - WROVER
VCC-3,3V
3,3 V - 3,3 V
GND - GND
FLT-GND
DMP-GND
SCL-GND
BCK - (BCK - veja abaixo)
DIN - (DO - veja abaixo)
LCK - (WS - veja abaixo) FMT - GND
XMT-3,3V
Use o arquivo de configuração squeezelite-esp32-I2S-4MFlash-sdkconfig.defaults .
E o projeto super legal https://github.com/rochuck/squeeze-amp-too
Para acessar o NVS, na webUI, vá em créditos e selecione "mostra editor nvs". Vá para a guia do editor NVS para alterar os parâmetros do NFS. Na descrição da sintaxe abaixo, <> significa um valor enquanto [] descreve parâmetros opcionais.
Conforme mencionado acima, existem algumas compilações dedicadas fornecidas hoje: SqueezeAMP e Muse, mas se você mesmo construir, também poderá criar uma compilação para o T-WATCH2020. A compilação padrão é um firmware genérico chamado I2S que pode ser configurado através do NVS para produzir exatamente os mesmos resultados que as compilações dedicadas. A diferença é que os parâmetros devem ser inseridos e podem ser apagados acidentalmente. A GUI também fornece uma grande ajuda para carregar "conjuntos de configurações conhecidos".
Por escolha de design, não existe código incorporado apenas para uma determinada versão, todo o código está sempre lá. A filosofia é minimizar tanto quanto possível o código específico da plataforma e o uso de #ifdef específico é proibido, não importa o que aconteça. Portanto, se você deseja adicionar sua própria plataforma, consulte mainKConfig.projbuild para ver como você pode, usando os parâmetros abaixo, tornar seu dispositivo puramente uma solução baseada em configuração. Quando realmente não houver outra opção, consulte targets<target> para adicionar seu próprio código. Não aceitarei PR para código que possa evitar a criação de tal código dedicado sempre que possível. O "destino" do NVS será usado para chamar o código específico do destino, mas, novamente, isso é puramente tempo de execução, não tempo de compilação.
O parâmetro NVS "i2c_config" define o gpio do i2c usado para fins genéricos (por exemplo, exibição). Deixe em branco para desabilitar o uso de I2C. Observe que no SqueezeAMP, a porta deve ser 1. A velocidade padrão é 400.000, mas alguns monitores podem suportar até 800.000 ou mais. Sintaxe é
sda=<gpio>,scl=<gpio>[,port=0|1][,speed=<speed>]
Observe que você não pode usar o mesmo GPIO ou porta do DAC.
O esp32 possui 4 subsistemas SPI, um é inacessível, então a numeração é 0..2 e o SPI0 é reservado para Flash/PSRAM. O parâmetro NVS "spi_config" define o gpio do spi usado para fins genéricos (por exemplo, exibição). Deixe em branco para desabilitar o uso de SPI. O parâmetro DC é necessário para exibições. Sintaxe é
data|mosi=<gpio>,clk=<gpio>[,dc=<gpio>][,host=1|2][,miso=<gpio>]
O padrão e único "host" é 1, pois outros já são usados por flash e spiram. O parâmetro opcional "miso" (MasterInSlaveOut) só é usado quando o barramento SPI é bidirecional e compartilhado com outros periféricos como ethernet, expansor gpio. Observe que “dados” também podem ser denominados “mosi” (MasterOutSlaveIn).
O parâmetro NVS "dac_config" define o gpio usado para comunicação i2s com seu DAC. Você pode definir os padrões em tempo de compilação, mas o parâmetro nvs tem precedência, exceto para configurações nomeadas
bck=<gpio>,ws=<gpio>,do=<gpio>[,mck=0|1|2][,mute=<gpio>[:0|1][,model=TAS57xx|TAS5713|AC101|WM8978|ES8388|I2S][,sda=<gpio>,scl=<gpio>[,i2c=<addr>]]
se o "modelo" não estiver definido ou não for reconhecido, o padrão "I2S" será usado. A opção "mck" é usada para alguns codecs que requerem um relógio mestre (embora não devam). Por padrão, GPIO0 é usado como MCLK e apenas compilações recentes (após meados de 2023) podem usar 1 ou 2. Esteja ciente também de que isso não pode coexistir com Ethernet RMII (consulte a seção Ethernet abaixo). Os parâmetros I2C são opcionais e necessários apenas se o seu DAC exigir um controle I2C (consulte 'dac_controlset' abaixo). Observe que os parâmetros "i2c" são decimais, a notação hexadecimal não é permitida.
Até agora, TAS57xx, TAS5713, AC101, WM8978 e ES8388 são modelos reconhecidos para os quais a sequência de inicialização/volume/controles de energia adequados são enviados. Para outros codecs que podem exigir comandos I2C, use o parâmetro "dac_controlset" que permite a definição de comandos simples a serem enviados por i2c para init, power, alto-falante e fone de ouvido usando uma sintaxe JSON:
{ <command>: [ <item1>, <item2>, ... <item3> ],
<command>: [ <item1>, <item2>, ... <item3> ],
... } Onde <command> é init, poweron, poweroff, speakeron, speakeroff, headseton, headsetoff ( deve ser uma matriz mesmo para um único item). Item é qualquer um dos seguintes elementos
{"reg":<register>,"val":<value>,"mode":<nothing>|"or"|"and"}
{"gpio":<gpio>,"level":0|1}
{"delay":<ms>}
Esta é a notação JSON padrão, portanto, se você não estiver familiarizado com ela, o Google é seu melhor amigo. Esteja ciente de que '...' significa que você pode ter quantas entradas quiser, não faz parte da sintaxe. Cada seção é opcional, mas não faz sentido definir i2c no parâmetro 'dac_config' e não definir nada aqui.
A chave reg permite escrever registros no barramento i2c. O mode de parâmetro permite ou o registro com o valor ou para e it. Não defina mode se você simplesmente deseja escrever. O parâmetro val pode ser um array [v1, v2,...] para escrever uma série de bytes em um único burst i2c (nesse caso, 'mode' é ignorado). Observe que todos os valores devem ser decimais . Você pode usar um validador como este para verificar sua sintaxe. A chave gpio serve simplesmente para definir um gpio como parte da ação do DAC e delay permite uma pausa entre os elementos.
O comando 'power' é usado ao ligar/desligar o DAC após o período ocioso (veja a opção -C do squeezelite) e os comandos 'alto-falante/fone de ouvido' são enviados ao alternar entre alto-falantes e fones de ouvido (veja detecção de conector de fone de ouvido).
NB: Para configurações nomeadas ((SqueezeAMP, Muse ... todas exceto I2S), tudo isso é ignorado. Para codecs conhecidos, as sequências integradas podem ser substituídas usando dac_controlset
Observe que você não pode usar o mesmo GPIO ou porta do I2C.
O parâmetro NVS "spdif_config" define o gpio do i2s necessário para SPDIF.
O SPDIF é disponibilizado reutilizando a interface i2s de uma forma não padrão, portanto, embora apenas um pino (DO) seja necessário, o controlador deve ser totalmente inicializado, portanto, o bit clock (bck) e o word clock (ws) devem ser definir também. Como i2s e SPDIF são mutuamente exclusivos, você pode reutilizar o mesmo IO se o seu hardware permitir.
Você pode definir os padrões em tempo de compilação, mas o parâmetro nvs tem precedência, exceto para configurações nomeadas (SqueezeAMP, Muse ...)
Deixe em branco para desabilitar o uso do SPDIF, você também pode defini-los em tempo de compilação usando "make menuconfig". Sintaxe é
bck=<gpio>,ws=<gpio>,do=<gpio>
NB: Para configurações nomeadas, isso é ignorado
A profundidade máxima de bits é de 24 bits, mesmo no modo de 32 bits (esta é uma limitação SPDIF - obrigado @UrbanLienert pela atualização de 20 para 24 bits). Agora, você também pode obter SPDIF usando um chip especializado que oferece uma interface I2S como um DAC, mas emite SPDIF (óptico e coaxial). Refere-se ao capítulo DAC então.
Se você quiser coaxial, também pode usar um truque de pobre para gerar sinal de um GPIO de 3,3V. Tudo o que isso faz é dividir os 3,3 V para gerar 0,6 V pico a pico e depois remover o DC
100nF
GPIO ----210ohm-----------||---- coax S/PDIF signal out
|
110ohm
|
Ground -------------------------- coax signal ground
O parâmetro NVS "display_config" define os parâmetros para uma exibição opcional. Pode ser I2C (veja aqui para barramento compartilhado) ou SPI (veja aqui para barramento compartilhado) A sintaxe é
I2C,width=<pixels>,height=<pixels>[address=<i2c_address>][,reset=<gpio>][,HFlip][,VFlip][driver=SSD1306|SSD1326[:1|4]|SSD1327|SH1106]
SPI,width=<pixels>,height=<pixels>,cs=<gpio>[,back=<gpio>][,reset=<gpio>][,speed=<speed>][,HFlip][,VFlip][driver=SSD1306|SSD1322|SSD1326[:1|4]|SSD1327|SH1106|SSD1675|ST7735|ST7789[:x=<offset>][:y=<offset>]|ILI9341[:16|18][,rotate]]
Você pode ajustar a forma como o vu-meter e o analisador de espectro são exibidos, bem como o tamanho da arte através de um menu dedicado nas configurações do player (não se esqueça de adicionar o plugin).
O parâmetro NVS "metadata_config" define como os metadados são exibidos para AirPlay e Bluetooth. Sintaxe é
[format=<display_content>][,speed=<speed>][,pause=<pause>][,artwork[:0|1]]
%artist% , %album% , %title% . Usando essa string de formato, as palavras-chave são substituídas por seus valores para construir a string a ser exibida. Observe que o texto simples após uma palavra-chave que estiver vazia durante a reprodução de uma faixa será removido. Por exemplo, se você definiu format= %artist% - %title% e não há artista nos metadados, apenas <title> será exibido, não - <title> .Você pode usar qualquer receptor IR compatível com protocolo NEC (38KHz) ou RC5. Vcc, GND e saída são os únicos pinos que precisam ser conectados, sem pullup, sem capacitor de filtragem, é uma conexão direta.
Os códigos IR são enviados "como estão" para o LMS, portanto, apenas um controle remoto Logitech SB do Boom, Classic ou Touch funcionará. Acho que o arquivo Slim_Devices_Remote.ir no diretório "servidor" do LMS pode ser modificado para se adaptar a outros códigos, mas não tentei isso.
No modo AirPlay e Bluetooth, apenas esses controles remotos nativos são suportados, não adicionei a opção de fazer seu próprio mapeamento
Consulte "definir GPIO" abaixo para configurar o GPIO associado ao receptor infravermelho (opção "ir").
O parâmetro "set_GPIO" é usado para atribuir GPIO a várias funções.
GPIO pode ser configurado para fornecimento GND ou Vcc na inicialização. Isto é conveniente para alimentar dispositivos que consomem menos de 40 mA do conector lateral. Tenha cuidado porque não há verificações de conflito sendo feitas em qual GPIO você está alterando, então você pode danificar sua placa ou criar um conflito aqui.
O parâmetro <amp> pode ser usado para atribuir um GPIO que será definido para o nível ativo (padrão 1) quando a reprodução iniciar. Ele será redefinido quando o squeezelite ficar ocioso. O tempo limite de inatividade é definido na linha de comando do squeezelite por meio de -C <timeout>
O parâmetro <power> pode ser usado para atribuir um GPIO que será definido para o nível ativo (padrão 1) quando o player for ligado e redefinido quando desligado (no LMS, não se aplica ao AirPlay, Spotify ou BT).
Se você tiver um conector de áudio que suporte inserção (use :0 ou :1 para definir o nível quando inserido), poderá especificar a qual GPIO ele está conectado. Usar o parâmetro jack_mutes_amp permite silenciar o amplificador quando o fone de ouvido (por exemplo) estiver inserido.
Você também pode definir os LEDs de status Verde e Vermelho com seus respectivos estados ativos (:0 ou:1) ou especificar o chipset se usar LED RGB endereçável.
O parâmetro <ir> define o GPIO associado a um receptor IR. Não há necessidade de adicionar pullup ou capacitor
A sintaxe é:
<gpio>=Vcc|GND|amp[:1|0]|power[:1:0]|ir[:nec|rc5]|jack[:0|1]|green[:0|1|ws2812]|red[:0|1|ws2812]|spkfault[:0|1][,<repeated sequence for next GPIO>]
Você pode definir os padrões para jack, spkfault leds em tempo de compilação, mas o parâmetro nvs tem precedência, exceto para configurações nomeadas ((SqueezeAMP, Muse ...) onde estes são forçados em tempo de execução. Observe que gpio 36 e 39 são apenas de entrada e não podem usar interrupção Quando definido como falha no conector ou no alto-falante, uma pesquisa de 100 ms verifica seu valor, mas isso é caro.
É possível adicionar expansores GPIO usando barramento I2C ou SPI. Eles devem ser usados principalmente para botões, mas também podem suportar saídas de propósito genérico. Esses GPIOs adicionais podem ser numerados a partir de um valor arbitrário (40 e superior, pois esp32 tem GPIO 0..39). Então, esses novos GPIOs "virtuais" de (por exemplo) 100 a 115 podem ser usados na configuração de botões, set_GPIO ou outras configurações.
Cada expansor pode suportar até 32 GPIO. Para usar um expansor para botões, uma interrupção deve ser fornecida; o modo polling não é aceitável. Um expansor sem interrupção ainda pode ser configurado, mas apenas a saída será utilizável. Observe que a mesma interrupção pode ser compartilhada entre expansores, desde que eles usem dreno aberto ou coletores abertos (o que provavelmente todos fazem)
O parâmetro "gpio_exp_config" é uma lista separada por ponto e vírgula (;) com a seguinte sintaxe para cada expansor
model=<model>,addr=<addr>,[,port=system|dac][,base=<n>][,count=<n>][,intr=<gpio>][,cs=<gpio>][,speed=<Hz>]
Observe que o PWM ("led_brightness" abaixo) não é compatível com GPIOs expandidos e não pode ser usado para sinais de temporização precisos ou de alta velocidade, como CS, D/C, Reset e Ready. Botões, codificador rotativo, controle de amplificador e potência são suportados. Dependendo do chipset real, pullup ou pulldown podem ser suportados, então talvez seja necessário adicionar resistores externos (somente o MCP23x17 faz pullup). O pca8575 não é um ótimo chip, ele gera algumas interrupções espúrias quando usado para saída GPIO. Ao usar um expansor SPI, o barramento deve ser configurado usando barramento SPI compartilhado
Consulte set_GPIO para saber como definir os LEDs verdes e vermelhos (incluindo os RGB endereçáveis). Além disso, seu brilho pode ser controlado através do parâmetro "led_brigthness". A sintaxe é
[green=0..100][,red=0..100]
NB: Para configuração nomeada, o GPIO afetado pelo LED verde e vermelho não pode ser alterado, mas a opção de brilho se aplica
Uma faixa de LED com até 255 LEDs endereçáveis pode ser configurada para oferecer visualizações aprimoradas. O visualizador do medidor VU inclui um indicador de status da bateria (consulte Bateria). Atualmente apenas LEDs WS2812B são suportados. Defina a configuração de hardware da faixa de LED ou a sintaxe led_vu_config do NVS é
type=[WS2812],length=<n>,gpio=<dataPin>[,scale=<gain>]
onde <n> é o número de LEDs na faixa (1..255). Um valor de ganho <scale> (porcentagem) pode ser adicionado para melhorar as respostas do efeito.
A atualização mais recente do plug-in LMS é necessária para definir o modo do visualizador e o brilho na página de configurações do ESP32 para o player ou uma tela controlável (consulte os menus Extra/SqueezeESP32). O plug-in adiciona comandos CLI LMS adicionais.
| Comando | Notas |
|---|---|
| <playerid> led_visual [<modo>] [<brilho>] | Alterna ou seleciona o "modo" do visualizador. O brilho do visualizador (0..255) pode ser controlado usando a tag "brilho". |
| <playerid> dmx <R,G,B,R,G,B, ... R,G,B> [<offset>] | Define a cor do LED começando na posição "offset" com sequências de cores "R" (vermelho), "G" (verde) e "B" (azul). Adicione valores RGB adicionais à sequência delimitada para definir vários LEDs. |
Um codificador rotativo geral é suportado, mudança de quadratura com pressão. Tais encoders geralmente possuem 2 pinos para encoders (A e B), sendo comum C que deve ser aterrado e um pino SW opcional para prensa. A, B e SW devem ser puxados para cima, então o pull-up automático é fornecido pelo ESP32, mas você pode adicionar seus próprios resistores. Um pouco de filtragem em A e B (~470nF) ajuda no debouncing que não é feito por software.
O codificador normalmente é codificado para girar respectivamente para a esquerda, direita e pressionar LMS e para diminuir/aumentar/reproduzir volume em BT, AirPlay e Spotify. Usar a opção 'volume' torna codificado a alternância de diminuir/aumentar/reproduzir o volume o tempo todo (mesmo no LMS). A opção 'longpress' permite um modo alternativo quando SW é pressionado longamente. Nesse modo, esquerda é anterior, direita é próxima e pressionar é alternar. Cada pressão longa em SW alterna entre os modos (o comportamento real do modo principal depende do 'volume').
Existe também a possibilidade de utilizar a opção ‘knobonly’ (exclusiva com ‘volume’ e ‘longpress’). Este modo tenta oferecer uma navegação completa com um único botão que é um pouco distorcida devido aos princípios da UI do LMS. Esquerda, Direita e Pressionar obedecem às regras de navegação do LMS e principalmente Press sempre vai para o item inferior do submenu, mesmo ao navegar na Biblioteca de Música. Isso causa um desafio, pois não há botão ‘Play’, ‘Back’ ou ‘Pause’. As soluções alternativas são as seguintes:
A velocidade do clique duplo (ou esquerda-direita) pode ser definida usando o parâmetro opcional 'knobonly'. Esta não é uma solução perfeita e outras ideias são bem-vindas. Esteja ciente de que quanto mais tempo você definir a velocidade do clique duplo, menos responsiva será a interface. O motivo é que preciso aguardar esse atraso antes de decidir se é um clique único ou duplo. Também pode fazer com que a navegação no menu "hesite" sendo facilmente interpretada como 'Pausa'
Use o parâmetro rotary_config com a seguinte sintaxe:
A=<gpio>,B=<gpio>[,SW=gpio>[[,knobonly[=<ms>]]|[[,volume][,longpress]]]]
Nota de HW: todos os gpio usados para rotativo possuem pull-up interno, portanto normalmente não há necessidade de fornecer Vcc ao codificador. No entanto, se a placa do codificador que você está usando também tiver seu próprio pull-up mais forte que o do ESP32 (o que provavelmente é o caso), então haverá diafonia entre o gpio, então você deve trazer o Vcc. Observe o esquema da sua placa e você entenderá que esses pull-up da placa criam um pull-down "vencedor" quando qualquer outro pino está aterrado.
O SW gpio é opcional, você pode reafetá-lo para um botão puro se preferir, mas as opções de volume, toque longo e apenas botão fazem pouco sentido, pois o botão ausente desempenha um papel importante nesses modos. Você ainda pode ter o modo "volume", mas não poderá usá-lo para nada, exceto aumentar e diminuir o volume. Portanto, esteja ciente de que o uso da sintaxe [] é um pouco enganador acima.
Veja também a "NOTA IMPORTANTE" na seção "Botões" e lembre-se de que quando 'lms_ctrls_raw' (veja abaixo) é ativado, nenhuma dessas opções knobonly, volume, longpress se aplica, os códigos brutos dos botões (não as ações) são simplesmente enviados para o LMS
Observe que no esp32, gpio 36 e 39 são apenas de entrada e não podem usar interrupção, portanto não podem ser definidos como A ou B. Ao usá-los para SW, é usada uma pesquisa de 100 ms, o que é caro
Um codificador rotativo de volume dedicado é suportado, mudança de quadratura com pressão. O codificador é codificado para aumentar, diminuir o volume e alternar a reprodução para LMS, BT, AirPlay e Spotify (veja a nota acima para filtragem e nota de HW, bem como GPIO 36 e 39 no esp32)
Use o parâmetro volume_rotary com a seguinte sintaxe:
A=<gpio>,B=<gpio>[,SW=gpio>]
Os botões são descritos usando uma string JSON com a seguinte sintaxe
[
{ "gpio" : <num>,
"type" : " BUTTON_LOW | BUTTON_HIGH " ,
"pull" :[ true|false ],
"long_press" : <ms>,
"debounce" : <ms>,
"shifter_gpio" : <-1|num>,
"normal" : { "pressed" : " <action> " , "released" : " <action> " },
"longpress" : { <same> },
"shifted" : { <same> },
"longshifted" : { <same> },
},
{ ... },
{ ... },
] Onde (todos os parâmetros são opcionais, exceto gpio)
Onde <action> é o nome de outra configuração para carregar (remap) ou um entre
ACTRLS_NONE, ACTRLS_POWER, ACTRLS_VOLUP, ACTRLS_VOLDOWN, ACTRLS_TOGGLE, ACTRLS_PLAY,
ACTRLS_PAUSE, ACTRLS_STOP, ACTRLS_REW, ACTRLS_FWD, ACTRLS_PREV, ACTRLS_NEXT,
BCTRLS_UP, BCTRLS_DOWN, BCTRLS_LEFT, BCTRLS_RIGHT,
BCTRLS_PS1, BCTRLS_PS2, BCTRLS_PS3, BCTRLS_PS4, BCTRLS_PS5, BCTRLS_PS6, BCTRLS_PS7, BCTRLS_PS8, BCTRLS_PS9, BCTRLS_PS10,
KNOB_LEFT, KNOB_RIGHT, KNOB_PUSH,
ACTRLS_SLEEP,
Observe que o Actrls_sleep não é um botão real que pode ser enviado ao LMS, mas é um gancho para ativar o modo de suspensão profundo (consulte o sono).
Um que você criou tal string, use -o para preencher um novo parâmetro NVS com algum nome abaixo de 16 (?). Você pode ter o maior número possível de configurações. Em seguida, defina o parâmetro de configuração "actrls_config" com o nome da sua configuração padrão
Por exemplo, uma configuração chamada "botões":
[{ "gpio" : 4 , "type" : " BUTTON_LOW " , "pull" : true , "long_press" : 1000 , "normal" :{ "pressed" : " ACTRLS_VOLDOWN " }, "longpress" :{ "pressed" : " buttons_remap " }},
{ "gpio" : 5 , "type" : " BUTTON_LOW " , "pull" : true , "shifter_gpio" : 4 , "normal" :{ "pressed" : " ACTRLS_VOLUP " }, "shifted" :{ "pressed" : " ACTRLS_TOGGLE " }}]Define dois botões
Enquanto a configuração chamada "button_remap"
[{ "gpio" : 4 , "type" : " BUTTON_LOW " , "pull" : true , "long_press" : 1000 , "normal" :{ "pressed" : " BCTRLS_DOWN " }, "longpress" :{ "pressed" : " buttons " }},
{ "gpio" : 5 , "type" : " BUTTON_LOW " , "pull" : true , "shifter_gpio" : 4 , "normal" :{ "pressed" : " BCTRLS_UP " }}]Define dois botões
Abaixo está uma interface de 2 butões difíceis, mas funcionais, para o seu prazer de decodificar:
actrls_config :
buttons
buttons :
[{ "gpio" : 4 , "type" : " BUTTON_LOW " , "pull" : true , "long_press" : 1000 ,
"normal" :{ "pressed" : " ACTRLS_VOLDOWN " },
"longpress" :{ "pressed" : " buttons_remap " }},
{ "gpio" : 5 , "type" : " BUTTON_LOW " , "pull" : true , "long_press" : 1000 , "shifter_gpio" : 4 ,
"normal" :{ "pressed" : " ACTRLS_VOLUP " },
"shifted" :{ "pressed" : " ACTRLS_TOGGLE " },
"longpress" :{ "pressed" : " ACTRLS_NEXT " }}
] buttons_remap :
[{ "gpio" : 4 , "type" : " BUTTON_LOW " , "pull" : true , "long_press" : 1000 ,
"normal" :{ "pressed" : " BCTRLS_DOWN " },
"longpress" :{ "pressed" : " buttons " }},
{ "gpio" : 5 , "type" : " BUTTON_LOW " , "pull" : true , "long_press" : 1000 , "shifter_gpio" : 4 ,
"normal" :{ "pressed" : " BCTRLS_UP " },
"shifted" :{ "pressed" : " BCTRLS_PUSH " },
"longpress" :{ "pressed" : " ACTRLS_PLAY " },
"longshifted" :{ "pressed" : " BCTRLS_LEFT " }}
]Nota importante : o LMS também suporta a possibilidade de enviar códigos de botão 'RAW'. É um pouco complicado, então tenha paciência comigo. Os botões podem ser processados pelo Squeezeesp32 e mapeados para uma "função" como reproduzir/pausar ou podem ser enviados para o código LMS (RAW) e a lógica completa da imprensa/liberação/longpress é tratada pelo LMS, você não T tem algum controle sobre isso.
O benefício do modo "Raw" é que você pode construir um jogador o mais próximo possível de um boom (por exemplo), mas não pode usar a função de remapeamento nem as lógicas de longantima ou mudança para fazer seu próprio mapeamento quando tiver um Conjunto limitado de botões. No modo 'RAW', tudo o que você realmente precisa definir é o mapeamento entre o GPIO e o botão. No que diz respeito ao LMS, qualquer outra opção nessas cargas úteis JSON não importa. Agora, quando você usa o BT ou o AirPlay, o construto JSON completo descrito acima se aplica totalmente, para que as opções de mudança, longpressas, ainda funcionam.
Esteja ciente de que, ao usar o modo não "cru", a CLI (interface da linha de comando) do LMS é usada e deve estar disponível sem senha
Não há opção boa ou ruim, é sua escolha. Use o parâmetro NVS "lms_ctrls_raw" para alterar essa opção
Observe que o GPIO 36 e 39 são apenas de entrada e não pode usar a interrupção. Ao usá -los para um botão, é iniciada uma pesquisa de 100ms, o que é caro. Longa imprensa também provavelmente não funcionará muito bem
O Wired Ethernet é suportado pelo ESP32 com várias opções, mas o Squeezeesp32 está suportando apenas um microchip LAN8720 com uma interface RMII como esta ou pontes Spi-Ethernet como o DAVICOM DM9051 que ou W5500 assim.
Nota: Os botões toque que podem ser encontrados em algum quadro como o Lyrat v4.3 não são suportados atualmente.
| Gpio | Sinal rmii | Notas |
|---|---|---|
| Gpio21 | Tx_en | Emac_tx_en |
| GPIO19 | TX0 | Emac_txd0 |
| Gpio22 | TX1 | Emac_txd1 |
| GPIO25 | Rx0 | Emac_rxd0 |
| GPIO26 | RX1 | Emac_rxd1 |
| GPIO27 | CRS_DV | Emac_rx_drv |
| Gpio0 | Ref_clk | Relógio de 50MHz |
model=lan8720,mdc=<gpio>,mdio=<gpio>[,rst=<gpio>]
Conectar um pino de redefinição para o LAN8720 é opcional, mas recomendado para evitar que o GPIO0 (relógio de entrada de 50MHz) bloqueie o ESP32 no modo de download no tempo de inicialização.
A APLL do ESP32 é necessária para o codec de áudio, por isso precisamos de um LAN8720 que forneça um
