スナップキャストバジェットマルチルーム

マルチルームオーディオシステムを作成すると、一度に複数の目標を達成できます。

1. 複数の部屋（バックグラウンドミュージック）で同じオーディオ信号を再生する
2. 各部屋で独自のオーディオ信号を再生する機能
3. 通知の分散再生の可能性（たとえば、ドアベルが全音量でドアの近くではなく、すべてまたは特定のスピーカーから小音量で鳴る）。

この記事では、自分のアパートにマルチルームシステムを構築する例を紹介します。元のアイデアは、音量を上げる必要がある1箇所ではなく、すべての部屋で小音量でBGM（選択したラジオ局）を作成することでした。



マルチルーム システムの基盤は、無料のSnapcastソリューションでした。サーバー部分はホームサーバー上で起動され、アクティブスピーカーが接続されたOrange PI zeroミニコンピューター、またはKodiメディアプレーヤー（ディストリビューターLibreelec）がインストールされたより強力なRasberry PIが部屋ごとにクライアントとして機能します。

完成したシステムの主な機能

1. バックグラウンドでインターネットラジオ局を再生する
2. Airplay、UPnP、またはPlexプレーヤーを使用して、マルチルーム（または個別に選択したクライアント）で音楽を再生する機能。Bluetoothサポートを追加する予定がありますが、これは特に私には関係ありません
3. Webインターフェイスを介してコンピューターから任意のコンテンツを再生する
4. 現在再生中のラジオ局の手動またはスケジュールによる変更
5. 任意のソースの各クライアントへの割り当て
6. ボリュームコントロールはオーディオデバイスごとに個別に設定されます（これは次のように機能します：独自のオーディオシステムコントロールが最大に設定され、必要に応じて各snapclientのボリュームがサーバーから調整され（通常は最大にも設定されます）、全体のボリュームレベルは再生のソースから調整されます-電話、コンピュータプレーヤーまたはMPD）

これでクライアントは飾り気なしで完了しました-shairportとsnapclientがインストールされているarmbianがあり、upmpdcliとplexampを提供する計画があるため、各クライアントはあらゆる可能なプロトコルを使用してサウンドを再現するユニバーサルポイントとして機能します。これがまだ行われない主な問題は、Linuxが複数のプログラム間で1つのALSAオーディオデバイスを共有することを許可していないことです。ここでは、1つのサービスでサウンドを再生している間、他のオーディオデバイスをオフにするか、Snapclient（Snapcastの場合は不可能）を使用する必要があります。遅延を最小限に抑え、これによりすべてのソースのサウンドが完全に同期しているため、ALSAを通じてのみ機能します。詳細は、Snapcastのドキュメントを参照してください）。



サーバー側は、いくつかのDockerコンテナーをスタックに結合した形のマイクロサービスとして設計されています。当初、Swarmクラスターでコンテナーを起動する計画がありました（はい、私は自宅に2台のコンピューターをSwarmクラスターに結合しており、必要なすべてのサービスを実行し、実際には自宅では必要ありません）。このアイデアは破棄し、docker-compose .ymlファイルは、いずれかのコンピューターで実行されます。信頼性はもちろん不十分ですが、家庭には十分です。クラスターで開始できない理由は、Snapcastサーバーがfifoを使用してオーディオストリームを受信するためです（通常、チェーンは次のように機能します-サウンドはmpdを使用して再生され、fifoは出力デバイスであり、snapserverがストリームを読み取ってすべてのクライアントに送信します）。しかし、クラスターがボリュームを共有できないという事実により、複数のノード間でfifoをホストします（ホストでfifoを使用し、分散ファイルシステムを使用してそれを転送することもできません。nfsで可能かもしれませんが、まだ試していません）。また、1つのノードですべてのコンテナを実行するようにswarmクラスタを強制することもできません。すべてのサービスにfifoへのアクセスを許可する唯一の方法は、すべてを1つのノードで実行することです（もちろん、仮想マシン、または1つの巨大なコンテナーを作成できます。そこでは、可能なすべてのものがスーパーバイザー経由で起動されますが、私はそれをしないことにしました）。すべてのサービスにfifoへのアクセスを許可する唯一の方法は、すべてを1つのノードで実行することです（もちろん、仮想マシン、または1つの巨大なコンテナーを作成できます。そこでは、可能なすべてのものがスーパーバイザーを介して起動されますが、私はそれをしないことにしました）。すべてのサービスにfifoへのアクセスを許可する唯一の方法は、1つをすべてのノードで実行することです（もちろん、すべてをスーパーバイザー経由で起動する仮想マシンまたは1つの巨大なコンテナーを作成できますが、私はそれをしないことにしました）。

スタック構成

1）Snapserver。Snapcastサーバーコンテナー。これは、ポート1704、1705、およびホームネットワークで使用でき、DNSへの呼び出しは、dns名snapserver.localを経由します。Avahiを介してそれ自体をアナウンスする方法を知っていますが、avahi Dockerで作業している場合、アナウンスは別のコンテナーを経由します（このスタックには含まれていません）。



2）Snapcastr。Snapserver Webサービス。ポート5011で利用可能（ローカルリバースプロキシ経由でsnapcastr.localとして利用可能）。



3）スナップチェンジャー。オーディオソースを解析し、クライアントを現在アクティブな最高優先度のオーディオソースに切り替えるPythonスクリプト。たとえば、インターネットラジオは優先順位が最も低く、常に再生されます。 Airplayを介して電話から音楽を再生すると、このストリームに切り替わり、現時点でスマートホームからの信号がある場合は、それに切り替わります。ストリームが停止すると、優先順位が最も高いアクティブなストリームに戻ります。クライアントごとに、スレッドのリストとそれらの優先順位を指定できます。



4）Snapcron。特定の時間にスクリプトを実行できるcronを含むコンテナー。たとえば、クライアントの音量を変更します（夜に寝室の音楽を完全にオフにします）。



5）mpd。インターネットラジオを再生するためのmpdインスタンス。非標準ポート36602でホームネットワークに転送されます。6



）無線。ラジオが常に再生されることを確認するpyhthonスクリプト（接続が中断されたり、接続が存在しているように見えても、音が再生されない場合があります）、およびラジオ局と音量を時刻に応じて切り替えます。



7-8）mpd.fmおよびpifi-ラジオ局を再生するためのWebシェル。実験用に同じタイプの2個。



9）モディピー。音楽を再生するための別のシェル（別のmpdサーバー）。独立したmpdサーバーとして機能し、標準のmpdポート-6600に応答します。音楽を聴くために使用できます。独自のストリームを使用し、ラジオ局のmpdとは独立して動作します。



10-12）shairport-sync、upmpdcli、plexamp-対応するクライアントを持つコンテナー。各コンテナーは、独自のmpdのインスタンスを使用して、独自のfifoに書き込みます。したがって、各クライアントには独自の独立したストリームがあります。



したがって、スタックは次をサポートします。

• いくつかの独立した音源、それらの間で任意の選択-デフォルト、uPnP、Mopidy、Plexamp、AirPlayおよびインターネットラジオ。
• Snapcastrを使用したSnapcastサーバー自体の管理。
• 信頼性が高く、中断されないバックグラウンドラジオサウンドを保証するスクリプトのセット。
• pi-fiまたはmpd.fmを使用したラジオ再生の制御（さらに、ホームオートメーションで使用されているNode-redを使用して、このmpdインスタンスの制御を構成しました）。

リポジトリリンク