[libvirt] [PATCH] qemu: sound: Support intel 'hda' model
In QEMU, the card itself is a PCI device, but it requires -device hda-output in order to actually get sound to the host. AIUI this is just HDA configuration and does not require stable addressing, so is not presently represented in the XML. Additionally, qemu supports audio input with '-device hda-duplex', however that provides guests access to the host's microphone, so probably isn't what we want by default. --- docs/formatdomain.html.in | 5 +++-- docs/schemas/domain.rng | 1 + src/conf/domain_conf.c | 3 ++- src/conf/domain_conf.h | 1 + src/qemu/qemu_command.c | 14 +++++++++++++- .../qemuxml2argv-sound-device.args | 2 +- .../qemuxml2argvdata/qemuxml2argv-sound-device.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-sound.args | 2 +- tests/qemuxml2argvdata/qemuxml2argv-sound.xml | 1 + 9 files changed, 24 insertions(+), 6 deletions(-) diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index e9fcea1..8c43b74 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -1663,8 +1663,9 @@ qemu-kvm -net nic,model=? /dev/null The <code>sound</code> element has one mandatory attribute, <code>model</code>, which specifies what real sound device is emulated. Valid values are specific to the underlying hypervisor, though typical - choices are 'es1370', 'sb16', and 'ac97' - (<span class="since">'ac97' only since 0.6.0</span>) + choices are 'es1370', 'sb16', 'ac97', and 'hda' + (<span class="since"> + 'ac97' only since 0.6.0, 'hda' only since 0.8.8</span>) </dd> </dl> diff --git a/docs/schemas/domain.rng b/docs/schemas/domain.rng index a524e4b..491a5a5 100644 --- a/docs/schemas/domain.rng +++ b/docs/schemas/domain.rng @@ -1489,6 +1489,7 @@ <value>es1370</value> <value>pcspk</value> <value>ac97</value> + <value>hda</value> </choice> </attribute> <optional> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index c857a89..992435d 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -225,7 +225,8 @@ VIR_ENUM_IMPL(virDomainSoundModel, VIR_DOMAIN_SOUND_MODEL_LAST, "sb16", "es1370", "pcspk", - "ac97") + "ac97", + "hda") VIR_ENUM_IMPL(virDomainMemballoonModel, VIR_DOMAIN_MEMBALLOON_MODEL_LAST, "virtio", diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h index a459a22..d5ff9f3 100644 --- a/src/conf/domain_conf.h +++ b/src/conf/domain_conf.h @@ -458,6 +458,7 @@ enum virDomainSoundModel { VIR_DOMAIN_SOUND_MODEL_ES1370, VIR_DOMAIN_SOUND_MODEL_PCSPK, VIR_DOMAIN_SOUND_MODEL_AC97, + VIR_DOMAIN_SOUND_MODEL_HDA, VIR_DOMAIN_SOUND_MODEL_LAST }; diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 7dd8e03..2030455 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -1726,11 +1726,13 @@ qemuBuildSoundDevStr(virDomainSoundDefPtr sound) goto error; } - /* Hack for 2 wierdly unusal devices name in QEMU */ + /* Hack for wierdly unusal devices name in QEMU */ if (STREQ(model, "es1370")) model = "ES1370"; else if (STREQ(model, "ac97")) model = "AC97"; + else if (STREQ(model, "hda")) + model = "intel-hda"; virBufferVSprintf(&buf, "%s", model); virBufferVSprintf(&buf, ",id=%s", sound->info.alias); @@ -3750,6 +3752,14 @@ qemuBuildCommandLine(virConnectPtr conn, goto error; virCommandAddArg(cmd, str); + + if (sound->model == VIR_DOMAIN_SOUND_MODEL_HDA) { + /* This is just an HDA codec, so doesn't require + * stable addressing AIUI */ + virCommandAddArgList(cmd, + "-device", "hda-output", NULL); + } + VIR_FREE(str); } } @@ -5529,6 +5539,8 @@ virDomainDefPtr qemuParseCommandLine(virCapsPtr caps, type = VIR_DOMAIN_SOUND_MODEL_ES1370; } else if (STRPREFIX(start, "ac97")) { type = VIR_DOMAIN_SOUND_MODEL_AC97; + } else if (STRPREFIX(start, "hda")) { + type = VIR_DOMAIN_SOUND_MODEL_HDA; } if (type != -1) { diff --git a/tests/qemuxml2argvdata/qemuxml2argv-sound-device.args b/tests/qemuxml2argvdata/qemuxml2argv-sound-device.args index 6b2e697..6cd4b4a 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-sound-device.args +++ b/tests/qemuxml2argvdata/qemuxml2argv-sound-device.args @@ -1 +1 @@ -LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu -S -M pc -m 214 -smp 1 -nographic -nodefconfig -nodefaults -monitor unix:/tmp/test-monitor,server,nowait -no-acpi -boot c -hda /dev/HostVG/QEMUGuest1 -usb -soundhw pcspk -device ES1370,id=sound1,bus=pci.0,addr=0x2 -device sb16,id=sound2 -device AC97,id=sound3,bus=pci.0,addr=0x3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 +LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu -S -M pc -m 214 -smp 1 -nographic -nodefconfig -nodefaults -monitor unix:/tmp/test-monitor,server,nowait -no-acpi -boot c -hda /dev/HostVG/QEMUGuest1 -usb -soundhw pcspk -device ES1370,id=sound1,bus=pci.0,addr=0x2 -device sb16,id=sound2 -device AC97,id=sound3,bus=pci.0,addr=0x3 -device intel-hda,id=sound4,bus=pci.0,addr=0x4 -device hda-output -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 diff --git a/tests/qemuxml2argvdata/qemuxml2argv-sound-device.xml b/tests/qemuxml2argvdata/qemuxml2argv-sound-device.xml index c725346..f48c61e 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-sound-device.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-sound-device.xml @@ -22,6 +22,7 @@ <sound model='es1370'/> <sound model='sb16'/> <sound model='ac97'/> + <sound model='hda'/> <memballoon model='virtio'/> </devices> </domain> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-sound.args b/tests/qemuxml2argvdata/qemuxml2argv-sound.args index 8cb2da2..0db62c3 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-sound.args +++ b/tests/qemuxml2argvdata/qemuxml2argv-sound.args @@ -1 +1 @@ -LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu -S -M pc -m 214 -smp 1 -nographic -monitor unix:/tmp/test-monitor,server,nowait -no-acpi -boot c -hda /dev/HostVG/QEMUGuest1 -net none -serial none -parallel none -usb -soundhw pcspk,es1370,sb16,ac97 +LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu -S -M pc -m 214 -smp 1 -nographic -monitor unix:/tmp/test-monitor,server,nowait -no-acpi -boot c -hda /dev/HostVG/QEMUGuest1 -net none -serial none -parallel none -usb -soundhw pcspk,es1370,sb16,ac97,hda diff --git a/tests/qemuxml2argvdata/qemuxml2argv-sound.xml b/tests/qemuxml2argvdata/qemuxml2argv-sound.xml index d34e0b3..c713d05 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-sound.xml +++ b/tests/qemuxml2argvdata/qemuxml2argv-sound.xml @@ -24,6 +24,7 @@ <sound model='es1370'/> <sound model='sb16'/> <sound model='ac97'/> + <sound model='hda'/> <memballoon model='virtio'/> </devices> </domain> -- 1.7.3.3
On 01/10/2011 10:19 AM, Cole Robinson wrote:
In QEMU, the card itself is a PCI device, but it requires -device hda-output in order to actually get sound to the host. AIUI this is just HDA configuration and does not require stable addressing, so is not presently represented in the XML.
Additionally, qemu supports audio input with '-device hda-duplex', however that provides guests access to the host's microphone, so probably isn't what we want by default.
Is there room for future XML expansion if we do decide to expose the choice between -device hda-output vs. -device hda-duplex via the XML? The patch looks fine as-is, but I'm a bit hesitant to ack until we've thought about a potential upgrade path for the future, in case it implies rearranging any of this patch. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
On 01/10/2011 12:44 PM, Eric Blake wrote:
On 01/10/2011 10:19 AM, Cole Robinson wrote:
In QEMU, the card itself is a PCI device, but it requires -device hda-output in order to actually get sound to the host. AIUI this is just HDA configuration and does not require stable addressing, so is not presently represented in the XML.
Additionally, qemu supports audio input with '-device hda-duplex', however that provides guests access to the host's microphone, so probably isn't what we want by default.
Is there room for future XML expansion if we do decide to expose the choice between -device hda-output vs. -device hda-duplex via the XML? The patch looks fine as-is, but I'm a bit hesitant to ack until we've thought about a potential upgrade path for the future, in case it implies rearranging any of this patch.
I imagined some generic <sound> property like microphone="on|off" or input="on|off", or a <sound> child element. From an XML perspective I don't think it should conflict with this patch. However I realize now that this patch is introducing inconsistent semantics WRT audio input, since it seems like es1370 and ac97 support a microphone (though I haven't tested it). So maybe this should use hda-duplex. Anyone have an opinion? - Cole
On Mon, Jan 10, 2011 at 12:58:09PM -0500, Cole Robinson wrote:
On 01/10/2011 12:44 PM, Eric Blake wrote:
On 01/10/2011 10:19 AM, Cole Robinson wrote:
In QEMU, the card itself is a PCI device, but it requires -device hda-output in order to actually get sound to the host. AIUI this is just HDA configuration and does not require stable addressing, so is not presently represented in the XML.
Additionally, qemu supports audio input with '-device hda-duplex', however that provides guests access to the host's microphone, so probably isn't what we want by default.
Is there room for future XML expansion if we do decide to expose the choice between -device hda-output vs. -device hda-duplex via the XML? The patch looks fine as-is, but I'm a bit hesitant to ack until we've thought about a potential upgrade path for the future, in case it implies rearranging any of this patch.
I imagined some generic <sound> property like microphone="on|off" or input="on|off", or a <sound> child element. From an XML perspective I don't think it should conflict with this patch.
However I realize now that this patch is introducing inconsistent semantics WRT audio input, since it seems like es1370 and ac97 support a microphone (though I haven't tested it). So maybe this should use hda-duplex. Anyone have an opinion?
If we add extra 'mic=on|off' in the XML later, we need to be able to pick the default for them. It is easier to pick the default if we can pick the same default for all device types. So if all existing devices are full duplex we should use that for HDA too, otherwise apps would see a change in semantics when updating to newer libvirt. Regards, Daniel
On Mon, Jan 10, 2011 at 10:44:29AM -0700, Eric Blake wrote:
On 01/10/2011 10:19 AM, Cole Robinson wrote:
In QEMU, the card itself is a PCI device, but it requires -device hda-output in order to actually get sound to the host. AIUI this is just HDA configuration and does not require stable addressing, so is not presently represented in the XML.
Additionally, qemu supports audio input with '-device hda-duplex', however that provides guests access to the host's microphone, so probably isn't what we want by default.
Is there room for future XML expansion if we do decide to expose the choice between -device hda-output vs. -device hda-duplex via the XML? The patch looks fine as-is, but I'm a bit hesitant to ack until we've thought about a potential upgrade path for the future, in case it implies rearranging any of this patch.
That isn't related to the device model name, so I think it is fine. hda-output vs hda-duplex is basically determining whether QEMU can merely write to the sound card (to play audio), or can also read from the card (to record via the mic). This is something we'd want to represent either as additional attributes, or child elements. Regards, Daniel
On Mon, Jan 10, 2011 at 12:19:07PM -0500, Cole Robinson wrote:
In QEMU, the card itself is a PCI device, but it requires -device hda-output in order to actually get sound to the host. AIUI this is just HDA configuration and does not require stable addressing, so is not presently represented in the XML.
Additionally, qemu supports audio input with '-device hda-duplex', however that provides guests access to the host's microphone, so probably isn't what we want by default. --- docs/formatdomain.html.in | 5 +++-- docs/schemas/domain.rng | 1 + src/conf/domain_conf.c | 3 ++- src/conf/domain_conf.h | 1 + src/qemu/qemu_command.c | 14 +++++++++++++- .../qemuxml2argv-sound-device.args | 2 +- .../qemuxml2argvdata/qemuxml2argv-sound-device.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-sound.args | 2 +- tests/qemuxml2argvdata/qemuxml2argv-sound.xml | 1 + 9 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index e9fcea1..8c43b74 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -1663,8 +1663,9 @@ qemu-kvm -net nic,model=? /dev/null The <code>sound</code> element has one mandatory attribute, <code>model</code>, which specifies what real sound device is emulated. Valid values are specific to the underlying hypervisor, though typical - choices are 'es1370', 'sb16', and 'ac97' - (<span class="since">'ac97' only since 0.6.0</span>) + choices are 'es1370', 'sb16', 'ac97', and 'hda' + (<span class="since"> + 'ac97' only since 0.6.0, 'hda' only since 0.8.8</span>) </dd> </dl>
diff --git a/docs/schemas/domain.rng b/docs/schemas/domain.rng index a524e4b..491a5a5 100644 --- a/docs/schemas/domain.rng +++ b/docs/schemas/domain.rng @@ -1489,6 +1489,7 @@ <value>es1370</value> <value>pcspk</value> <value>ac97</value> + <value>hda</value> </choice> </attribute> <optional> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index c857a89..992435d 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -225,7 +225,8 @@ VIR_ENUM_IMPL(virDomainSoundModel, VIR_DOMAIN_SOUND_MODEL_LAST, "sb16", "es1370", "pcspk", - "ac97") + "ac97", + "hda")
IIUC, HDA is a generic family of devices, of which QEMU is only emulating one particular device model - ICH6. If it adds others (ICH7/8/9/etc) in the future we need to distinguish them, so I think we should probably call it 'ich6' in the XML, rather than 'hda'. Regards, Daniel
On 01/10/11 18:19, Cole Robinson wrote:
In QEMU, the card itself is a PCI device, but it requires -device hda-output in order to actually get sound to the host. AIUI this is just HDA configuration and does not require stable addressing, so is not presently represented in the XML.
It isn't that simple. There are actually multiple devices involved. Each audio codec (yes, there can be multiple of these, up to 15) is connected via HDA Link to the pci controller. Each audio codec has a codec address (HDA bus property: cad=[0..14]). So you can specify "-device intel-hda -device hda-duplex -device hda-output" and the guest has multiple audio devices. Win7 even handles this correctly, whereas alsa uses only the first codec it finds (lowest codec address). Not that this buys you much today, qemu mixes all channels together before sending them off to the hosts sound system, i.e. you don't see a stream per sound card in pulseaudio. That might change in the future though. We also might see more hda codecs in the future. Maybe to pass through digital audio interfaces from the host? Not investigated yet in detail though. The HDA Links are even hot-pluggable (new audio codec can be linked up when putting the laptop into the docking station for example), although the qemu emulation doesn't support that today. cheers, Gerd
On Tue, Jan 11, 2011 at 11:46:14AM +0100, Gerd Hoffmann wrote:
On 01/10/11 18:19, Cole Robinson wrote:
In QEMU, the card itself is a PCI device, but it requires -device hda-output in order to actually get sound to the host. AIUI this is just HDA configuration and does not require stable addressing, so is not presently represented in the XML.
It isn't that simple. There are actually multiple devices involved. Each audio codec (yes, there can be multiple of these, up to 15) is connected via HDA Link to the pci controller. Each audio codec has a codec address (HDA bus property: cad=[0..14]).
So you can specify "-device intel-hda -device hda-duplex -device hda-output" and the guest has multiple audio devices. Win7 even handles this correctly, whereas alsa uses only the first codec it finds (lowest codec address). Not that this buys you much today, qemu mixes all channels together before sending them off to the hosts sound system, i.e. you don't see a stream per sound card in pulseaudio. That might change in the future though.
So 'intel-hda' should really be considered as a controller, and hda-output' & 'hda-duplex' are the things to be treated as devices in the guest config. This suggests a setup more like the one we did for virtio-serial where we'd invent a new address type for codecs, and have XML looking something like <controller type='hda' model='ich6'> <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/> </controller> <sound model='hda-output'> <address type='hda' codec='0'/> </sound> <sound model='hda-duplex'> <address type='hda' codec='1'/> </sound> Are there any technical model names for 'hda-output' 'hda-duplex' we need to be aware of (as we potentially have ich6, ich7, 8, 9, etc for intel-hda in the future)
We also might see more hda codecs in the future. Maybe to pass through digital audio interfaces from the host? Not investigated yet in detail though.
The HDA Links are even hot-pluggable (new audio codec can be linked up when putting the laptop into the docking station for example), although the qemu emulation doesn't support that today.
Hotplug is another good reason for us to treat the 'hda-output' and 'hda-duplex' objects as the <sound> device in libvirt XML, because then we can add/remove them via virDomainAttachDevice which we couldn't otherwise do Regards, Daniel
On 01/11/11 12:10, Daniel P. Berrange wrote:
This suggests a setup more like the one we did for virtio-serial where we'd invent a new address type for codecs, and have XML looking something like
<controller type='hda' model='ich6'> <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/> </controller> <sound model='hda-output'> <address type='hda' codec='0'/> </sound> <sound model='hda-duplex'> <address type='hda' codec='1'/> </sound>
Looks sane to me.
Are there any technical model names for 'hda-output' 'hda-duplex' we need to be aware of (as we potentially have ich6, ich7, 8, 9, etc for intel-hda in the future)
hda-output and hda-duplex are purely virtual devices, they don't exist as physical chip, so there are no code names or chipset families. When other variants of the hda controller will be added the audio codecs are not affected at all. Given that q35 (ich9 family) chipset emulation support is in development it is quite likely that we'll see a ich9 variant some day (which is basically just another pci id). cheers, Gerd
On 01/11/2011 06:10 AM, Daniel P. Berrange wrote:
On Tue, Jan 11, 2011 at 11:46:14AM +0100, Gerd Hoffmann wrote:
On 01/10/11 18:19, Cole Robinson wrote:
In QEMU, the card itself is a PCI device, but it requires -device hda-output in order to actually get sound to the host. AIUI this is just HDA configuration and does not require stable addressing, so is not presently represented in the XML.
It isn't that simple. There are actually multiple devices involved. Each audio codec (yes, there can be multiple of these, up to 15) is connected via HDA Link to the pci controller. Each audio codec has a codec address (HDA bus property: cad=[0..14]).
So you can specify "-device intel-hda -device hda-duplex -device hda-output" and the guest has multiple audio devices. Win7 even handles this correctly, whereas alsa uses only the first codec it finds (lowest codec address). Not that this buys you much today, qemu mixes all channels together before sending them off to the hosts sound system, i.e. you don't see a stream per sound card in pulseaudio. That might change in the future though.
So 'intel-hda' should really be considered as a controller, and hda-output' & 'hda-duplex' are the things to be treated as devices in the guest config.
This suggests a setup more like the one we did for virtio-serial where we'd invent a new address type for codecs, and have XML looking something like
<controller type='hda' model='ich6'> <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/> </controller> <sound model='hda-output'> <address type='hda' codec='0'/> </sound> <sound model='hda-duplex'> <address type='hda' codec='1'/> </sound>
Sounds good, though I think doing <sound model='hda' mic="on|off"/> would be preferable from a UI perspective, since it sounds like that's the only differentiating factor (or maybe use 'duplex' or 'input' etc.). Does that sound okay? - Cole
On Tue, Jan 11, 2011 at 09:58:42AM -0500, Cole Robinson wrote:
On 01/11/2011 06:10 AM, Daniel P. Berrange wrote:
On Tue, Jan 11, 2011 at 11:46:14AM +0100, Gerd Hoffmann wrote:
On 01/10/11 18:19, Cole Robinson wrote:
In QEMU, the card itself is a PCI device, but it requires -device hda-output in order to actually get sound to the host. AIUI this is just HDA configuration and does not require stable addressing, so is not presently represented in the XML.
It isn't that simple. There are actually multiple devices involved. Each audio codec (yes, there can be multiple of these, up to 15) is connected via HDA Link to the pci controller. Each audio codec has a codec address (HDA bus property: cad=[0..14]).
So you can specify "-device intel-hda -device hda-duplex -device hda-output" and the guest has multiple audio devices. Win7 even handles this correctly, whereas alsa uses only the first codec it finds (lowest codec address). Not that this buys you much today, qemu mixes all channels together before sending them off to the hosts sound system, i.e. you don't see a stream per sound card in pulseaudio. That might change in the future though.
So 'intel-hda' should really be considered as a controller, and hda-output' & 'hda-duplex' are the things to be treated as devices in the guest config.
This suggests a setup more like the one we did for virtio-serial where we'd invent a new address type for codecs, and have XML looking something like
<controller type='hda' model='ich6'> <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/> </controller> <sound model='hda-output'> <address type='hda' codec='0'/> </sound> <sound model='hda-duplex'> <address type='hda' codec='1'/> </sound>
Sounds good, though I think doing
<sound model='hda' mic="on|off"/>
would be preferable from a UI perspective, since it sounds like that's the only differentiating factor (or maybe use 'duplex' or 'input' etc.). Does that sound okay?
The problem with mic=on|off is that it only works for the current case of choosing hda-output vs hda-duplex. It can't cope with the scenario where QEMU adds more codecs, which are unrelated to the microphone state, Gerd mentioned might well happen Regards, Daniel
On 01/11/2011 10:04 AM, Daniel P. Berrange wrote:
On Tue, Jan 11, 2011 at 09:58:42AM -0500, Cole Robinson wrote:
On 01/11/2011 06:10 AM, Daniel P. Berrange wrote:
On Tue, Jan 11, 2011 at 11:46:14AM +0100, Gerd Hoffmann wrote:
On 01/10/11 18:19, Cole Robinson wrote:
In QEMU, the card itself is a PCI device, but it requires -device hda-output in order to actually get sound to the host. AIUI this is just HDA configuration and does not require stable addressing, so is not presently represented in the XML.
It isn't that simple. There are actually multiple devices involved. Each audio codec (yes, there can be multiple of these, up to 15) is connected via HDA Link to the pci controller. Each audio codec has a codec address (HDA bus property: cad=[0..14]).
So you can specify "-device intel-hda -device hda-duplex -device hda-output" and the guest has multiple audio devices. Win7 even handles this correctly, whereas alsa uses only the first codec it finds (lowest codec address). Not that this buys you much today, qemu mixes all channels together before sending them off to the hosts sound system, i.e. you don't see a stream per sound card in pulseaudio. That might change in the future though.
So 'intel-hda' should really be considered as a controller, and hda-output' & 'hda-duplex' are the things to be treated as devices in the guest config.
This suggests a setup more like the one we did for virtio-serial where we'd invent a new address type for codecs, and have XML looking something like
<controller type='hda' model='ich6'> <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/> </controller> <sound model='hda-output'> <address type='hda' codec='0'/> </sound> <sound model='hda-duplex'> <address type='hda' codec='1'/> </sound>
Sounds good, though I think doing
<sound model='hda' mic="on|off"/>
would be preferable from a UI perspective, since it sounds like that's the only differentiating factor (or maybe use 'duplex' or 'input' etc.). Does that sound okay?
The problem with mic=on|off is that it only works for the current case of choosing hda-output vs hda-duplex. It can't cope with the scenario where QEMU adds more codecs, which are unrelated to the microphone state, Gerd mentioned might well happen
It isn't meant to handle the case for all HDA codecs, just output vs. duplex. If a 'passthrough' codec is available tomorrow, the best way to handle it might be a new 'hda-passthrough' model. But what if someone implements 5.1 support? Are we going to have hda-output, hda-duplex, hda5.1-output, hda5.1-duplex? Rather than <sound model='hda' duplex='on|off" channels="5.1"/> or similar? - Cole
On Tue, Jan 11, 2011 at 11:10:04AM +0000, Daniel P. Berrange wrote:
On Tue, Jan 11, 2011 at 11:46:14AM +0100, Gerd Hoffmann wrote:
On 01/10/11 18:19, Cole Robinson wrote:
In QEMU, the card itself is a PCI device, but it requires -device hda-output in order to actually get sound to the host. AIUI this is just HDA configuration and does not require stable addressing, so is not presently represented in the XML.
It isn't that simple. There are actually multiple devices involved. Each audio codec (yes, there can be multiple of these, up to 15) is connected via HDA Link to the pci controller. Each audio codec has a codec address (HDA bus property: cad=[0..14]).
So you can specify "-device intel-hda -device hda-duplex -device hda-output" and the guest has multiple audio devices. Win7 even handles this correctly, whereas alsa uses only the first codec it finds (lowest codec address). Not that this buys you much today, qemu mixes all channels together before sending them off to the hosts sound system, i.e. you don't see a stream per sound card in pulseaudio. That might change in the future though.
So 'intel-hda' should really be considered as a controller, and hda-output' & 'hda-duplex' are the things to be treated as devices in the guest config.
This suggests a setup more like the one we did for virtio-serial where we'd invent a new address type for codecs, and have XML looking something like
<controller type='hda' model='ich6'> <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/> </controller> <sound model='hda-output'> <address type='hda' codec='0'/> </sound> <sound model='hda-duplex'> <address type='hda' codec='1'/> </sound>
Are there any technical model names for 'hda-output' 'hda-duplex' we need to be aware of (as we potentially have ich6, ich7, 8, 9, etc for intel-hda in the future)
We also might see more hda codecs in the future. Maybe to pass through digital audio interfaces from the host? Not investigated yet in detail though.
The HDA Links are even hot-pluggable (new audio codec can be linked up when putting the laptop into the docking station for example), although the qemu emulation doesn't support that today.
Hotplug is another good reason for us to treat the 'hda-output' and 'hda-duplex' objects as the <sound> device in libvirt XML, because then we can add/remove them via virDomainAttachDevice which we couldn't otherwise do
One further alternative is to explicitly list codecs under the <sound> element eg <sound model='ich6'> <codec name='output' slot=0/> <codec name='duplex' slot=3/> <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/> </sound> We could use virDomainAttachDevice/DetachDevice to hotplug an entire ich6 device, and virDomainUpdateDevice to hotplug individual codecs within the device. This might be a slightly nicer option for applications, so it would more closely mesh with what the guest OS actually sees as its device(s). Daniel
participants (4)
-
Cole Robinson -
Daniel P. Berrange -
Eric Blake -
Gerd Hoffmann