- Tocando o mesmo sinal de áudio em várias salas (música de fundo)
- A capacidade de reproduzir seu próprio sinal de áudio em cada sala
- Possibilidade de reprodução distribuída de notificações (por exemplo, a campainha toca não perto da porta em volume máximo, mas em volume baixo em todos ou em determinados alto-falantes).
Neste artigo, compartilharei um exemplo de construção de um sistema com várias salas no meu próprio apartamento. A idéia original era criar música de fundo (a estação de rádio selecionada) em volume baixo em todas as salas, em vez de um ponto em que o volume precisava ser aumentado.
A base do sistema com várias salas foi a solução gratuita do Snapcast . A parte do servidor é iniciada no servidor doméstico: os minicomputadores Orange PI zero com alto-falantes ativos conectados a eles ou o Rasberry PI mais poderoso com um media player Kodi instalado (distribuidor Libreelec) atuam como clientes por divisão.
Principais recursos do sistema acabado
- Tocando uma estação de rádio da Internet em segundo plano
- A capacidade de tocar música em uma sala múltipla (ou em um cliente selecionado separadamente) usando Airplay, UPnP ou através de um player Plex. Existem planos para adicionar suporte bluetooth, embora isso não seja particularmente relevante para mim
- Reproduzindo conteúdo arbitrário de um computador por meio de uma interface da web
- Mudança da estação de rádio atualmente sendo reproduzida manualmente ou de acordo com a programação
- Atribuição a cada cliente de qualquer origem
- O controle de volume é individual para cada dispositivo de áudio (funciona da seguinte maneira: o controle do sistema de áudio é definido como máximo, o volume de cada snapclient é ajustado no servidor, se necessário (geralmente também é definido como máximo), e o nível geral de volume é ajustado na fonte da qual a reprodução está sendo executada - o telefone , player de computador ou mpd)
Agora, nos clientes, isso é feito sem frescuras - existe um armbian no qual shairport e snapclient estão instalados e há planos de fornecer upmpdcli e plexamp, para que cada cliente atue como um ponto universal que reproduz o som usando qualquer protocolo possível. O principal problema que ainda impede que isso seja feito é que o Linux não permite compartilhar um dispositivo de áudio ALSA entre vários programas, e aqui você deve desligar outros enquanto reproduz som através de um serviço ou tentar usar o Pulseaudio, que é impossível no Snapclient (Snapcast) funciona exclusivamente através do ALSA, porque minimiza os atrasos e, por isso, o som de todas as fontes é absolutamente síncrono.Mais informações podem ser encontradas na documentação do Snapcast).
O lado do servidor foi projetado como microsserviços na forma de vários contêineres de docker combinados em uma pilha. Inicialmente, havia planos de lançar contêineres no cluster Swarm (sim, eu tenho dois computadores em casa combinados em um cluster Swarm, que executa todos os serviços que eu preciso e que realmente não preciso em casa), mas essa ideia teve que ser abandonada e a pilha via docker-compose O arquivo .yml é executado em um dos computadores. A confiabilidade é obviamente fraca, mas suficiente para o lar. O motivo da incapacidade de iniciar no cluster é que o servidor Snapcast usa o fifo para receber o fluxo de áudio (uma cadeia típica funciona assim - o som é reproduzido usando mpd, o fifo é o dispositivo de saída, do qual o snapserver lê e transmite o fluxo para todos os clientes). Mas, devido ao fato de que o cluster não pode compartilhar volume,que hospeda um fifo entre vários nós (usar um fifo em um host e encaminhá-lo usando um sistema de arquivos distribuído também não funciona. Embora possa ser possível através do nfs, eu ainda não tentei), e também é impossível forçar o cluster swarm a executar todos os contêineres em um nó, a única maneira de conceder acesso a todos os serviços ao fifo é executar tudo em um nó (é claro, você pode criar uma máquina virtual ou um contêiner gigantesco, onde tudo é lançado através do supervisor, mas eu decidi não fazer isso).a única maneira de conceder acesso a todos os serviços ao fifo é executar tudo em um nó (é claro, você pode criar uma máquina virtual ou um contêiner gigantesco, onde tudo é lançado através do supervisor, mas eu decidi não fazer isso).a única maneira de conceder acesso a todos os serviços ao fifo é executar tudo em um nó (é claro, você pode criar uma máquina virtual ou um contêiner gigantesco, onde tudo é lançado através do supervisor, mas eu decidi não fazer isso).
Composição da pilha
1) Snapserver. Contêiner do servidor Snapcast. Está disponível nas portas 1704, 1705 e na rede doméstica, as chamadas passam pelo nome de DNS snapserver.local. Ele sabe como se anunciar através do Avahi, mas ao trabalhar no docker avahi, os anúncios passam por um contêiner separado (não está incluído nesta pilha).
2) Snapcastr. Serviço da Web Snapserver. Disponível na porta 5011 (disponível como snapcastr.local via proxy reverso local).
3) Snapchanger. Script Python que analisa fontes de áudio e alterna clientes para a fonte de áudio de maior prioridade atualmente ativa. Por exemplo, o rádio na Internet tem a menor prioridade e sempre é reproduzido. Ao reproduzir música de um telefone via Airplay, ele muda para esse fluxo e, nesse momento, há um sinal de uma casa inteligente, ele muda para ele. Quando um fluxo é parado, ele volta para os fluxos ativos com a maior prioridade. Para cada cliente, você pode especificar sua lista de threads e prioridades para eles.
4) Snapcron. Um contêiner cron que pode executar scripts em um determinado horário, por exemplo, alterando o volume nos clientes (desligue completamente a música no quarto à noite).
5) mpd. instância mpd para tocar rádio na Internet. Encaminhado para a rede doméstica em uma porta não padrão 36602.
6) rádio. scripts pyhthon que garantem que o rádio seja sempre reproduzido (há casos em que a conexão é interrompida ou a conexão parece estar presente, mas o som não é reproduzido), além de alternar estações e volume de rádio, dependendo da hora do dia.
7-8) mpd.fm e pifi - web shells para reproduzir estações de rádio. Duas peças do mesmo tipo para experimentos.
9) mopidy. Outro shell (também conhecido como servidor mpd separado) para tocar música. Ele atua como um servidor mpd separado e responde à porta mpd padrão - 6600. Pode ser usado para ouvir música. Ele usa seu próprio fluxo e funciona independentemente do mpd para estações de rádio.
10-12) shairport-sync, upmpdcli, plexamp - contêineres com clientes correspondentes. Cada um dos contêineres usa sua própria instância do mpd, gravando em seu próprio fifo. Portanto, cada cliente tem seu próprio fluxo independente.
Assim, a pilha agora suporta:
- Várias fontes de som independentes com escolha arbitrária entre elas - Default, uPnP, Mopidy, Plexamp, AirPlay e rádio na Internet.
- Gerenciando o próprio servidor Snapcast com o Snapcastr.
- Um conjunto de scripts para garantir um som de rádio em segundo plano confiável e ininterrupto.
- Controlando a reprodução de rádio usando pi-fi ou mpd.fm (além disso, configurei o controle dessa instância mpd usando o Node-red usado na minha automação residencial).
Link do repositório