From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f48.google.com (mail-wr1-f48.google.com [209.85.221.48]) by mx.groups.io with SMTP id smtpd.web12.2253.1623183910692462919 for ; Tue, 08 Jun 2021 13:25:11 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@nuviainc-com.20150623.gappssmtp.com header.s=20150623 header.b=VZrSJxIA; spf=pass (domain: nuviainc.com, ip: 209.85.221.48, mailfrom: leif@nuviainc.com) Received: by mail-wr1-f48.google.com with SMTP id f2so22903241wri.11 for ; Tue, 08 Jun 2021 13:25:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuviainc-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=azUa/xuEJrxOCo87uWQBuqPQZ3fxsSTqv4Lsu99pxPs=; b=VZrSJxIAdnkcoIxzFEme/NFNqLPnFjaTkUODkRWIR0xOofab3sO7QqX6irq1prEdK4 mOjA8de/I4/NUaHgQtgfdh52zx8sjikdWZuoUbHXBAMEJgUZISOV0nOFxFQX01acrVuG Z8rx/dCqyyX4SUVL3bIZKd1NL7ys00jtywUvuqYtIrxag+CnbxVJjDI7TFjLdTGuvGhV bH20l3ynWLmA3OICBrsPmpME8Ubzhw6+2FREjh4rxyexuktYUCVOcYFw5uPfQ29kC+r4 cqZR+52tYtwASele1JpDnMp63hKexbOQT6S4sckNaf+GbtBw0VvRmdWhs74RES2K5Vfn jCuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=azUa/xuEJrxOCo87uWQBuqPQZ3fxsSTqv4Lsu99pxPs=; b=lqe3qw5iPA9T7Nvhs/4iOGGfL0pcPpKgMpU9+ZXcmvu38i2UMNdt0bx4tZ7O8o0kK9 Pi9GTS51qfoSNdSuKvEaMXWoG9Oh9n7bvZ4swMtA3kxhCoQr8+vT6E1AdXzsgT1I5ZNU D4nR7D2cogqtv2+py3Sw2YPQ1/CyuFTP2ZIrJVtaL4Tb5wtK/x403Um5wAPhSK4z30dM PhO+FmI/NIngO6QVgsO4rXYXaB0poFbjWJlHuAAvMybQK9q32comVGg3OP0d4oytZbU7 +6T7Lk9gCHghW22qnCKwARPzDVyHTeGNjXGvuRi3Kq4t235SdTEJZLp8aBiuQAnW/Jt4 LVCA== X-Gm-Message-State: AOAM531o0IQ2X1PjWwGk6wuXsqOof6qv07Vxn/qZST6V/m+wgTKl6FOf 9vXvro+ye2lAoyScGLQ9NdhgaA== X-Google-Smtp-Source: ABdhPJwAlstOISkiMGm2CPk3XL0o6gwSasgR/1lA7/HY4WOHQzc8ZtOHNXKggWEvQWvhNPz0gsWqDw== X-Received: by 2002:adf:a489:: with SMTP id g9mr24187860wrb.103.1623183909146; Tue, 08 Jun 2021 13:25:09 -0700 (PDT) Return-Path: Received: from leviathan (cpc1-cmbg19-2-0-cust915.5-4.cable.virginm.net. [82.27.183.148]) by smtp.gmail.com with ESMTPSA id o11sm5226174wmq.1.2021.06.08.13.25.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Jun 2021 13:25:08 -0700 (PDT) Date: Tue, 8 Jun 2021 21:25:06 +0100 From: "Leif Lindholm" To: Ethin Probst Cc: devel@edk2.groups.io, lersek@redhat.com, mcb30@ipxe.org Subject: Re: [edk2-devel] VirtIO sound device in qemu? Message-ID: <20210608202506.5ukz7kro33c7d54x@leviathan> References: <74f2a141-fe7c-b25c-ab65-aea8989cc885@redhat.com> <20210607213349.zyqbavq2kqm726h3@leviathan> MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Ethin, Adapting and overcoming is very much the point of GSoC. The purpose of this project was always to bring portable audio support to EDK2, and longer-term the UEFI specification. Virtio was just the ideal means to that end. If it turns out not being the ideal way, that's just the way it is. *But*, I want to point out that there is no reason why we couldn't build this on top of a not-yet-upstream QEMU patchset - and help out by providing an eager real consumer for it. The virtio-snd RFC has been sent out, and it is very unlikely that it will not end up being merged, if in a modified form from what the first proof-of-concept looked like. Working with it would give you the opportunity to influence that implementation, as well as the virtio-snd standard. *However*, if the state of the QEMU virtio-snd RFC is not one that lends itself to basing other work on, then QEMU's usb-audio support is a close second - that should also be portable to other If we pick that route, you can always come back to virtio a bit later if you make good progress on USB Audio Device Class 1.0. / Leif On Tue, Jun 08, 2021 at 13:52:14 -0500, Ethin Probst wrote: > So I just might have to go with USB audio (the basic audio device > class) since no code in QEMU for VirtIO audio has actually been > committed upstream. Perusing the qemu code (specifically this: > https://github.com/qemu/qemu/blob/master/hw/usb/dev-audio.c) it > appears that Qemu implements v. 1.0 of the ADC specification. Section > 5.3.3.1.2 of the USB basic audio device specification (v. 1.0) > confirms that the bcdADC field should be set to 0100h. Will doing this > violate any rules of GSoC or anything like that? > I can implement VirtIO, but I will have no way of testing it until > Qemu actually adds it in (unless there's another emulator that > implements it). :-( > > On 6/7/21, Leif Lindholm wrote: > > On Mon, Jun 07, 2021 at 17:16:00 +0200, Laszlo Ersek wrote: > >> On 06/07/21 13:40, Michael Brown wrote: > >> > On 07/06/2021 05:41, Ethin Probst wrote: > >> >> For my audio output protocol (I wonder if we should abbreviate it as > >> >> AOP?) I need to get access to VirtIO devices in PCIe configuration > >> >> space. However, I can't seem to find a way of telling QEMU to use this > >> >> device for audio output. Is there something I missed, or something > >> >> that does support this? > >> > > >> > Do you mean that you can't find a way to get QEMU to create a Virtio > >> > audio device visible to the guest, or that you can't find a way to get > >> > QEMU to connect this Virtio device to the host-side audio output? > >> > >> My latest (admittedly, quite old) information has been that QEMU does > >> not implement a virtio-audio device yet. It's been work in progress. > >> Best inquire on qemu-devel, CC'ing the audio subsys maintainers. > > > > An RFC sent out end of April has not yet seen a PATCH, but some > > feedback: > > https://lists.gnu.org/archive/html/qemu-devel/2021-04/msg06089.html > > > > / > > Leif > > > > > -- > Signed, > Ethin D. Probst