[libvirt] [PATCH] qemu: sound: Support intel 'hda' model

[Cole Robinson]

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