This is a request for enhancement.
Description of problem:
qemu 0.14 added support for virtualized Intel HDA Audio; but libvirt does not support using it in its XML configuration files.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. $ qemu-kvm -soundhw ?
2. Create a virtual machine in virt-manager.
3. Edit virtual machine configuration in virt-manager and add a "Sound" device.
All supported sound devices except 'hda' can be configured.
All supported sound devices including 'hda' should be configurable.
$ qemu-kvm -soundhw ?
Valid sound card names (comma separated):
pcspk PC speaker
sb16 Creative Sound Blaster 16
ac97 Intel 82801AA AC97 Audio
es1370 ENSONIQ AudioPCI ES1370
hda Intel HD Audio
-soundhw all will enable all of the above
Intel HDA Audio cannot be configured in libvirt's XML files. Using virt-manager above to "reproduce" was solely for convenience.
At the moment Intel HDA Audio is the only available virtualized sound hardware for which 64-bit Windows guests have reasonably functional drivers available.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This is supported, but within libvirt the model is called "ich6" not "hda".
(It is named after the chipset name, not the marketing name.)
In particular, here is the upstream commit that added support for 'ich6' sound:
Author: Cole Robinson <firstname.lastname@example.org>
Date: Thu Jan 13 09:15:11 2011 -0500
qemu: sound: Support intel 'ich6' model
In QEMU, the card itself is a PCI device, but it requires a codec
(either -device hda-output or -device hda-duplex) to actually output
sound. Specifying <sound model='ich6'/> gives us -device intel-hda
-device hda-duplex I think it's important that a simple <sound model='ich6'/>
sets up a useful codec, to have consistent behavior with all other sound cards.
This is basically Dan's proposal of
<codec type='output' slot='0'/>
<codec type='duplex' slot='3'/>
without the codec bits implemented.
The important thing is to keep a consistent API here, we don't want some
<sound> devs require tweaking codecs but not others. Steps I see to
- every <sound> device has a <codec type='default'/> (unless codecs are
- <codec type='none'/> is required to specify 'no codecs'
- new audio settings like mic=on|off could then be exposed in
<sound> or <codec> in a consistent manner for all sound models
Use feature detection, from eblake
Set codec id, bus, and cad values
intel-hda isn't supported if -device isn't available
Comment spelling fixes