[pve-devel] Audio support, dummy/none

[Gilles Pietri]

Le 04/01/2021 à 16:55, Aaron Lauterer a écrit :
> Hi Gilou!
> 
> On 1/3/21 1:55 AM, Gilles Pietri wrote:
>> Hi!
>>
>> Happy new year to everyone, especially the devs working on Proxmox, it's
>> still awesome in 2021 ;)
>>
>> I'm interested in replicating a qemu audio setup that uses the dummy
>> driver (called "none") on Proxmox, but the enum $audio_fmt
>> (PVE/QemuServer.pm) for drivers only contains spice as a choice, which
>> is all nice, but a bit restrictive!
> 
> May I ask what your use case is?
> 
> The reason why we currently only support the spice audio backend is that
> for other possible use cases, other (better / simpler) options exist.

Hi Aaron, and thanks for your answer!

Well, the usecase is an existing VM using KVM and a dummy audio device
that I would like to host in Proxmox rather than a standalone host hehe.
It's a bit sad not to allow an option available if it doesn't hurt the
overall proxmox experience ;)

I'm not sure exactly why this was done, though I assume it was to setup
a virtual sound device without any added complexity in the guest.

On that point, that goes further than my proposition, and we might
divert the subject for it, but here goes.

If you have clean setups to offer for a VM that requires sound, without
actually having an audio device to support it not involving:
- Windows fun or virtual audio cables, this is a Linux scenario
- pulseaudio dummy device: this has so many issues in clients…
- jackd dummy device: not really useful in real life scenario,
especially with clocks
- alsa dummy… COULD work, but it's not the easiest to set up, and you
need then pulse/jack to work with it. Also not really cool if you want
multiple devices, as it seems you can't hotplug stuff.

Then, I'm all ears ;)

> 
> Windows RDP supports audio by itself and if you need to play audio on
> the actual sound card it is simple to pass it through as PCI device to
> the VM.

That doesn't cut it, neither does spice for 2 reasons: it's a linux VM,
and the goal is for the audio to be totally unaffected by anything
happening to it (that is connecting / detaching using RDP, for example).

Spice is not too bad though, but well, I need sound even when detaching,
and I fear spice clients are not too keen on *not* relaying sound when
needed.

> 
>>
>> Since this is used only (?) to generate the audio conf (through
>> conf_has_audio), which generate the audio devices through audio_devs,
>> which in turn generates both the -device param and the -audiodev
>> backend,id=xxx, it seems there wouldn't be any side effect if we fed
>> "none" instead of spice, as the id param is valid and works the same
>> here.
>>
>> I haven't tried patching that, but it might be that this would boil
>> down to:
>>
>> diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
>> index bca5669..54278e5 100644
>> --- a/PVE/QemuServer.pm
>> +++ b/PVE/QemuServer.pm
>> @@ -211,7 +211,7 @@ my $audio_fmt = {
>>       },
>>       driver =>  {
>>          type => 'string',
>> -       enum => ['spice'],
>> +       enum => ['spice', 'none'],
>>          default => 'spice',
>>          optional => 1,
>>          description => "Driver backend for the audio device."
>>
>> And maybe, if we want to go further, we may want a bit of documentation
>> also, maybe on the wiki… 
> 
> Is the current documentation in the admin guide [0] enough or do you
> mean more documentation on how to setup more advanced audio setups, such
> as with PA or ALSA?

Yeah, I meant: if we add options there, we might want to add docs ;)
As-is, it's clear enough, that's fine. PA and alsa are not supported
either, or they? Or am I mistaken here…

Cheers,

Gilou

> [0] https://pve.proxmox.com/pve-docs/pve-admin-guide.html#qm_audio_device
>