Re: [edk2-devel] VirtIO sound device in qemu?

["Laszlo Ersek" <lersek@redhat.com>]

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 <leif@nuviainc.com> 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
>