لم يكن جهاز Ubuntu الافتراضي يفتقد بطاقة صوت. فقد اكتشف Ubuntu جهاز صوت افتراضيًا من نوع ICH9، وأظهر نشاطًا صوتيًا للنظام وFirefox، ووفّر مخرجًا صوتيًا داخليًا. كانت المشكلة الحقيقية أسفل نظام التشغيل الضيف: إذ تم ضبط الواجهة الخلفية لصوت QEMU في الجهاز الافتراضي على none، لذلك كان لدى الضيف جهاز صوت افتراضي، لكن لم يكن لديه مكان لإرسال الصوت إليه.
تمثّل الحل المجتمعي في تفعيل واجهة خلفية لصوت SPICE داخل XML الخاص بالجهاز الافتراضي، مع الإبقاء على VNC لعرض ZVM المعتاد في المتصفح. أدى ذلك إلى إخراج الصوت عبر عميل SPICE منفصل مثل remote-viewer على مضيف Debian. وأكد صاحب المنشور الأصلي أن الصوت عمل بهذه الطريقة، لكنه كان متقطعًا. وحتى آخر رد في أغسطس 2026، لم يُظهر النقاش تشغيل الصوت مباشرة داخل وحدة تحكم ZVM في المتصفح.
اكتشف Ubuntu بطاقة الصوت الافتراضية مسبقًا
أظهرت لقطات الشاشة الأولية لوحة الصوت في Ubuntu مع جهاز إخراج داخلي، كما ظهر Firefox في خلاط مستوى الصوت. لذلك أصبح احتمال فقدان جهاز ALSA/PipeWire بالكامل أقل.
اقترح المجتمع تأكيد جانب الضيف باستخدام أوامر للقراءة فقط مثل:
aplay -l
pactl list short sinksإذا أظهرت هذه الأوامر جهاز صوت افتراضيًا، فتابع استكشاف طبقة المحاكاة الافتراضية ونقل الصوت بدلًا من إعادة تثبيت حزم صوت Ubuntu عشوائيًا.
لم تعرض واجهة ZVM المعتادة خيارًا لإخراج الصوت من المضيف
تحقق المستخدم من إعدادات ZVM المتاحة، وتمكن من ضبط المعالج والذاكرة والتخزين والشبكة والبرنامج الثابت، لكن لم يكن هناك محدد واضح لإخراج الصوت من وحدة تحكم المتصفح.
اكتشف المصدر أن الواجهة الخلفية لصوت QEMU مضبوطة على none
في 5 يونيو، لخّص صاحب المنشور التشخيص: كان لدى الجهاز الافتراضي بطاقة صوت افتراضية من نوع ICH9، لكن الواجهة الخلفية للصوت كانت type='none'. وبعبارة أخرى، كانت الأجهزة الافتراضية موجودة، لكن برنامج مراقبة الأجهزة الافتراضية لم يكن يمرر صوتها إلى أي مكان.
وأفاد المستخدم أيضًا بأن واجهات الصوت الخلفية المتاحة لـ ZVM/QEMU في إعداداته كانت none وspice وwav، دون إتاحة واجهة خلفية مباشرة لـ PulseAudio أو PipeWire عبر ZVM.
أعاد SPICE الصوت عبر remote-viewer
عدّل المستخدم XML الخاص بالجهاز الافتراضي لتفعيل صوت SPICE، وأضاف مسار رسومات وقناة SPICE مع الاحتفاظ بـ VNC للعرض المعتاد في ZVM. ثم اتصل من Debian باستخدام عميل SPICE مثل:
remote-viewer spice://ZIMAOS_IP:SPICE_PORTيفيد المصدر بأن الصوت عمل بعد ذلك. هذا تعديل متقدم على الجهاز الافتراضي من المجتمع، وليس إجراءً حاليًا عبر واجهة IceWhale الرسومية، لذا يُنصح بإنشاء نسخة احتياطية من تعريف الجهاز الافتراضي قبل تغيير XML.
ظل صوت VNC في المتصفح لا يعمل
كان استنتاج المصدر واضحًا: واصلت وحدة تحكم ZVM في Firefox أو المتصفح استخدام VNC للعرض، ولم توفر عميل SPICE للصوت المباشر. لذلك تطلب الحل الناجح باستخدام SPICE عميلًا خارجيًا بدلًا من علامة تبويب المتصفح المعتادة.
سأل تحديث في 15 أغسطس عما إذا كانت مشكلة صوت المتصفح قد أُصلحت، وخلص إلى أنها لم تُصلح على ما يبدو. لا تصف الصوت المباشر في المتصفح بأنه يعمل وفقًا لتأكيد المصدر.
كان صوت SPICE متقطعًا أيضًا
وصف المستخدم الصوت العامل بأنه متقطع جدًا، واشتبَه في برنامج ترميز صوت SPICE أو وسيلة النقل. وهذا يعني أن الحل البديل أثبت قدرة الجهاز الافتراضي على إنتاج الصوت، لكنه لم يوفر تجربة صوتية مكتبية مصقولة.
أعد الاختبار على ZimaOS الحالي قبل تعديل XML
يمتد المصدر من مايو إلى أغسطس 2026، ويسبق بعض تحديثات ZimaOS اللاحقة. اختبر أولًا ضيف ZVM حاليًا ومتصفحًا حاليًا. وإذا ظل الجهاز الافتراضي لا يوفر صوتًا عاملًا في المتصفح، فاعتبر الحل البديل باستخدام SPICE خيارًا متقدمًا احتياطيًا، لا الإعداد الافتراضي.
للتخطيط الحالي الأوسع للأجهزة الافتراضية، استخدم دليل التخطيط الحالي للأجهزة الافتراضية على ZimaOS.
الأسئلة الشائعة حول صوت Ubuntu في ZVM
هل رأى Ubuntu جهازًا صوتيًا بالفعل؟
نعم. أظهر المصدر جهازًا صوتيًا افتراضيًا داخليًا وتدفقات صوتية نشطة من Firefox والنظام.
ما الذي أعاد الصوت في المصدر؟
تفعيل صوت SPICE في تعريف الجهاز الافتراضي والاتصال باستخدام عميل SPICE خارجي مثل remote-viewer.
هل عمل الصوت مباشرة في وحدة تحكم ZVM داخل المتصفح؟
لم يؤكد أي رد في المصدر ذلك. وظل مسار المتصفح أو VNC صامتًا في النقاش.
