- تشغيل نفس الإشارة الصوتية في غرف متعددة (موسيقى خلفية)
- القدرة على إعادة إنتاج الإشارة الصوتية الخاصة بها في كل غرفة
- إمكانية تشغيل الإخطارات الموزعة (على سبيل المثال ، يرن جرس الباب ليس بالقرب من الباب بمستوى صوت كامل ، ولكن بمستوى صوت منخفض من خلال الكل أو من خلال بعض السماعات).
في هذه المقالة ، سأشارك مثالًا على بناء نظام متعدد الغرف في شقتي الخاصة. كانت الفكرة الأصلية هي إنشاء موسيقى خلفية (المحطة الإذاعية المختارة) بمستوى صوت منخفض في جميع الغرف ، بدلاً من نقطة واحدة حيث كان يجب زيادة مستوى الصوت.
كان أساس النظام متعدد الغرف هو حل Snapcast المجاني . يتم إطلاق جزء الخادم على الخادم الرئيسي ؛ إما Orange PI صفر حاسبات صغيرة ذات مكبرات صوت نشطة متصلة بها ، أو أكثر قوة Rasberry PI مع مشغل وسائط Kodi مثبت (موزع Libreelec) يعمل كعملاء حسب الغرفة.
الملامح الرئيسية للنظام النهائي
- تشغيل محطة إذاعية عبر الإنترنت في الخلفية
- القدرة على تشغيل الموسيقى في غرف متعددة (أو على عميل محدد بشكل منفصل) باستخدام Airplay أو UPnP أو من خلال مشغل Plex. هناك خطط لإضافة دعم البلوتوث ، على الرغم من أن هذا لا يتعلق بي بشكل خاص
- تشغيل محتوى عشوائي من جهاز كمبيوتر عبر واجهة ويب
- تغيير محطة الراديو قيد التشغيل حاليًا يدويًا أو وفقًا للجدول الزمني
- التعيين لكل عميل من أي مصدر
- يتم التحكم في مستوى الصوت بشكل فردي لكل جهاز صوت (يعمل على النحو التالي: يتم ضبط عنصر التحكم في نظام الصوت على الحد الأقصى ، ويتم ضبط حجم كل snapclient من الخادم إذا لزم الأمر (يتم ضبطه أيضًا على الحد الأقصى عادة) ، ويتم ضبط مستوى الصوت العام من المصدر الذي يتم التشغيل منه - الهاتف أو مشغل كمبيوتر أو mpd)
يتم العملاء الآن بدون رتوش - هناك armbian ، حيث يتم تثبيت shairport و snapclient ، وهناك خطط لتقديم upmpdcli و plexamp ، بحيث يعمل كل عميل كنقطة عالمية تنتج الصوت باستخدام أي بروتوكول ممكن. المشكلة الرئيسية التي لا تزال تمنع القيام بذلك هي أن Linux لا يسمح بمشاركة جهاز صوتي ALSA واحد بين عدة برامج ، وهنا عليك إما إيقاف تشغيل الآخرين أثناء تشغيل الصوت من خلال خدمة واحدة ، أو محاولة استخدام Pulseaudio ، وهو أمر مستحيل في حالة Snapclient (Snapcast) يعمل حصريًا من خلال ALSA ، لأنه يقلل من التأخيرات وبسبب هذا ، فإن صوت جميع المصادر متزامن تمامًا. يمكن العثور على مزيد من التفاصيل في وثائق Snapcast).
تم تصميم جانب الخادم كخدمات صغيرة على شكل عدة حاويات أرصفة مدمجة في حزمة. في البداية ، كانت هناك خطط لإطلاق حاويات في مجموعة Swarm (نعم ، لدي جهازي كمبيوتر في المنزل مدمجين في مجموعة Swarm ، والتي تعمل على تشغيل جميع الخدمات التي أحتاجها ولا أحتاجها حقًا في المنزل) ، ولكن كان يجب التخلي عن هذه الفكرة ، والمكدس عبر إنشاء عامل الميناء يتم تشغيل ملف .yml على أحد أجهزة الكمبيوتر. الموثوقية عرجاء بالطبع ، لكنها كافية للمنزل. سبب عدم القدرة على البدء في المجموعة هو أن خادم Snapcast يستخدم fifo لتلقي الدفق الصوتي (تعمل سلسلة نموذجية مثل هذه - يتم تشغيل الصوت باستخدام mpd ، و fifo هو جهاز الإخراج ، الذي يقرأ منه snapserver وينقل الدفق إلى جميع العملاء). ولكن نظرًا لحقيقة أن الكتلة لا يمكنها مشاركة الحجم ،الذي يستضيف فيفو بين عدة عقد (لا يستخدم فيفو على مضيف وإعادة توجيهه باستخدام نظام الملفات الموزعة أيضًا. على الرغم من أنه قد يكون ممكنًا من خلال nfs ، لم أجربه بعد) ، ومن المستحيل أيضًا إجبار كتلة السرب على تشغيل جميع الحاويات على عقدة واحدة ، الطريقة الوحيدة لمنح جميع الخدمات حق الوصول إلى FIFA هي تشغيل كل شيء على عقدة واحدة (يمكنك بالطبع إنشاء جهاز افتراضي أو حاوية ضخمة ، حيث يتم إطلاق كل شيء من خلال المشرف ، لكنني قررت عدم القيام بذلك).الطريقة الوحيدة لمنح جميع الخدمات حق الوصول إلى FIFA هي تشغيل كل شيء على عقدة واحدة (يمكنك بالطبع إنشاء جهاز افتراضي أو حاوية ضخمة ، حيث يتم إطلاق كل شيء من خلال المشرف ، لكنني قررت عدم القيام بذلك).الطريقة الوحيدة لمنح جميع الخدمات حق الوصول إلى FIFA هي تشغيل كل شيء على عقدة واحدة (يمكنك بالطبع إنشاء جهاز افتراضي أو حاوية ضخمة ، حيث يتم إطلاق كل شيء من خلال المشرف ، لكنني قررت عدم القيام بذلك).
تكوين المكدس
1) Snapserver. حاوية خادم Snapcast. وهي متاحة على المنافذ 1704 و 1705 وفي الشبكة المنزلية ، والمكالمات إليها تمر عبر اسم DNS snapserver.local. إنها تعرف كيف تعلن عن نفسها من خلال Avahi ، ولكن عند العمل في avahi docker ، تمر الإعلانات عبر حاوية منفصلة (لا يتم تضمينها في هذا المكدس).
2) سنابكاستر. خدمة الويب Snapserver. متوفر على المنفذ 5011 (متاح على شكل snapcastr.local عبر الوكيل العكسي المحلي).
3) سناب شانجر. نص Python النصي الذي يوزع مصادر الصوت ويحول العملاء إلى مصدر الصوت ذي الأولوية الأعلى النشط حاليًا. على سبيل المثال ، تحظى إذاعة الإنترنت بالأولوية الدنيا ويتم تشغيلها دائمًا. عند تشغيل الموسيقى من هاتف عبر Airplay ، فإنه يتحول إلى هذا الدفق ، وإذا كانت هناك إشارة من منزل ذكي في هذه اللحظة ، فسيتم التبديل إليه. عندما يتم إيقاف الدفق ، فإنه يتحول مرة أخرى إلى التدفقات النشطة ذات الأولوية القصوى. لكل عميل ، يمكنك تحديد قائمة سلاسل العمليات والأولويات الخاصة بهم.
4) سنابكرون. حاوية تحتوي على cron يمكنها تشغيل البرامج النصية في وقت معين ، على سبيل المثال ، تغيير مستوى الصوت للعملاء (قم بإيقاف تشغيل الموسيقى في غرفة النوم في الليل تمامًا).
5) mpd. مثيل mpd لتشغيل راديو الإنترنت. إعادة توجيهها إلى الشبكة المنزلية على منفذ غير قياسي 36602.
6) راديو. نصوص pyhthon التي تتأكد من تشغيل الراديو دائمًا (هناك حالات عند انقطاع الاتصال ، أو يبدو أن الاتصال موجود ، ولكن لا يتم تشغيل الصوت) ، بالإضافة إلى تبديل محطات الراديو ومستوى الصوت وفقًا للوقت من اليوم.
7-8) mpd.fm و pifi - قذائف ويب لتشغيل محطات الراديو. قطعتين من نفس النوع للتجارب.
9) موبيدي. قذيفة أخرى (تعرف أيضا بخادم mpd منفصل) لتشغيل الموسيقى. يعمل كخادم mpd منفصل ويستجيب لمنفذ mpd القياسي - 6600. يمكن استخدامه للاستماع إلى الموسيقى. يستخدم دفقه الخاص ويعمل بشكل مستقل عن mpd لمحطات الراديو.
10-12) مزامنة شيربورت ، upmpdcli ، plexamp - حاويات مع العملاء المطابقين. تستخدم كل حاوية مثيلها الخاص من mpd ، للكتابة على موقع FIFA الخاص بها. لذلك كل عميل لديه تيار مستقل خاص به.
وبالتالي ، يدعم المكدس الآن:
- العديد من مصادر الصوت المستقلة مع الاختيار التعسفي بينها - افتراضي ، uPnP ، Mopidy ، Plexamp ، AirPlay وراديو الإنترنت.
- إدارة خادم Snapcast نفسه باستخدام Snapcastr.
- مجموعة من البرامج النصية لضمان صوت لاسلكي موثوق به وبدون انقطاع.
- التحكم في تشغيل الراديو باستخدام pi-fi أو mpd.fm (بالإضافة إلى ذلك ، قمت بتكوين التحكم في مثيل mpd هذا باستخدام العقدة الحمراء المستخدمة في أتمتة منزلي).
رابط المستودع