From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mx.groups.io with SMTP id smtpd.web10.6181.1623236278904346234 for ; Wed, 09 Jun 2021 03:57:59 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=QgrhT3JG; spf=pass (domain: redhat.com, ip: 216.205.24.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1623236278; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xZOCeJ8W6pdW7aIuiryhmRajMlvOlOEwFFdLfdFwoXQ=; b=QgrhT3JGb2ohado6kmb9kmBp4b76yRafQ7bVLf6BVJc6o2FjENKyRTaJDcJnDgSG4aQgBL s2PxzKrY+OquYpyGvElwKh6B9/02P98Ecjp3MYaHTG2Jq/odg/y+Xa6QWS897SBBn0uadj E4ZXEjehFMaXyrsnXLsR+FLT+YKdreo= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-255-zwRTFIOnNoWvGElccpGqbw-1; Wed, 09 Jun 2021 06:57:56 -0400 X-MC-Unique: zwRTFIOnNoWvGElccpGqbw-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C09F58015A4; Wed, 9 Jun 2021 10:57:54 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-113-249.ams2.redhat.com [10.36.113.249]) by smtp.corp.redhat.com (Postfix) with ESMTPS id BFA5F5D719; Wed, 9 Jun 2021 10:57:53 +0000 (UTC) Subject: Re: [edk2-devel] VirtIO sound device in qemu? To: Leif Lindholm , Ethin Probst Cc: devel@edk2.groups.io, mcb30@ipxe.org References: <74f2a141-fe7c-b25c-ab65-aea8989cc885@redhat.com> <20210607213349.zyqbavq2kqm726h3@leviathan> <20210608202506.5ukz7kro33c7d54x@leviathan> From: "Laszlo Ersek" Message-ID: Date: Wed, 9 Jun 2021 12:57:52 +0200 MIME-Version: 1.0 In-Reply-To: <20210608202506.5ukz7kro33c7d54x@leviathan> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 06/08/21 22:25, Leif Lindholm wrote: > 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. SeaBIOS and OVMF patches are usually merged after the underlying QEMU device model is upstream. I'm uneducated about the "deliverables" in GSoC, but in general I'd suggest narrowing down the scope as much as possible. I don't know how hard it is to program USB audio, but if QEMU provides a good device model for that, out of the box, I would recommend basing the edk2 work on that device. Upstreaming QEMU patches can take very long, and it wouldn't be great if the usability (or "delivery") of the edk2 patch set depended on that. Especially if the authors of the QEMU and edk2 patches are different. Thanks Laszlo > > / > 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 >