GNOME Bugzilla – Bug 761031
Newer audio device for modern windows
Last modified: 2018-01-11 10:31:15 UTC
There is no 64-bit driver for AC97 audio cards, and drivers are not available for Windows 8 nor 10. “qemu -device intel-hda“ seems to work for everyone on all OSes, as per experiences shared on around the web. (Aka. my Google searches were everyone’s problems seem to be fixed by “changing to Intel HDA” in quem and VirtualBox.) The audio device is non-configurable per the below commit. If you don’t want to change the default audio device, please make it configurable to support newer operating systems.. https://mail.gnome.org/archives/commits-list/2011-December/msg08329.html VirtualBox offers these choices: intel-hda, ac97, and soundblaster16. VirtualBox defaults to intel-hda for Windows systems and ac97 for Linux systems.
(In reply to Daniel Aleksandersen from comment #0) > There is no 64-bit driver for AC97 audio cards, and drivers are not > available for Windows 8 nor 10. > > “qemu -device intel-hda“ seems to work for everyone on all OSes, as per > experiences shared on around the web. (Aka. my Google searches were > everyone’s problems seem to be fixed by “changing to Intel HDA” in quem and > VirtualBox.) > > The audio device is non-configurable per the below commit. If you don’t want > to change the default audio device, please make it configurable to support > newer operating systems.. > https://mail.gnome.org/archives/commits-list/2011-December/msg08329.html Configuration option is typically a work-around and is very much so in this case. The correct fix would be to change the audio device for these OSes in libosinfo database.
I wrote up how to modify your Windows box installation to get working audio, for any users who’re waiting for a fix to this issue. https://www.slightfuture.com/how-to/win10-in-gnome-boxes
I just installed a Windows 10 box specifically to reproduce your issue. It sounds good ;).I could hear Cortana speaking in the bootstrapping dialog and after as well. Everything works fine out of the box. I see in the machine xml that it picked up the right sound model option: <sound model='ich6'> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </sound> Are you still experiencing the issue? I am testing it with: gnome-boxes-3.24.0 in Fedora 26 Windows 10 Home x64
I set up a Windows 7 VM on Debian Testing. It used 'ac97' and the audio was not working. I had to manually edit the xml file to change it to 'ich6'. As I said I used Debian Testing and it was gnome-boxes 3.22.4 I guess it is fixed in the new version. Just need to wait for Debian to update. (In reply to Felipe Borges from comment #3) > I just installed a Windows 10 box specifically to reproduce your issue. > > It sounds good ;).I could hear Cortana speaking in the bootstrapping dialog > and after as well. Everything works fine out of the box. > > I see in the machine xml that it picked up the right sound model option: > <sound model='ich6'> > <address type='pci' domain='0x0000' bus='0x00' slot='0x04' > function='0x0'/> > </sound> > > Are you still experiencing the issue? > > I am testing it with: > gnome-boxes-3.24.0 in Fedora 26 > Windows 10 Home x64
I tested this time with an Windows 7 box and I can reproduce your issue. I see in the osinfo-db/data/os/microsoft.com/win-7.xml.in that the correct device (ich6) is defined, but it is not getting picked up when installing the win-7 guest. Updating the sound entry in the xml with virsh edit fixed it for me as well. I reported this bug against libosinfo/osinfo-db: https://bugzilla.redhat.com/show_bug.cgi?id=1441719
Problem reproduced: Windows 10 Home(x86-64) Ver. 1709 Build 16299.125 Changed "ac97" ---> "ich6" in boxes-*.xml w/ 'virsh edit' command to fix. Ubuntu 17.04 chris@CKR-1:~$ gnome-boxes --version 3.24.0
(In reply to Chris Rainey from comment #6) > Problem reproduced: > > Windows 10 Home(x86-64) > Ver. 1709 > Build 16299.125 > > Changed "ac97" ---> "ich6" in boxes-*.xml w/ 'virsh edit' command to fix. > > > Ubuntu 17.04 > > chris@CKR-1:~$ gnome-boxes --version > 3.24.0 The osinfo data seems to be correctly pointing to the ich6 driver but we fallback to ac97 whenever the Operating System is not identified. The reasoning is discussed in Bug 672872. I'd have to conduct some research to conclude whether the assumptions posted in this bug are still valid. Therefore, would you mind sharing the output of $ osinfo-detect your_windows_image_file.iso ?
(In reply to Felipe Borges from comment #7) > (In reply to Chris Rainey from comment #6) > > Problem reproduced: > > > > Windows 10 Home(x86-64) > > Ver. 1709 > > Build 16299.125 > > > > Changed "ac97" ---> "ich6" in boxes-*.xml w/ 'virsh edit' command to fix. > > > > > > Ubuntu 17.04 > > > > chris@CKR-1:~$ gnome-boxes --version > > 3.24.0 > > The osinfo data seems to be correctly pointing to the ich6 driver but we > fallback to ac97 whenever the Operating System is not identified. > > The reasoning is discussed in Bug 672872. I'd have to conduct some research > to conclude whether the assumptions posted in this bug are still valid. > > Therefore, would you mind sharing the output of $ osinfo-detect > your_windows_image_file.iso ? chris@CKR-1:~$ osinfo-detect Archives/ISOS/Win10_1709_English_x64.iso Media is bootable. chris@CKR-1:~$ Thanks for looking into this!
(In reply to Chris Rainey from comment #8) > (In reply to Felipe Borges from comment #7) > > Therefore, would you mind sharing the output of $ osinfo-detect > > your_windows_image_file.iso ? > > > chris@CKR-1:~$ osinfo-detect Archives/ISOS/Win10_1709_English_x64.iso > Media is bootable. That's it. Your image file is not detected by libosinfo, causing Boxes to fallback to the AC97 driver which we assign to unknown (undetected) operating systems. See https://git.gnome.org/browse/gnome-boxes/tree/src/vm-configurator.vala#n357 After discussing with @teuf on IRC, it seems that the right approach is to switch the fallback to ich6 and patch older Windows versions in libosinfo to explicitly pick the AC97 driver. I will patch Boxes as soon as we get the libosinfo patches. Expect this to be resolved/fixed for our next stable release: 3.28.
(In reply to Chris Rainey from comment #8) > > chris@CKR-1:~$ osinfo-detect Archives/ISOS/Win10_1709_English_x64.iso > Media is bootable. Could you provide the output of $ isoinfo -d -i Archives/ISOS/Win10_1709_English_x64.iso ? isoinfo is part of the genisoimage/cdrkit package.
(In reply to Christophe Fergeau from comment #10) > (In reply to Chris Rainey from comment #8) > > > > chris@CKR-1:~$ osinfo-detect Archives/ISOS/Win10_1709_English_x64.iso > > Media is bootable. > > Could you provide the output of > $ isoinfo -d -i Archives/ISOS/Win10_1709_English_x64.iso > ? > > isoinfo is part of the genisoimage/cdrkit package. You, Sir --- are a God among Devs! chris@CKR-1:~$ isoinfo -d -i Archives/ISOS/Win10_1709_English_x64.iso CD-ROM is in ISO 9660 format System id: Volume id: CCCOMA_X64FRE_EN-US_DV9 Volume set id: CCCOMA_X64FRE_EN-US_DV9 Publisher id: MICROSOFT CORPORATION Data preparer id: MICROSOFT CORPORATION, ONE MICROSOFT WAY, REDMOND WA 98052, (425) 882-8080 Application id: CDIMAGE 2.56 (01/01/2005 TM) Copyright File id: Abstract File id: Bibliographic File id: Volume set size is: 1 Volume set sequence number is: 1 Logical block size is: 2048 Volume size is: 2293634 El Torito VD version 1 found, boot catalog is in sector 22 NO Joliet present NO Rock Ridge present Eltorito validation header: Hid 1 Arch 0 (x86) ID 'Microsoft Corporation' Key 55 AA Eltorito defaultboot header: Bootid 88 (bootable) Boot media 0 (No Emulation Boot) Load segment 0 Sys type 0 Nsect 8 Bootoff 20C 524 chris@CKR-1:~$
(In reply to Chris Rainey from comment #11) > (In reply to Christophe Fergeau from comment #10) > > (In reply to Chris Rainey from comment #8) > > > > > > chris@CKR-1:~$ osinfo-detect Archives/ISOS/Win10_1709_English_x64.iso > > > Media is bootable. > > > > Could you provide the output of > > $ isoinfo -d -i Archives/ISOS/Win10_1709_English_x64.iso > > ? > > > > isoinfo is part of the genisoimage/cdrkit package. > > > You, Sir --- are a God among Devs! > > > chris@CKR-1:~$ isoinfo -d -i Archives/ISOS/Win10_1709_English_x64.iso Thanks! osinfodb from git seems to already correctly identify this image :)
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-boxes/issues/78.