From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) by mx.groups.io with SMTP id smtpd.web10.901.1623194992142396376 for ; Tue, 08 Jun 2021 16:29:52 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Bodsg3tL; spf=pass (domain: gmail.com, ip: 209.85.167.54, mailfrom: rafaelrodrigues.machado@gmail.com) Received: by mail-lf1-f54.google.com with SMTP id m21so19108776lfg.13 for ; Tue, 08 Jun 2021 16:29:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xzvm0J6JfXMWm8iirdmQtVEF5fQZixqFX4bzLKwhfvA=; b=Bodsg3tLFNuS8LVCj6U2Y3hjE8Vct/6+oK0+CSJW76Vvk3VoBBwrrIL/fBCFZ4wMFo j1HpMvMBcVjCc4OND/dis/GFPHviAOu9K9rK0m+N6EtnyeXyP6ksDaycFfZsOL+dvq0o SOmB55ECK410eha/Hgu0crbw1vuttAI8LQU0z0UqKQH+IltxwR09v6ZE53aUnOq1u5JL VAR8BrWUq3/u452GqKysCj4D+CLdnNoFsUs23djUVLNXWSAYV8U8nU6ICbVHLUKAD07m t2f7dcpCSU+k6BKNrSeJJy7ZNT4ZWvApWEatQBe9TuYDDaBhFtKEIwIDIamCMnQHaHK+ ZyIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xzvm0J6JfXMWm8iirdmQtVEF5fQZixqFX4bzLKwhfvA=; b=HwBz3Hzn0+kLmKVpInAOuexpQvCYx5hk/fUxTjieHi7Jlim6zx0Xu0Gk6DcCjUblEF eQKyGWyFgm/Dtatikhrm9AplAp36Z8sYS3EA+3Y6dLKBbMZr1bk1UKTNcttnpPFb0Lxi FV8gWedJNgwH/gx9BvlKymVwT7j/dcGsOqx23Lr1VHVorQM1wm73VKzc5q1P647jXN/9 QP06A8doRiQ+tnzvt5foMEojnI/VnLDq1MXA1PVVlSn1WwXpx1e2zH2p/3cHlD6cMPmK ItM1H/vIA8QOeUL+ylk6AxoSCCkPsEtiaNBxtwwBSzFuxvpypSBVZn+GxRRHFsO2SLhx HeGg== X-Gm-Message-State: AOAM531XMLxm+da0EwSibtEf2MFEduGHAXRiYNTMvJnB/vfl409BiRpM ILWAEZYbliAwrXLP6WbIdVOgchWNi280udGZPT8NoUB9qok= X-Google-Smtp-Source: ABdhPJzQqhLOPvXQom8HXawhUovgvthPQQZSc+RP+HrokDweGFM0xcRWKzzhpW74O0TPefQun/ezbFK4FTS3slld/ns= X-Received: by 2002:ac2:5e2b:: with SMTP id o11mr16862075lfg.548.1623194990119; Tue, 08 Jun 2021 16:29:50 -0700 (PDT) MIME-Version: 1.0 References: <74f2a141-fe7c-b25c-ab65-aea8989cc885@redhat.com> <20210607213349.zyqbavq2kqm726h3@leviathan> <20210608202506.5ukz7kro33c7d54x@leviathan> In-Reply-To: <20210608202506.5ukz7kro33c7d54x@leviathan> From: "Rafael Machado" Date: Tue, 8 Jun 2021 20:29:37 -0300 Message-ID: Subject: Re: [edk2-devel] VirtIO sound device in qemu? To: devel@edk2.groups.io, leif@nuviainc.com Cc: Ethin Probst , Laszlo Ersek , mcb30@ipxe.org Content-Type: multipart/alternative; boundary="000000000000c98eee05c4498872" --000000000000c98eee05c4498872 Content-Type: text/plain; charset="UTF-8" That remembers me why did I do my mastering thesys using a real hardware :) Rafael Em ter, 8 de jun de 2021 17:25, Leif Lindholm escreveu: > 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 > > > > > > --000000000000c98eee05c4498872 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That remembers me why did I do my mastering thesys using = a real hardware :)

Rafael

Em ter, 8 de jun de 2021 17:25, Leif Lindholm <leif@nuviainc.com> escreveu:
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.

/
=C2=A0 =C2=A0 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 thi= s
> 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 PCI= e configuration
> >> >> space. However, I can't seem to find a way of t= elling QEMU to use this
> >> >> device for audio output. Is there something I misse= d, or something
> >> >> that does support this?
> >> >
> >> > Do you mean that you can't find a way to get QEMU t= o 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 aud= io 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 main= tainers.
> >
> > An RFC sent out end of April has not yet seen a PATCH, but some<= br> > > feedback:
> > https://lis= ts.gnu.org/archive/html/qemu-devel/2021-04/msg06089.html
> >
> > /
> >=C2=A0 =C2=A0 =C2=A0Leif
> >
>
>
> --
> Signed,
> Ethin D. Probst





--000000000000c98eee05c4498872--