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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list