- Reproducción de la misma señal de audio en varias salas (música de fondo)
- La capacidad de reproducir su propia señal de audio en cada habitación.
- Posibilidad de reproducción distribuida de notificaciones (por ejemplo, el timbre suena no cerca de la puerta a todo volumen, sino a un volumen bajo a través de todos o mediante ciertos altavoces).
En este artículo, compartiré un ejemplo de construcción de un sistema de varias habitaciones en mi propio departamento. La idea original era crear música de fondo (la estación de radio seleccionada) a bajo volumen en todas las habitaciones, en lugar de un punto donde el volumen tenía que aumentarse.
La base del sistema multisala fue la solución gratuita Snapcast . La parte del servidor se inicia en el servidor doméstico; los minicomputadores Orange PI zero con altavoces activos conectados a ellos o Rasberry PI más potente con un reproductor multimedia Kodi instalado (distribuidor de Libreelec) actúan como clientes por habitación.
Características clave del sistema terminado.
- Reproduciendo una estación de radio de Internet en el fondo
- La capacidad de reproducir música en una sala múltiple (o en un cliente seleccionado por separado) usando Airplay, UPnP o mediante un reproductor Plex. Hay planes para agregar compatibilidad con Bluetooth, aunque esto no es particularmente relevante para mí
- Reproducción de contenido arbitrario desde una computadora a través de una interfaz web
- Cambio de la estación de radio que se está reproduciendo manualmente o de acuerdo con el horario
- Asignación a cada cliente de cualquier fuente.
- El control de volumen es individualmente para cada dispositivo de audio (funciona así: el control del sistema de audio propio está configurado al máximo, el volumen de cada snapclient se ajusta desde el servidor si es necesario (generalmente también está configurado al máximo) y el nivel de volumen general se ajusta desde la fuente desde la que se está reproduciendo: el teléfono , reproductor de computadora o mpd)
Los clientes ahora se hacen sin adornos: hay armbian, en el que se instalan shairport y snapclient, y hay planes para entregar upmpdcli y plexamp, de modo que cada cliente actúe como un punto universal que reproduzca el sonido utilizando cualquier protocolo posible. El principal problema que aún impide que esto se haga es que Linux no permite compartir un dispositivo de audio ALSA entre varios programas, y aquí debe apagar otros mientras reproduce sonido a través de un servicio, o tratar de usar Pulseaudio, que es imposible en el caso de Snapclient (Snapcast funciona exclusivamente a través de ALSA, ya que minimiza los retrasos y debido a esto, el sonido de todas las fuentes es absolutamente sincrónico. Más detalles se pueden encontrar en la documentación de Snapcast).
El lado del servidor está diseñado como microservicios en forma de varios contenedores acoplables combinados en una pila. Inicialmente, había planes para lanzar contenedores en el clúster Swarm (sí, tengo dos computadoras en casa combinadas en un clúster Swarm, que ejecuta todos los servicios que necesito y realmente no necesito en el hogar), pero esta idea tuvo que ser abandonada, y la pila a través de docker-compose El archivo .yml se ejecuta en una de las computadoras. La fiabilidad es, por supuesto, poco convincente, pero suficiente para el hogar. La razón de la imposibilidad de iniciar en el clúster es que el servidor Snapcast usa quince para recibir la transmisión de audio (una cadena típica funciona así: el sonido se reproduce usando mpd, el quince es el dispositivo de salida, desde el cual el servidor de instantáneas lee y transmite la transmisión a todos los clientes). Pero debido al hecho de que el clúster no puede compartir el volumen,que aloja un fifo entre varios nodos (usar un fifo en un host y reenviarlo usando un sistema de archivos distribuido tampoco funciona. Aunque puede ser posible a través de nfs, aún no lo he probado), y también es imposible forzar el enjambre de clúster para ejecutar todos los contenedores en un nodo, la única forma de dar acceso a todos los servicios a fifo es ejecutar todo en un nodo (por supuesto, puede hacer una máquina virtual o un contenedor gigante, donde todo lo posible se inicia a través de un supervisor, pero decidí no hacerlo).la única forma de dar acceso a todos los servicios a fifo es ejecutar todo en un nodo (por supuesto, puede hacer una máquina virtual o un contenedor gigante, donde todo lo posible se inicia a través de un supervisor, pero decidí no hacerlo).la única forma de dar acceso a todos los servicios a fifo es ejecutar todo en un nodo (por supuesto, puede hacer una máquina virtual o un contenedor gigante, donde todo lo posible se inicia a través de un supervisor, pero decidí no hacerlo).
Composición de la pila
1) Snapserver. Contenedor de servidor Snapcast. Está disponible en los puertos 1704, 1705 y en la red doméstica, las llamadas pasan por el nombre dns snapserver.local. Sabe cómo anunciarse a través de Avahi, pero cuando trabaja en avahi docker, los anuncios pasan por un contenedor separado (no está incluido en esta pila).
2) Snapcastr. Servicio web Snapserver. Disponible en el puerto 5011 (disponible como snapcastr.local a través del proxy inverso local).
3) Snapchanger. Script de Python que analiza las fuentes de audio y cambia los clientes a la fuente de audio de mayor prioridad que está actualmente activa. Por ejemplo, la radio por internet tiene la prioridad más baja y siempre se reproduce. Al reproducir música desde un teléfono a través de Airplay, cambia a esta transmisión, y si en este momento hay una señal de un hogar inteligente, cambiará a ella. Cuando se detiene una secuencia, vuelve a las secuencias activas con la prioridad más alta. Para cada cliente, puede especificar su lista de hilos y prioridades para ellos.
4) Snapcron. Un contenedor con cron que puede ejecutar scripts en un momento determinado, por ejemplo, cambiando el volumen de los clientes (apague la música en el dormitorio por la noche por completo).
5) mpd. instancia mpd para reproducir radio por internet. Reenviado a la red doméstica en un puerto no estándar 36602.
6) radio. scripts de pyhthon que aseguran que la radio siempre se reproduce (hay casos en los que se interrumpe la conexión, o la conexión parece estar allí, pero el sonido no se reproduce), así como cambiar estaciones de radio y volumen según la hora del día.
7-8) mpd.fm y pifi - shells web para reproducir estaciones de radio. Dos piezas del mismo tipo para experimentos.
9) mopidy. Otro shell (también conocido como un servidor mpd separado) para reproducir música. Actúa como un servidor mpd separado y responde al puerto mpd estándar - 6600. Se puede usar para escuchar música. Utiliza su propia transmisión y funciona independientemente de mpd para estaciones de radio.
10-12) shairport-sync, upmpdcli, plexamp - contenedores con los clientes correspondientes. Cada uno de los contenedores utiliza su propia instancia de mpd, escribiendo en su propio fifo. Entonces cada cliente tiene su propia secuencia independiente.
Por lo tanto, la pila ahora admite:
- Varias fuentes de sonido independientes con elección arbitraria entre ellas: predeterminada, uPnP, Mopidy, Plexamp, AirPlay y radio por Internet.
- Administrar el servidor Snapcast con Snapcastr.
- Un conjunto de scripts para garantizar un sonido de radio de fondo confiable e ininterrumpido.
- Controlando la reproducción de radio usando pi-fi o mpd.fm (además, configuré el control de esta instancia de mpd usando el Nodo-rojo usado en mi domótica).
Enlace de repositorio