* [pve-devel] Audio support, dummy/none @ 2021-01-03 0:55 Gilles Pietri 2021-01-04 15:55 ` Aaron Lauterer 2021-01-04 17:55 ` Gilles Pietri 0 siblings, 2 replies; 6+ messages in thread From: Gilles Pietri @ 2021-01-03 0:55 UTC (permalink / raw) To: pve-devel 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! 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… Also, though it's not my usecase atm, it might be interesting to add others backends as well, like alsa or pa. It was mentionned here: https://forum.proxmox.com/threads/audiodev-driver-pa-support.62317/#post-285020 However that will require second level options for the audio backends, which are not supported as it's coded. Cheers, Gilou ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [pve-devel] Audio support, dummy/none 2021-01-03 0:55 [pve-devel] Audio support, dummy/none Gilles Pietri @ 2021-01-04 15:55 ` Aaron Lauterer 2021-01-04 16:22 ` Gilles Pietri 2021-01-04 17:55 ` Gilles Pietri 1 sibling, 1 reply; 6+ messages in thread From: Aaron Lauterer @ 2021-01-04 15:55 UTC (permalink / raw) To: Proxmox VE development discussion, Gilles Pietri 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. 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. > > 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? > Also, though it's not my usecase atm, it might > be interesting to add others backends as well, like alsa or pa. It was > mentionned here: > https://forum.proxmox.com/threads/audiodev-driver-pa-support.62317/#post-285020 > > However that will require second level options for the audio backends, > which are not supported as it's coded. > > Cheers, > > Gilou All the best! Aaron [0] https://pve.proxmox.com/pve-docs/pve-admin-guide.html#qm_audio_device ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [pve-devel] Audio support, dummy/none 2021-01-04 15:55 ` Aaron Lauterer @ 2021-01-04 16:22 ` Gilles Pietri 0 siblings, 0 replies; 6+ messages in thread From: Gilles Pietri @ 2021-01-04 16:22 UTC (permalink / raw) To: Aaron Lauterer, Proxmox VE development discussion 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 > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [pve-devel] Audio support, dummy/none 2021-01-03 0:55 [pve-devel] Audio support, dummy/none Gilles Pietri 2021-01-04 15:55 ` Aaron Lauterer @ 2021-01-04 17:55 ` Gilles Pietri 2021-01-05 11:43 ` Aaron Lauterer 1 sibling, 1 reply; 6+ messages in thread From: Gilles Pietri @ 2021-01-04 17:55 UTC (permalink / raw) To: pve-devel Le 03/01/2021 à 01:55, Gilles Pietri a écrit : > 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! > > 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." > I tried it, it went on generating the kvm command line with none instead of spice as: -device 'ich9-intel-hda,id=audiodev0,bus=pci.2,addr=0xc' -device 'hda-micro,id=audiodev0-codec0,bus=audiodev0.0,cad=0,audiodev=none-backend0' -device 'hda-duplex,id=audiodev0-codec1,bus=audiodev0.0,cad=1,audiodev=none-backend0' -audiodev 'none,id=none-backend0' instead of the original: -device 'ich9-intel-hda,id=audiodev0,bus=pci.2,addr=0xc' -device 'hda-micro,id=audiodev0-codec0,bus=audiodev0.0,cad=0,audiodev=spice-backend0' -device 'hda-duplex,id=audiodev0-codec1,bus=audiodev0.0,cad=1,audiodev=spice-backend0' -audiodev 'spice,id=spice-backend0' And this works flawlessly… However, I guess I need to deploy the full version to have the webui integrating it, but I can follow up on that… Regards, Gilles ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [pve-devel] Audio support, dummy/none 2021-01-04 17:55 ` Gilles Pietri @ 2021-01-05 11:43 ` Aaron Lauterer 2021-01-05 19:33 ` Gilles Pietri 0 siblings, 1 reply; 6+ messages in thread From: Aaron Lauterer @ 2021-01-05 11:43 UTC (permalink / raw) To: pve-devel On 1/4/21 6:55 PM, Gilles Pietri wrote: > Le 03/01/2021 à 01:55, Gilles Pietri a écrit : >> 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! >> >> 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." >> > > I tried it, it went on generating the kvm command line with none instead > of spice as: > -device 'ich9-intel-hda,id=audiodev0,bus=pci.2,addr=0xc' -device > 'hda-micro,id=audiodev0-codec0,bus=audiodev0.0,cad=0,audiodev=none-backend0' > -device > 'hda-duplex,id=audiodev0-codec1,bus=audiodev0.0,cad=1,audiodev=none-backend0' > -audiodev 'none,id=none-backend0' > > instead of the original: > -device 'ich9-intel-hda,id=audiodev0,bus=pci.2,addr=0xc' -device > 'hda-micro,id=audiodev0-codec0,bus=audiodev0.0,cad=0,audiodev=spice-backend0' > -device > 'hda-duplex,id=audiodev0-codec1,bus=audiodev0.0,cad=1,audiodev=spice-backend0' > -audiodev 'spice,id=spice-backend0' > > And this works flawlessly… > > However, I guess I need to deploy the full version to have the webui > integrating it, but I can follow up on that… Adding support for the 'none' backend should not be too hard to implement. Besides changes in QemuServer.pm, the GUI (pve-manager) needs to be adapted as well because right now the backend is hard coded. Adding support for ALSA and / or pulseaudio is probably a bit more complicated to get it working "out of the box" and AFAICT our qemu build currently does not support the PA backend. If you want to take the challenge to implement the support for the none backend yourself, you are welcome to do so! Have a look at our Dev documentation [0]. We would also need a signed CLA[1] send to office@proxmox.com Alternatively you can create an enhancement request in our bugtracker so we can keep track of it. [0] https://pve.proxmox.com/wiki/Developer_Documentation [1] file:///tmp/mozilla_alauterer0/Proxmox-Individual-CLA.pdf [2] https://bugzilla.proxmox.com/ > > Regards, > Gilles > > _______________________________________________ > pve-devel mailing list > pve-devel@lists.proxmox.com > https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [pve-devel] Audio support, dummy/none 2021-01-05 11:43 ` Aaron Lauterer @ 2021-01-05 19:33 ` Gilles Pietri 0 siblings, 0 replies; 6+ messages in thread From: Gilles Pietri @ 2021-01-05 19:33 UTC (permalink / raw) To: pve-devel Le 05/01/2021 à 12:43, Aaron Lauterer a écrit : > Adding support for the 'none' backend should not be too hard to > implement. Besides changes in QemuServer.pm, the GUI (pve-manager) needs > to be adapted as well because right now the backend is hard coded. I'll start with that, it's a good "non intrusive" change that can get me more acquainted with the source and the overall build system, and separate git repos. > > Adding support for ALSA and / or pulseaudio is probably a bit more > complicated to get it working "out of the box" and AFAICT our qemu build > currently does not support the PA backend. True, and it will also require something like a second layer of dependent options, so it might make sense to have that stored/offered somewhere only once for API/qm and the Web UI, I'll think about it though… > > > If you want to take the challenge to implement the support for the none > backend yourself, you are welcome to do so! > Have a look at our Dev documentation [0]. We would also need a signed > CLA[1] send to office@proxmox.com I just did that, I like the idea of starting with a small feature ;) > > Alternatively you can create an enhancement request in our bugtracker so > we can keep track of it. I'll probably do it for alsa/pulseaudio support then, as this might be a little bit more delicate, and might require discussion. Thanks for your assistance and patience, hopefully I'll be able to help that way ;) Regards, Gilou ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-01-05 19:33 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-01-03 0:55 [pve-devel] Audio support, dummy/none Gilles Pietri 2021-01-04 15:55 ` Aaron Lauterer 2021-01-04 16:22 ` Gilles Pietri 2021-01-04 17:55 ` Gilles Pietri 2021-01-05 11:43 ` Aaron Lauterer 2021-01-05 19:33 ` Gilles Pietri
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox