[pve-devel] [PATCH qemu-server] audio dev: specify qemu audio backend

[Aaron Lauterer]

On 7/22/19 7:26 PM, Thomas Lamprecht wrote:
> On 7/22/19 12:33 PM, Aaron Lauterer wrote:> On 7/22/19 10:00 AM, Thomas Lamprecht wrote:
>>> On 7/19/19 3:15 PM, Aaron Lauterer wrote:
>>>> QEMU 4 adds the `-audiodev` parameter to explicitly specify the audio
>>>> backend. Setting it avoids occasional error messages when starting a
>>>> virtual machine with an audio device and qemu wants to connect it to the
>>>> physical audio device.
>>>
>>> Occasional? The error is always there if no audio card/alsa is there.
>>> The real issue is that this would have allowed access to host HW with
>>> only having the VM.Config.Option permission on any VM..
>>> (no big issue, I just like to have the commit messages tell the real reasons)
>>>
>>
>> Managed to find a reproducible setup to cause the errors. Will rewrite the commit msg.
>>
>>>>
>>>> For now only SPICE is supported as it's also the biggest use case.
>>>
>>>
>>> FYI, testing this in a VM I get the following errors/warnings:
>>>
>>>> audio: Could not init `spice' audio driver
>>>> audio: warning: Using timer based audio emulation
>>>
>>> but host seems to work...
>>>
>>
>> These errors are thrown if the "-audiodev spice" parameter is set but no spice (qxl) display is selected. If no spice display is selected the "-spice" parameter is not set.
>>
>> The manpage for qemu states the following regarding "-audiodev spice":
>>
>>> Creates a backend that sends audio through SPICE.  This backend requires "-spice" and automatically selected in that case, so usually you can ignore this option.  This backend has no backend specific properties.
>>
>> If spice(qxl) is selected as display there are no errors even if the "-audiodev spice" is not set.
> Ah okay, makes even (somewhat) sense, thanks for clearing this up!
> 
>>
>> To limit access to the host hardware I would still set the "-audiodev spice" for the cases that a user defines an audio device but does not set the display to spice(qxl).
>>
>> What do you think? @Thomas
> 
> Yes, sure that always should be done, else it would use the alsa host stuff.
> Real questions is if we should allow setting the audio0 then when qxl is
> not the display - I mean in the backend yes, for sure (maybe warn on startup
> then) but in the WebUI it could really make sense to merge the audio dev
> addition into the SPICE/QXL display edit?
> 
>> I could not find any doc regarding the need for a matching id or a different behavior. If someone can shed more light onto this I would appreciate it.
> 
>  From the offending commit[0] adding this pesky audiodev I still interpret
> that this is really to configure specific audio drivers (the intel-hda, et
> al. stuff in QEMU speak), and normally to combine those and ID is needed,
> that's the case with most devices + their configuration in QEMU. So I
> /guess/ that the id has it's purpose and that this is it..

After some research and digging it seems that the added -audiodev 
cleaned up the old way of configuring audio backends in qemu (used env 
variables). Devices like intel-hda are the audio frontends as far as I 
understand it.

> 
> I guess that it here only still works because in the with QXL as display it
> defaults here to it?
> 
> Anyway, I'm not too happy with this all if we do not have an idea how it
> works and what really is affected by this. Do you think you can ask around
> in the IRC or user mailing list, CCing the patch author could be an option,
> albeit a bit intrusive one..
> I'd be much happier if we had a bit clarity here, not just guess-work,
> that's no accusation, the docs really do not makes ones life easy here, and
> while the code helps - I currently just do not have the time to make me
> familiar with it and see what really happens and if that's OK..
> 
> [0]: https://git.qemu.org/gitweb.cgi?p=qemu.git;a=commitdiff;h=71830221fb23388b32e6516c2fb7a698453a6c5a
> 

The current implementation of the audio backend allows only one backend 
and will throw errors if more than one audiodev is added.
The id parameter also seems to not be used in any of the backend 
implementations (thanks fabian for helping me with that).

There is a patch series in the qemu-devel list to implement multiple 
audio backends [1].
The way the usage will be is that the id of the audio backend (audiodev) 
has to be specified when creating the audio device/frontend:

 > Example usage: -audiodev pa,id=foo -device AC97,audiodev=foo

So I guess we should come up with a decent naming of the id. Once qemu 
supports multiple audio devices and we want to do so too we need some 
kind of mapping of audio frontend to audio backend.

What about "spice0-backend"? I'm not really sure though and open to 
suggestions.

[1]: https://lists.nongnu.org/archive/html/qemu-devel/2019-07/msg03583.html