From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id EBD2665CE3 for ; Mon, 4 Jan 2021 17:23:28 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id E09F61F743 for ; Mon, 4 Jan 2021 17:22:58 +0100 (CET) Received: from vizir.gilouweb.com (vizir.gilouweb.com [51.254.229.100]) by firstgate.proxmox.com (Proxmox) with ESMTP id 1D9981F736 for ; Mon, 4 Jan 2021 17:22:56 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by vizir.gilouweb.com (Postfix) with ESMTP id A05F782B40F; Mon, 4 Jan 2021 17:22:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gilouweb.com; s=mail; t=1609777370; bh=gfZssifjk+qWeA0/iufihen8rGpCKffuguBV+LiGnXo=; h=Subject:To:References:From:Date:In-Reply-To:From; b=DY4bWCizKVmRVadflv2DZ+C9QVaq6DHX1kce8eZaXJ7eAMV4aeJrB2eZ9Vxn65kvk M3x8jMft1y7uCdUGD/WljhV8ROi0+W4aRKjDEFYjsWthwtxrYyidfBbnSHyoN4wn5C BXnP2Ug1o85s9gaOePOdBBmfJ2OsR6IUvfa0lDP82T5j2IegN/TAiEA0W1ply4MI8M YKYRscZyf0h2JPkri9noaCMOvRYQaKTgRJImGHWoZ/hGvLI2FR+ifB0EzM5K/npEmD MBCZRvIpw1ZBFJMmoGsM6grZP5Ih+auPG6fABEHhAKROoi5xae90WlWXDX7JK3VY1+ 8jg/dBUjc23+g== X-Virus-Scanned: Debian amavisd-new at vizir.gilouweb.com Received: from vizir.gilouweb.com ([127.0.0.1]) by localhost (vizir.gilouweb.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hejyD2ybaH1M; Mon, 4 Jan 2021 17:22:40 +0100 (CET) Received: from [IPv6:2001:910:102d::3ca] (unknown [IPv6:2001:910:102d::3ca]) by vizir.gilouweb.com (Postfix) with ESMTPSA id 920F582B406; Mon, 4 Jan 2021 17:22:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gilouweb.com; s=mail; t=1609777360; bh=gfZssifjk+qWeA0/iufihen8rGpCKffuguBV+LiGnXo=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Ixz8koQIlNqdsrwyMvtANwTgPL8YwSSnbLc8/silQfwFywnKv+udqEQPaO0ZC3x+3 QuvWv6kUPTCb78nF4pMQ5I6M9lH+ZvAlsynZozOvw29SMq4avjeJhOgyJW7+0Uf2YD EmicmxRw/3JXoKQ7vParJbYiL/48VfIp05kObCeQMYqIxwPYkqTJItGCKYbGnJFUHU NFOcXJ8Ddm4K5Vruy+2A5pcdNmHbivGYdVegefMXtDxMhBjvpHzySbauXuM1vVJ4qO Xhi9WgmmArOXZYEel/c5/SzQGIy+Zg4QEjm1BPSD3LjqTzNTRedvesEtqRPHXfydWs aGGccOELw7MiA== To: Aaron Lauterer , Proxmox VE development discussion References: <309fe8ad-2589-5699-be3d-4f5a1ac0cbea@gilouweb.com> <90c45c7c-c131-c761-dafd-6f18cf4ec69f@proxmox.com> From: Gilles Pietri Message-ID: <49617e8d-e13a-cee4-7e93-f0e4765ef1ee@gilouweb.com> Date: Mon, 4 Jan 2021 17:22:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <90c45c7c-c131-c761-dafd-6f18cf4ec69f@proxmox.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.001 Adjusted score from AWL reputation of From: address DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain NICE_REPLY_A -0.001 Looks like a legit reply (A) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] Audio support, dummy/none X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2021 16:23:29 -0000 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 >