VirtIO Sound Driver (GSoC 2021)

VirtIO Sound Driver (GSoC 2021)

[Ethin Probst]

Hello everyone,

This is the first time I've ever contributed to EDK2. As part of GSoC
2021, I have submitted a proposal to implement a UEFI audio output
protocol that will utilize the VirtIO sound driver. I've already
submitted a draft proposal, and apologize if I've done things out of
order. This is my first time doing GSoC 2021, and contributing to EDK2
felt like a really fun thing to do!

I look forward to working with you guys on this and any future projects! :-)

-- 
Signed,
Ethin D. Probst

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Nate DeSimone]

Hi Ethin,

Great to meet you and welcome to the TianoCore project! Glad you hear you are interested! The audio output protocol would be a great GSoC project! VirtIO/Qemu support seems like a good baseline to start with. Real hardware codecs like a USB audio class driver would be a good extension after the emulation case Is implemented. I would also recommend putting a testing strategy into your project proposal, maybe write a simple UEFI shell application that plays a .wav file using AUDIO_OUTPUT_PROTOCOL?

I took a quick look at your application, please make sure that you answer all the questions that we list in our application template: https://github.com/tianocore/tianocore.github.io/wiki/GSoC2021#application-template

Hope this helps and welcome to the project!

With Best Regards,
Nate

> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Ethin
> Probst
> Sent: Monday, March 29, 2021 1:29 PM
> To: devel@edk2.groups.io
> Subject: [edk2-devel] VirtIO Sound Driver (GSoC 2021)
> 
> Hello everyone,
> 
> This is the first time I've ever contributed to EDK2. As part of GSoC 2021, I
> have submitted a proposal to implement a UEFI audio output protocol that
> will utilize the VirtIO sound driver. I've already submitted a draft proposal,
> and apologize if I've done things out of order. This is my first time doing GSoC
> 2021, and contributing to EDK2 felt like a really fun thing to do!
> 
> I look forward to working with you guys on this and any future projects! :-)
> 
> --
> Signed,
> Ethin D. Probst
> 
> 
> 
> 

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Ethin Probst]

[-- Attachment #1: Type: text/plain, Size: 220 bytes --]

Hi Nate,

I appreciate the feedback, but I'm quite confused on exactly what questions I've failed to answer? I didn't include my other contact information but I'm not sure what else might be missing from my proposal.

[-- Attachment #2: Type: text/html, Size: 228 bytes --]

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Rafael Machado]

[-- Attachment #1: Type: text/plain, Size: 893 bytes --]

This would be amazing so people can continue my work related to
accessibility at BIOS. Something desired by the blind people since the 90's
Just for reference, this is what I have done:

https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility

Thanks
Rafael

Em seg, 29 de mar de 2021 20:24, Ethin Probst <harlydavidsen@gmail.com>
escreveu:

> Hello everyone,
>
> This is the first time I've ever contributed to EDK2. As part of GSoC
> 2021, I have submitted a proposal to implement a UEFI audio output
> protocol that will utilize the VirtIO sound driver. I've already
> submitted a draft proposal, and apologize if I've done things out of
> order. This is my first time doing GSoC 2021, and contributing to EDK2
> felt like a really fun thing to do!
>
> I look forward to working with you guys on this and any future projects!
> :-)
>
> --
> Signed,
> Ethin D. Probst
>
>
> 
>
>
>

[-- Attachment #2: Type: text/html, Size: 1486 bytes --]

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Ethin Probst]

I agree. Plus, it gives me a chance to finally learn the EDK2 build
system and how it works! I've been working on a hobby OS as a side
project and, though learning from other code examples from OSes is
fun, I have to say that learning from the firmware code like from
SeaBIOS has been some of the most enlightening and interesting times
thus far.
Thanks for the link to your code, Rafael; once I get virtIO support
in, I can work on HDA support, though I might tackle USB support
second and HDA third. We'll see, but VirtIO definitely is coming
first.

As I said before, I look forward to working with all of you wonderful people!

On 3/30/21, Rafael Rodrigues Machado <rafaelrodrigues.machado@gmail.com> wrote:
> This would be amazing so people can continue my work related to
> accessibility at BIOS. Something desired by the blind people since the 90's
> Just for reference, this is what I have done:
>
> https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
>
> Thanks
> Rafael
>
> Em seg, 29 de mar de 2021 20:24, Ethin Probst <harlydavidsen@gmail.com>
> escreveu:
>
>> Hello everyone,
>>
>> This is the first time I've ever contributed to EDK2. As part of GSoC
>> 2021, I have submitted a proposal to implement a UEFI audio output
>> protocol that will utilize the VirtIO sound driver. I've already
>> submitted a draft proposal, and apologize if I've done things out of
>> order. This is my first time doing GSoC 2021, and contributing to EDK2
>> felt like a really fun thing to do!
>>
>> I look forward to working with you guys on this and any future projects!
>> :-)
>>
>> --
>> Signed,
>> Ethin D. Probst
>>
>>
>> 
>>
>>
>>
>


-- 
Signed,
Ethin D. Probst

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Ethin Probst]

I'm wondering where exactly I should add the VirtIO sound protocol. I
just familiarized myself with the build system and am about to test it
by building OVMF if possible, but I'm wondering where I should
actually put the protocol and all that stuff. Maybe there's
documentation I've missed as well.

On 3/30/21, Ethin Probst via groups.io
<harlydavidsen=gmail.com@groups.io> wrote:
> I agree. Plus, it gives me a chance to finally learn the EDK2 build
> system and how it works! I've been working on a hobby OS as a side
> project and, though learning from other code examples from OSes is
> fun, I have to say that learning from the firmware code like from
> SeaBIOS has been some of the most enlightening and interesting times
> thus far.
> Thanks for the link to your code, Rafael; once I get virtIO support
> in, I can work on HDA support, though I might tackle USB support
> second and HDA third. We'll see, but VirtIO definitely is coming
> first.
>
> As I said before, I look forward to working with all of you wonderful
> people!
>
> On 3/30/21, Rafael Rodrigues Machado <rafaelrodrigues.machado@gmail.com>
> wrote:
>> This would be amazing so people can continue my work related to
>> accessibility at BIOS. Something desired by the blind people since the
>> 90's
>> Just for reference, this is what I have done:
>>
>> https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
>>
>> Thanks
>> Rafael
>>
>> Em seg, 29 de mar de 2021 20:24, Ethin Probst <harlydavidsen@gmail.com>
>> escreveu:
>>
>>> Hello everyone,
>>>
>>> This is the first time I've ever contributed to EDK2. As part of GSoC
>>> 2021, I have submitted a proposal to implement a UEFI audio output
>>> protocol that will utilize the VirtIO sound driver. I've already
>>> submitted a draft proposal, and apologize if I've done things out of
>>> order. This is my first time doing GSoC 2021, and contributing to EDK2
>>> felt like a really fun thing to do!
>>>
>>> I look forward to working with you guys on this and any future projects!
>>> :-)
>>>
>>> --
>>> Signed,
>>> Ethin D. Probst
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
>
> --
> Signed,
> Ethin D. Probst
>
>
> 
>
>
>


-- 
Signed,
Ethin D. Probst

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Andrew Fish]

[-- Attachment #1: Type: text/plain, Size: 4251 bytes --]


> On Mar 30, 2021, at 5:01 PM, Ethin Probst <harlydavidsen@gmail.com> wrote:
> 
> I'm wondering where exactly I should add the VirtIO sound protocol. I
> just familiarized myself with the build system and am about to test it
> by building OVMF if possible, but I'm wondering where I should
> actually put the protocol and all that stuff. Maybe there's
> documentation I've missed as well.

Ethin,

For the driver I’d match the patter of OVMF [1] and use OvmfPkg/VirtioSoundDxe/. Maybe even use one of the other drivers as a template. 

The protocol is more of a public thing. I think eventually we would like to publish the protocol in the UEFI Spec (I can help with that part) and that would mean we put the Protocol definition in MdePkg/Include/Protocol, but we don’t want to do that before it is standardized as that causes compatibility issues. So this is a “code first project” (code prototype and then contribute to the UEFI Forum for inclusion in the specification) so we need to follow some code first rules that I don’t remember of the top of my head? So why not start out the protocol definition OvmfPkg/Include/Protocol. You can also add a test application looks like you can just use the root [2] of OVMF for that. That way the project is not blocked. 

We can have a conversation on the mailing list about better places to put stuff, and it should be easy enough to move stuff around if everything else is working.

[1] find OvmfPkg  -iname '*Virtio*.inf'
OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf
OvmfPkg/Library/VirtioLib/VirtioLib.inf
OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
OvmfPkg/Virtio10Dxe/Virtio10.inf
OvmfPkg/VirtioNetDxe/VirtioNet.inf
OvmfPkg/VirtioRngDxe/VirtioRng.inf

[2] /Volumes/Case/edk2-github/OvmfPkg>git grep APPLICATION -- *.inf | grep MODULE_TYPE
EnrollDefaultKeys/EnrollDefaultKeys.inf:13:  MODULE_TYPE                    = UEFI_APPLICATION

Thanks,

Andrew Fish


> 
> On 3/30/21, Ethin Probst via groups.io <http://groups.io/>
> <harlydavidsen=gmail.com@groups.io <mailto:harlydavidsen=gmail.com@groups.io>> wrote:
>> I agree. Plus, it gives me a chance to finally learn the EDK2 build
>> system and how it works! I've been working on a hobby OS as a side
>> project and, though learning from other code examples from OSes is
>> fun, I have to say that learning from the firmware code like from
>> SeaBIOS has been some of the most enlightening and interesting times
>> thus far.
>> Thanks for the link to your code, Rafael; once I get virtIO support
>> in, I can work on HDA support, though I might tackle USB support
>> second and HDA third. We'll see, but VirtIO definitely is coming
>> first.
>> 
>> As I said before, I look forward to working with all of you wonderful
>> people!
>> 
>> On 3/30/21, Rafael Rodrigues Machado <rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>>
>> wrote:
>>> This would be amazing so people can continue my work related to
>>> accessibility at BIOS. Something desired by the blind people since the
>>> 90's
>>> Just for reference, this is what I have done:
>>> 
>>> https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
>>> 
>>> Thanks
>>> Rafael
>>> 
>>> Em seg, 29 de mar de 2021 20:24, Ethin Probst <harlydavidsen@gmail.com>
>>> escreveu:
>>> 
>>>> Hello everyone,
>>>> 
>>>> This is the first time I've ever contributed to EDK2. As part of GSoC
>>>> 2021, I have submitted a proposal to implement a UEFI audio output
>>>> protocol that will utilize the VirtIO sound driver. I've already
>>>> submitted a draft proposal, and apologize if I've done things out of
>>>> order. This is my first time doing GSoC 2021, and contributing to EDK2
>>>> felt like a really fun thing to do!
>>>> 
>>>> I look forward to working with you guys on this and any future projects!
>>>> :-)
>>>> 
>>>> --
>>>> Signed,
>>>> Ethin D. Probst
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
>> --
>> Signed,
>> Ethin D. Probst
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 
> -- 
> Signed,
> Ethin D. Probst
> 
> 
> 


[-- Attachment #2: Type: text/html, Size: 19394 bytes --]

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Nate DeSimone]

[-- Attachment #1: Type: text/plain, Size: 789 bytes --]

Hi Ethin,

I’m not quite sure what happened but I loaded it up again and the text shown now makes a lot more sense, thank you for your application!

Nate

From: <devel@edk2.groups.io> on behalf of Ethin Probst <harlydavidsen@gmail.com>
Reply-To: "devel@edk2.groups.io" <devel@edk2.groups.io>, "harlydavidsen@gmail.com" <harlydavidsen@gmail.com>
Date: Tuesday, March 30, 2021 at 7:41 AM
To: "Desimone, Nathaniel L" <nathaniel.l.desimone@intel.com>, "devel@edk2.groups.io" <devel@edk2.groups.io>
Subject: Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

Hi Nate,

I appreciate the feedback, but I'm quite confused on exactly what questions I've failed to answer? I didn't include my other contact information but I'm not sure what else might be missing from my proposal.


[-- Attachment #2: Type: text/html, Size: 3200 bytes --]

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Nate DeSimone]

[-- Attachment #1: Type: text/plain, Size: 4700 bytes --]

Another option is to put the protocol definition in MdeModulePkg and mark it with the EDKII_ prefix. For my last “code first” UEFI spec contribution I did this with the PPI that added up getting added.

Thanks,
Nate

From: <devel@edk2.groups.io> on behalf of "Andrew Fish via groups.io" <afish=apple.com@groups.io>
Reply-To: "devel@edk2.groups.io" <devel@edk2.groups.io>, "afish@apple.com" <afish@apple.com>
Date: Tuesday, March 30, 2021 at 10:54 PM
To: edk2-devel-groups-io <devel@edk2.groups.io>, "harlydavidsen@gmail.com" <harlydavidsen@gmail.com>
Cc: Rafael Rodrigues Machado <rafaelrodrigues.machado@gmail.com>
Subject: Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)



On Mar 30, 2021, at 5:01 PM, Ethin Probst <harlydavidsen@gmail.com<mailto:harlydavidsen@gmail.com>> wrote:

I'm wondering where exactly I should add the VirtIO sound protocol. I
just familiarized myself with the build system and am about to test it
by building OVMF if possible, but I'm wondering where I should
actually put the protocol and all that stuff. Maybe there's
documentation I've missed as well.

Ethin,

For the driver I’d match the patter of OVMF [1] and use OvmfPkg/VirtioSoundDxe/. Maybe even use one of the other drivers as a template.

The protocol is more of a public thing. I think eventually we would like to publish the protocol in the UEFI Spec (I can help with that part) and that would mean we put the Protocol definition in MdePkg/Include/Protocol, but we don’t want to do that before it is standardized as that causes compatibility issues. So this is a “code first project” (code prototype and then contribute to the UEFI Forum for inclusion in the specification) so we need to follow some code first rules that I don’t remember of the top of my head? So why not start out the protocol definition OvmfPkg/Include/Protocol. You can also add a test application looks like you can just use the root [2] of OVMF for that. That way the project is not blocked.

We can have a conversation on the mailing list about better places to put stuff, and it should be easy enough to move stuff around if everything else is working.

[1] find OvmfPkg  -iname '*Virtio*.inf'
OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf
OvmfPkg/Library/VirtioLib/VirtioLib.inf
OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
OvmfPkg/Virtio10Dxe/Virtio10.inf
OvmfPkg/VirtioNetDxe/VirtioNet.inf
OvmfPkg/VirtioRngDxe/VirtioRng.inf


[2] /Volumes/Case/edk2-github/OvmfPkg>git grep APPLICATION -- *.inf | grep MODULE_TYPE
EnrollDefaultKeys/EnrollDefaultKeys.inf:13:  MODULE_TYPE                    = UEFI_APPLICATION

Thanks,

Andrew Fish




On 3/30/21, Ethin Probst via groups.io<http://groups.io/>
<harlydavidsen=gmail.com@groups.io<mailto:harlydavidsen=gmail.com@groups.io>> wrote:

I agree. Plus, it gives me a chance to finally learn the EDK2 build
system and how it works! I've been working on a hobby OS as a side
project and, though learning from other code examples from OSes is
fun, I have to say that learning from the firmware code like from
SeaBIOS has been some of the most enlightening and interesting times
thus far.
Thanks for the link to your code, Rafael; once I get virtIO support
in, I can work on HDA support, though I might tackle USB support
second and HDA third. We'll see, but VirtIO definitely is coming
first.

As I said before, I look forward to working with all of you wonderful
people!

On 3/30/21, Rafael Rodrigues Machado <rafaelrodrigues.machado@gmail.com<mailto:rafaelrodrigues.machado@gmail.com>>
wrote:

This would be amazing so people can continue my work related to
accessibility at BIOS. Something desired by the blind people since the
90's
Just for reference, this is what I have done:

https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility

Thanks
Rafael

Em seg, 29 de mar de 2021 20:24, Ethin Probst <harlydavidsen@gmail.com>
escreveu:


Hello everyone,

This is the first time I've ever contributed to EDK2. As part of GSoC
2021, I have submitted a proposal to implement a UEFI audio output
protocol that will utilize the VirtIO sound driver. I've already
submitted a draft proposal, and apologize if I've done things out of
order. This is my first time doing GSoC 2021, and contributing to EDK2
felt like a really fun thing to do!

I look forward to working with you guys on this and any future projects!
:-)

--
Signed,
Ethin D. Probst








--
Signed,
Ethin D. Probst







--
Signed,
Ethin D. Probst






[-- Attachment #2: Type: text/html, Size: 12105 bytes --]

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Ethin Probst]

Hello there,

Some good advice, and thank you! I might add it to the other virtIO*
drivers if I can figure out a good template for that.

One thing I'm running into right now is that my build setup is
currently unable to build MdeModulePkg (which is required to build
OVMF, according to the readme). I've reported it on the bugzilla; its
issue 3289. This doesn't appear to occur on Linux, however, which is
odd.

Are there any suggestions that you guys have for improving my
proposal? I didn't want to write too much or go overboard, like
explaining how the sound driver would work and such, since I assumed
-- while writing it -- that anyone who wanted to know those inner
details would go read the VirtIO specification. But I'd appreciate any
extra feedback before I submit my final version; I haven't made any
changes since my initial proposal as of yet.

On 3/31/21, Nate DeSimone <nathaniel.l.desimone@intel.com> wrote:
> Another option is to put the protocol definition in MdeModulePkg and mark it
> with the EDKII_ prefix. For my last “code first” UEFI spec contribution I
> did this with the PPI that added up getting added.
>
> Thanks,
> Nate
>
> From: <devel@edk2.groups.io> on behalf of "Andrew Fish via groups.io"
> <afish=apple.com@groups.io>
> Reply-To: "devel@edk2.groups.io" <devel@edk2.groups.io>, "afish@apple.com"
> <afish@apple.com>
> Date: Tuesday, March 30, 2021 at 10:54 PM
> To: edk2-devel-groups-io <devel@edk2.groups.io>, "harlydavidsen@gmail.com"
> <harlydavidsen@gmail.com>
> Cc: Rafael Rodrigues Machado <rafaelrodrigues.machado@gmail.com>
> Subject: Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)
>
>
>
> On Mar 30, 2021, at 5:01 PM, Ethin Probst
> <harlydavidsen@gmail.com<mailto:harlydavidsen@gmail.com>> wrote:
>
> I'm wondering where exactly I should add the VirtIO sound protocol. I
> just familiarized myself with the build system and am about to test it
> by building OVMF if possible, but I'm wondering where I should
> actually put the protocol and all that stuff. Maybe there's
> documentation I've missed as well.
>
> Ethin,
>
> For the driver I’d match the patter of OVMF [1] and use
> OvmfPkg/VirtioSoundDxe/. Maybe even use one of the other drivers as a
> template.
>
> The protocol is more of a public thing. I think eventually we would like to
> publish the protocol in the UEFI Spec (I can help with that part) and that
> would mean we put the Protocol definition in MdePkg/Include/Protocol, but we
> don’t want to do that before it is standardized as that causes compatibility
> issues. So this is a “code first project” (code prototype and then
> contribute to the UEFI Forum for inclusion in the specification) so we need
> to follow some code first rules that I don’t remember of the top of my head?
> So why not start out the protocol definition OvmfPkg/Include/Protocol. You
> can also add a test application looks like you can just use the root [2] of
> OVMF for that. That way the project is not blocked.
>
> We can have a conversation on the mailing list about better places to put
> stuff, and it should be easy enough to move stuff around if everything else
> is working.
>
> [1] find OvmfPkg  -iname '*Virtio*.inf'
> OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
> OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
> OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf
> OvmfPkg/Library/VirtioLib/VirtioLib.inf
> OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
> OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
> OvmfPkg/Virtio10Dxe/Virtio10.inf
> OvmfPkg/VirtioNetDxe/VirtioNet.inf
> OvmfPkg/VirtioRngDxe/VirtioRng.inf
>
>
> [2] /Volumes/Case/edk2-github/OvmfPkg>git grep APPLICATION -- *.inf | grep
> MODULE_TYPE
> EnrollDefaultKeys/EnrollDefaultKeys.inf:13:  MODULE_TYPE
> = UEFI_APPLICATION
>
> Thanks,
>
> Andrew Fish
>
>
>
>
> On 3/30/21, Ethin Probst via groups.io<http://groups.io/>
> <harlydavidsen=gmail.com@groups.io<mailto:harlydavidsen=gmail.com@groups.io>>
> wrote:
>
> I agree. Plus, it gives me a chance to finally learn the EDK2 build
> system and how it works! I've been working on a hobby OS as a side
> project and, though learning from other code examples from OSes is
> fun, I have to say that learning from the firmware code like from
> SeaBIOS has been some of the most enlightening and interesting times
> thus far.
> Thanks for the link to your code, Rafael; once I get virtIO support
> in, I can work on HDA support, though I might tackle USB support
> second and HDA third. We'll see, but VirtIO definitely is coming
> first.
>
> As I said before, I look forward to working with all of you wonderful
> people!
>
> On 3/30/21, Rafael Rodrigues Machado
> <rafaelrodrigues.machado@gmail.com<mailto:rafaelrodrigues.machado@gmail.com>>
> wrote:
>
> This would be amazing so people can continue my work related to
> accessibility at BIOS. Something desired by the blind people since the
> 90's
> Just for reference, this is what I have done:
>
> https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
>
> Thanks
> Rafael
>
> Em seg, 29 de mar de 2021 20:24, Ethin Probst <harlydavidsen@gmail.com>
> escreveu:
>
>
> Hello everyone,
>
> This is the first time I've ever contributed to EDK2. As part of GSoC
> 2021, I have submitted a proposal to implement a UEFI audio output
> protocol that will utilize the VirtIO sound driver. I've already
> submitted a draft proposal, and apologize if I've done things out of
> order. This is my first time doing GSoC 2021, and contributing to EDK2
> felt like a really fun thing to do!
>
> I look forward to working with you guys on this and any future projects!
> :-)
>
> --
> Signed,
> Ethin D. Probst
>
>
>
>
>
>
>
>
> --
> Signed,
> Ethin D. Probst
>
>
>
>
>
>
>
> --
> Signed,
> Ethin D. Probst
>
>
>
>
>
>
>
> 
>
>
>


-- 
Signed,
Ethin D. Probst

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Marvin Häuser]

Good day Ethin and all,

I'd recommend you taking a look at our audio implementation at 
Acidanthera: 
https://github.com/acidanthera/OpenCorePkg/tree/master/Staging/AudioDxe
It was tested on at least a few hundred, possibly a few thousand 
machines to work adequately. This includes preboot accessibility voice 
assistance in both text UI and GUI. Please note that there was no 
thorough review and there may be minor reliability or security defects left.

Best regards,
Marvin

On 29.03.21 22:28, Ethin Probst wrote:
> Hello everyone,
>
> This is the first time I've ever contributed to EDK2. As part of GSoC
> 2021, I have submitted a proposal to implement a UEFI audio output
> protocol that will utilize the VirtIO sound driver. I've already
> submitted a draft proposal, and apologize if I've done things out of
> order. This is my first time doing GSoC 2021, and contributing to EDK2
> felt like a really fun thing to do!
>
> I look forward to working with you guys on this and any future projects! :-)
>

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Andrew Fish]

[-- Attachment #1: Type: text/plain, Size: 6491 bytes --]

Ethin I’m not sure what issue you are hitting with VFR? When you built the C build tools it should have built the VFR compiler that matches the code?

Did you run edksetup.bat Rebuild?
> On Mar 31, 2021, at 10:05 PM, Ethin Probst <harlydavidsen@gmail.com> wrote:
> 
> Hello there,
> 
> Some good advice, and thank you! I might add it to the other virtIO*
> drivers if I can figure out a good template for that.
> 
> One thing I'm running into right now is that my build setup is
> currently unable to build MdeModulePkg (which is required to build
> OVMF, according to the readme). I've reported it on the bugzilla; its
> issue 3289. This doesn't appear to occur on Linux, however, which is
> odd.
> 
> Are there any suggestions that you guys have for improving my
> proposal? I didn't want to write too much or go overboard, like
> explaining how the sound driver would work and such, since I assumed
> -- while writing it -- that anyone who wanted to know those inner
> details would go read the VirtIO specification. But I'd appreciate any
> extra feedback before I submit my final version; I haven't made any
> changes since my initial proposal as of yet.
> 
>> On 3/31/21, Nate DeSimone <nathaniel.l.desimone@intel.com> wrote:
>> Another option is to put the protocol definition in MdeModulePkg and mark it
>> with the EDKII_ prefix. For my last “code first” UEFI spec contribution I
>> did this with the PPI that added up getting added.
>> 
>> Thanks,
>> Nate
>> 
>> From: <devel@edk2.groups.io> on behalf of "Andrew Fish via groups.io"
>> <afish=apple.com@groups.io>
>> Reply-To: "devel@edk2.groups.io" <devel@edk2.groups.io>, "afish@apple.com"
>> <afish@apple.com>
>> Date: Tuesday, March 30, 2021 at 10:54 PM
>> To: edk2-devel-groups-io <devel@edk2.groups.io>, "harlydavidsen@gmail.com"
>> <harlydavidsen@gmail.com>
>> Cc: Rafael Rodrigues Machado <rafaelrodrigues.machado@gmail.com>
>> Subject: Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)
>> 
>> 
>> 
>> On Mar 30, 2021, at 5:01 PM, Ethin Probst
>> <harlydavidsen@gmail.com<mailto:harlydavidsen@gmail.com>> wrote:
>> 
>> I'm wondering where exactly I should add the VirtIO sound protocol. I
>> just familiarized myself with the build system and am about to test it
>> by building OVMF if possible, but I'm wondering where I should
>> actually put the protocol and all that stuff. Maybe there's
>> documentation I've missed as well.
>> 
>> Ethin,
>> 
>> For the driver I’d match the patter of OVMF [1] and use
>> OvmfPkg/VirtioSoundDxe/. Maybe even use one of the other drivers as a
>> template.
>> 
>> The protocol is more of a public thing. I think eventually we would like to
>> publish the protocol in the UEFI Spec (I can help with that part) and that
>> would mean we put the Protocol definition in MdePkg/Include/Protocol, but we
>> don’t want to do that before it is standardized as that causes compatibility
>> issues. So this is a “code first project” (code prototype and then
>> contribute to the UEFI Forum for inclusion in the specification) so we need
>> to follow some code first rules that I don’t remember of the top of my head?
>> So why not start out the protocol definition OvmfPkg/Include/Protocol. You
>> can also add a test application looks like you can just use the root [2] of
>> OVMF for that. That way the project is not blocked.
>> 
>> We can have a conversation on the mailing list about better places to put
>> stuff, and it should be easy enough to move stuff around if everything else
>> is working.
>> 
>> [1] find OvmfPkg  -iname '*Virtio*.inf'
>> OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
>> OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
>> OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf
>> OvmfPkg/Library/VirtioLib/VirtioLib.inf
>> OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
>> OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
>> OvmfPkg/Virtio10Dxe/Virtio10.inf
>> OvmfPkg/VirtioNetDxe/VirtioNet.inf
>> OvmfPkg/VirtioRngDxe/VirtioRng.inf
>> 
>> 
>> [2] /Volumes/Case/edk2-github/OvmfPkg>git grep APPLICATION -- *.inf | grep
>> MODULE_TYPE
>> EnrollDefaultKeys/EnrollDefaultKeys.inf:13:  MODULE_TYPE
>> = UEFI_APPLICATION
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
>> 
>> 
>> 
>> On 3/30/21, Ethin Probst via groups.io<http://groups.io/>
>> <harlydavidsen=gmail.com@groups.io<mailto:harlydavidsen=gmail.com@groups.io>>
>> wrote:
>> 
>> I agree. Plus, it gives me a chance to finally learn the EDK2 build
>> system and how it works! I've been working on a hobby OS as a side
>> project and, though learning from other code examples from OSes is
>> fun, I have to say that learning from the firmware code like from
>> SeaBIOS has been some of the most enlightening and interesting times
>> thus far.
>> Thanks for the link to your code, Rafael; once I get virtIO support
>> in, I can work on HDA support, though I might tackle USB support
>> second and HDA third. We'll see, but VirtIO definitely is coming
>> first.
>> 
>> As I said before, I look forward to working with all of you wonderful
>> people!
>> 
>> On 3/30/21, Rafael Rodrigues Machado
>> <rafaelrodrigues.machado@gmail.com<mailto:rafaelrodrigues.machado@gmail.com>>
>> wrote:
>> 
>> This would be amazing so people can continue my work related to
>> accessibility at BIOS. Something desired by the blind people since the
>> 90's
>> Just for reference, this is what I have done:
>> 
>> https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
>> 
>> Thanks
>> Rafael
>> 
>> Em seg, 29 de mar de 2021 20:24, Ethin Probst <harlydavidsen@gmail.com>
>> escreveu:
>> 
>> 
>> Hello everyone,
>> 
>> This is the first time I've ever contributed to EDK2. As part of GSoC
>> 2021, I have submitted a proposal to implement a UEFI audio output
>> protocol that will utilize the VirtIO sound driver. I've already
>> submitted a draft proposal, and apologize if I've done things out of
>> order. This is my first time doing GSoC 2021, and contributing to EDK2
>> felt like a really fun thing to do!
>> 
>> I look forward to working with you guys on this and any future projects!
>> :-)
>> 
>> --
>> Signed,
>> Ethin D. Probst
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> --
>> Signed,
>> Ethin D. Probst
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> --
>> Signed,
>> Ethin D. Probst
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 
> -- 
> Signed,
> Ethin D. Probst

[-- Attachment #2: Type: text/html, Size: 15078 bytes --]

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Ethin Probst]

I can't run edksetup.bat rebuild. The system is set to treat warnings
as errors, and the build tools have warnings within them, and so MSVC
bails out.

On 4/4/21, Andrew Fish via groups.io <afish=apple.com@groups.io> wrote:
> Ethin I’m not sure what issue you are hitting with VFR? When you built the C
> build tools it should have built the VFR compiler that matches the code?
>
> Did you run edksetup.bat Rebuild?
>> On Mar 31, 2021, at 10:05 PM, Ethin Probst <harlydavidsen@gmail.com>
>> wrote:
>>
>> Hello there,
>>
>> Some good advice, and thank you! I might add it to the other virtIO*
>> drivers if I can figure out a good template for that.
>>
>> One thing I'm running into right now is that my build setup is
>> currently unable to build MdeModulePkg (which is required to build
>> OVMF, according to the readme). I've reported it on the bugzilla; its
>> issue 3289. This doesn't appear to occur on Linux, however, which is
>> odd.
>>
>> Are there any suggestions that you guys have for improving my
>> proposal? I didn't want to write too much or go overboard, like
>> explaining how the sound driver would work and such, since I assumed
>> -- while writing it -- that anyone who wanted to know those inner
>> details would go read the VirtIO specification. But I'd appreciate any
>> extra feedback before I submit my final version; I haven't made any
>> changes since my initial proposal as of yet.
>>
>>> On 3/31/21, Nate DeSimone <nathaniel.l.desimone@intel.com> wrote:
>>> Another option is to put the protocol definition in MdeModulePkg and mark
>>> it
>>> with the EDKII_ prefix. For my last “code first” UEFI spec contribution
>>> I
>>> did this with the PPI that added up getting added.
>>>
>>> Thanks,
>>> Nate
>>>
>>> From: <devel@edk2.groups.io> on behalf of "Andrew Fish via groups.io"
>>> <afish=apple.com@groups.io>
>>> Reply-To: "devel@edk2.groups.io" <devel@edk2.groups.io>,
>>> "afish@apple.com"
>>> <afish@apple.com>
>>> Date: Tuesday, March 30, 2021 at 10:54 PM
>>> To: edk2-devel-groups-io <devel@edk2.groups.io>,
>>> "harlydavidsen@gmail.com"
>>> <harlydavidsen@gmail.com>
>>> Cc: Rafael Rodrigues Machado <rafaelrodrigues.machado@gmail.com>
>>> Subject: Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)
>>>
>>>
>>>
>>> On Mar 30, 2021, at 5:01 PM, Ethin Probst
>>> <harlydavidsen@gmail.com<mailto:harlydavidsen@gmail.com>> wrote:
>>>
>>> I'm wondering where exactly I should add the VirtIO sound protocol. I
>>> just familiarized myself with the build system and am about to test it
>>> by building OVMF if possible, but I'm wondering where I should
>>> actually put the protocol and all that stuff. Maybe there's
>>> documentation I've missed as well.
>>>
>>> Ethin,
>>>
>>> For the driver I’d match the patter of OVMF [1] and use
>>> OvmfPkg/VirtioSoundDxe/. Maybe even use one of the other drivers as a
>>> template.
>>>
>>> The protocol is more of a public thing. I think eventually we would like
>>> to
>>> publish the protocol in the UEFI Spec (I can help with that part) and
>>> that
>>> would mean we put the Protocol definition in MdePkg/Include/Protocol, but
>>> we
>>> don’t want to do that before it is standardized as that causes
>>> compatibility
>>> issues. So this is a “code first project” (code prototype and then
>>> contribute to the UEFI Forum for inclusion in the specification) so we
>>> need
>>> to follow some code first rules that I don’t remember of the top of my
>>> head?
>>> So why not start out the protocol definition OvmfPkg/Include/Protocol.
>>> You
>>> can also add a test application looks like you can just use the root [2]
>>> of
>>> OVMF for that. That way the project is not blocked.
>>>
>>> We can have a conversation on the mailing list about better places to
>>> put
>>> stuff, and it should be easy enough to move stuff around if everything
>>> else
>>> is working.
>>>
>>> [1] find OvmfPkg  -iname '*Virtio*.inf'
>>> OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
>>> OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
>>> OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf
>>> OvmfPkg/Library/VirtioLib/VirtioLib.inf
>>> OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
>>> OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
>>> OvmfPkg/Virtio10Dxe/Virtio10.inf
>>> OvmfPkg/VirtioNetDxe/VirtioNet.inf
>>> OvmfPkg/VirtioRngDxe/VirtioRng.inf
>>>
>>>
>>> [2] /Volumes/Case/edk2-github/OvmfPkg>git grep APPLICATION -- *.inf |
>>> grep
>>> MODULE_TYPE
>>> EnrollDefaultKeys/EnrollDefaultKeys.inf:13:  MODULE_TYPE
>>> = UEFI_APPLICATION
>>>
>>> Thanks,
>>>
>>> Andrew Fish
>>>
>>>
>>>
>>>
>>> On 3/30/21, Ethin Probst via groups.io<http://groups.io/>
>>> <harlydavidsen=gmail.com@groups.io<mailto:harlydavidsen=gmail.com@groups.io>>
>>> wrote:
>>>
>>> I agree. Plus, it gives me a chance to finally learn the EDK2 build
>>> system and how it works! I've been working on a hobby OS as a side
>>> project and, though learning from other code examples from OSes is
>>> fun, I have to say that learning from the firmware code like from
>>> SeaBIOS has been some of the most enlightening and interesting times
>>> thus far.
>>> Thanks for the link to your code, Rafael; once I get virtIO support
>>> in, I can work on HDA support, though I might tackle USB support
>>> second and HDA third. We'll see, but VirtIO definitely is coming
>>> first.
>>>
>>> As I said before, I look forward to working with all of you wonderful
>>> people!
>>>
>>> On 3/30/21, Rafael Rodrigues Machado
>>> <rafaelrodrigues.machado@gmail.com<mailto:rafaelrodrigues.machado@gmail.com>>
>>> wrote:
>>>
>>> This would be amazing so people can continue my work related to
>>> accessibility at BIOS. Something desired by the blind people since the
>>> 90's
>>> Just for reference, this is what I have done:
>>>
>>> https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
>>>
>>> Thanks
>>> Rafael
>>>
>>> Em seg, 29 de mar de 2021 20:24, Ethin Probst <harlydavidsen@gmail.com>
>>> escreveu:
>>>
>>>
>>> Hello everyone,
>>>
>>> This is the first time I've ever contributed to EDK2. As part of GSoC
>>> 2021, I have submitted a proposal to implement a UEFI audio output
>>> protocol that will utilize the VirtIO sound driver. I've already
>>> submitted a draft proposal, and apologize if I've done things out of
>>> order. This is my first time doing GSoC 2021, and contributing to EDK2
>>> felt like a really fun thing to do!
>>>
>>> I look forward to working with you guys on this and any future projects!
>>> :-)
>>>
>>> --
>>> Signed,
>>> Ethin D. Probst
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Signed,
>>> Ethin D. Probst
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Signed,
>>> Ethin D. Probst
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Signed,
>> Ethin D. Probst
>
>
> 
>
>
>


-- 
Signed,
Ethin D. Probst

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Andrew Fish]

[-- Attachment #1: Type: text/plain, Size: 7614 bytes --]

CPPFLAGS might be your issue. Assuming VFR is failing. It is one of the only C++ tools.

See the end of:
https://github.com/tianocore/edk2/blob/master/BaseTools/Source/C/Makefiles/ms.common

It would be good to attach this failure to the BZ too
> On Apr 4, 2021, at 9:43 PM, Ethin Probst <harlydavidsen@gmail.com> wrote:
> 
> I can't run edksetup.bat rebuild. The system is set to treat warnings
> as errors, and the build tools have warnings within them, and so MSVC
> bails out.
> 
>> On 4/4/21, Andrew Fish via groups.io <afish=apple.com@groups.io> wrote:
>> Ethin I’m not sure what issue you are hitting with VFR? When you built the C
>> build tools it should have built the VFR compiler that matches the code?
>> 
>> Did you run edksetup.bat Rebuild?
>>> On Mar 31, 2021, at 10:05 PM, Ethin Probst <harlydavidsen@gmail.com>
>>> wrote:
>>> 
>>> Hello there,
>>> 
>>> Some good advice, and thank you! I might add it to the other virtIO*
>>> drivers if I can figure out a good template for that.
>>> 
>>> One thing I'm running into right now is that my build setup is
>>> currently unable to build MdeModulePkg (which is required to build
>>> OVMF, according to the readme). I've reported it on the bugzilla; its
>>> issue 3289. This doesn't appear to occur on Linux, however, which is
>>> odd.
>>> 
>>> Are there any suggestions that you guys have for improving my
>>> proposal? I didn't want to write too much or go overboard, like
>>> explaining how the sound driver would work and such, since I assumed
>>> -- while writing it -- that anyone who wanted to know those inner
>>> details would go read the VirtIO specification. But I'd appreciate any
>>> extra feedback before I submit my final version; I haven't made any
>>> changes since my initial proposal as of yet.
>>> 
>>>> On 3/31/21, Nate DeSimone <nathaniel.l.desimone@intel.com> wrote:
>>>> Another option is to put the protocol definition in MdeModulePkg and mark
>>>> it
>>>> with the EDKII_ prefix. For my last “code first” UEFI spec contribution
>>>> I
>>>> did this with the PPI that added up getting added.
>>>> 
>>>> Thanks,
>>>> Nate
>>>> 
>>>> From: <devel@edk2.groups.io> on behalf of "Andrew Fish via groups.io"
>>>> <afish=apple.com@groups.io>
>>>> Reply-To: "devel@edk2.groups.io" <devel@edk2.groups.io>,
>>>> "afish@apple.com"
>>>> <afish@apple.com>
>>>> Date: Tuesday, March 30, 2021 at 10:54 PM
>>>> To: edk2-devel-groups-io <devel@edk2.groups.io>,
>>>> "harlydavidsen@gmail.com"
>>>> <harlydavidsen@gmail.com>
>>>> Cc: Rafael Rodrigues Machado <rafaelrodrigues.machado@gmail.com>
>>>> Subject: Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)
>>>> 
>>>> 
>>>> 
>>>> On Mar 30, 2021, at 5:01 PM, Ethin Probst
>>>> <harlydavidsen@gmail.com<mailto:harlydavidsen@gmail.com>> wrote:
>>>> 
>>>> I'm wondering where exactly I should add the VirtIO sound protocol. I
>>>> just familiarized myself with the build system and am about to test it
>>>> by building OVMF if possible, but I'm wondering where I should
>>>> actually put the protocol and all that stuff. Maybe there's
>>>> documentation I've missed as well.
>>>> 
>>>> Ethin,
>>>> 
>>>> For the driver I’d match the patter of OVMF [1] and use
>>>> OvmfPkg/VirtioSoundDxe/. Maybe even use one of the other drivers as a
>>>> template.
>>>> 
>>>> The protocol is more of a public thing. I think eventually we would like
>>>> to
>>>> publish the protocol in the UEFI Spec (I can help with that part) and
>>>> that
>>>> would mean we put the Protocol definition in MdePkg/Include/Protocol, but
>>>> we
>>>> don’t want to do that before it is standardized as that causes
>>>> compatibility
>>>> issues. So this is a “code first project” (code prototype and then
>>>> contribute to the UEFI Forum for inclusion in the specification) so we
>>>> need
>>>> to follow some code first rules that I don’t remember of the top of my
>>>> head?
>>>> So why not start out the protocol definition OvmfPkg/Include/Protocol.
>>>> You
>>>> can also add a test application looks like you can just use the root [2]
>>>> of
>>>> OVMF for that. That way the project is not blocked.
>>>> 
>>>> We can have a conversation on the mailing list about better places to
>>>> put
>>>> stuff, and it should be easy enough to move stuff around if everything
>>>> else
>>>> is working.
>>>> 
>>>> [1] find OvmfPkg  -iname '*Virtio*.inf'
>>>> OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
>>>> OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
>>>> OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf
>>>> OvmfPkg/Library/VirtioLib/VirtioLib.inf
>>>> OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
>>>> OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
>>>> OvmfPkg/Virtio10Dxe/Virtio10.inf
>>>> OvmfPkg/VirtioNetDxe/VirtioNet.inf
>>>> OvmfPkg/VirtioRngDxe/VirtioRng.inf
>>>> 
>>>> 
>>>> [2] /Volumes/Case/edk2-github/OvmfPkg>git grep APPLICATION -- *.inf |
>>>> grep
>>>> MODULE_TYPE
>>>> EnrollDefaultKeys/EnrollDefaultKeys.inf:13:  MODULE_TYPE
>>>> = UEFI_APPLICATION
>>>> 
>>>> Thanks,
>>>> 
>>>> Andrew Fish
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On 3/30/21, Ethin Probst via groups.io<http://groups.io/>
>>>> <harlydavidsen=gmail.com@groups.io<mailto:harlydavidsen=gmail.com@groups.io>>
>>>> wrote:
>>>> 
>>>> I agree. Plus, it gives me a chance to finally learn the EDK2 build
>>>> system and how it works! I've been working on a hobby OS as a side
>>>> project and, though learning from other code examples from OSes is
>>>> fun, I have to say that learning from the firmware code like from
>>>> SeaBIOS has been some of the most enlightening and interesting times
>>>> thus far.
>>>> Thanks for the link to your code, Rafael; once I get virtIO support
>>>> in, I can work on HDA support, though I might tackle USB support
>>>> second and HDA third. We'll see, but VirtIO definitely is coming
>>>> first.
>>>> 
>>>> As I said before, I look forward to working with all of you wonderful
>>>> people!
>>>> 
>>>> On 3/30/21, Rafael Rodrigues Machado
>>>> <rafaelrodrigues.machado@gmail.com<mailto:rafaelrodrigues.machado@gmail.com>>
>>>> wrote:
>>>> 
>>>> This would be amazing so people can continue my work related to
>>>> accessibility at BIOS. Something desired by the blind people since the
>>>> 90's
>>>> Just for reference, this is what I have done:
>>>> 
>>>> https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
>>>> 
>>>> Thanks
>>>> Rafael
>>>> 
>>>> Em seg, 29 de mar de 2021 20:24, Ethin Probst <harlydavidsen@gmail.com>
>>>> escreveu:
>>>> 
>>>> 
>>>> Hello everyone,
>>>> 
>>>> This is the first time I've ever contributed to EDK2. As part of GSoC
>>>> 2021, I have submitted a proposal to implement a UEFI audio output
>>>> protocol that will utilize the VirtIO sound driver. I've already
>>>> submitted a draft proposal, and apologize if I've done things out of
>>>> order. This is my first time doing GSoC 2021, and contributing to EDK2
>>>> felt like a really fun thing to do!
>>>> 
>>>> I look forward to working with you guys on this and any future projects!
>>>> :-)
>>>> 
>>>> --
>>>> Signed,
>>>> Ethin D. Probst
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Signed,
>>>> Ethin D. Probst
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Signed,
>>>> Ethin D. Probst
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> Signed,
>>> Ethin D. Probst
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 
> -- 
> Signed,
> Ethin D. Probst

[-- Attachment #2: Type: text/html, Size: 31874 bytes --]

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Laszlo Ersek]

On 03/31/21 08:41, Nate DeSimone wrote:
> Another option is to put the protocol definition in MdeModulePkg and
> mark it with the EDKII_ prefix. For my last “code first” UEFI spec
> contribution I did this with the PPI that added up getting added.

The new audio protocol should be generic, only its implementation in
question should be virtio specific.

Please include Gerd Hoffmann (CC'd) in the protocol design, as well as
the developers of the virtio-sound device model in QEMU.

Thanks
Laszlo


> 
>  
> 
> Thanks,
> 
> Nate
> 
>  
> 
> *From: *<devel@edk2.groups.io> on behalf of "Andrew Fish via groups.io"
> <afish=apple.com@groups.io>
> *Reply-To: *"devel@edk2.groups.io" <devel@edk2.groups.io>,
> "afish@apple.com" <afish@apple.com>
> *Date: *Tuesday, March 30, 2021 at 10:54 PM
> *To: *edk2-devel-groups-io <devel@edk2.groups.io>,
> "harlydavidsen@gmail.com" <harlydavidsen@gmail.com>
> *Cc: *Rafael Rodrigues Machado <rafaelrodrigues.machado@gmail.com>
> *Subject: *Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)
> 
>  
> 
> 
> 
>     On Mar 30, 2021, at 5:01 PM, Ethin Probst <harlydavidsen@gmail.com
>     <mailto:harlydavidsen@gmail.com>> wrote:
> 
>      
> 
>     I'm wondering where exactly I should add the VirtIO sound protocol. I
>     just familiarized myself with the build system and am about to test it
>     by building OVMF if possible, but I'm wondering where I should
>     actually put the protocol and all that stuff. Maybe there's
>     documentation I've missed as well.
> 
>  
> 
> Ethin,
> 
>  
> 
> For the driver I’d match the patter of OVMF [1] and use
> OvmfPkg/VirtioSoundDxe/. Maybe even use one of the other drivers as a
> template. 
> 
>  
> 
> The protocol is more of a public thing. I think eventually we would like
> to publish the protocol in the UEFI Spec (I can help with that part) and
> that would mean we put the Protocol definition in
> MdePkg/Include/Protocol, but we don’t want to do that before it is
> standardized as that causes compatibility issues. So this is a “code
> first project” (code prototype and then contribute to the UEFI Forum for
> inclusion in the specification) so we need to follow some code first
> rules that I don’t remember of the top of my head? So why not start out
> the protocol definition OvmfPkg/Include/Protocol. You can also add a
> test application looks like you can just use the root [2] of OVMF for
> that. That way the project is not blocked. 
> 
>  
> 
> We can have a conversation on the mailing list about better places to
> put stuff, and it should be easy enough to move stuff around if
> everything else is working.  
> 
>  
> 
> [1] find OvmfPkg  -iname '*Virtio*.inf'
> 
> OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
> 
> OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
> 
> OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf
> 
> OvmfPkg/Library/VirtioLib/VirtioLib.inf
> 
> OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
> 
> OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
> 
> OvmfPkg/Virtio10Dxe/Virtio10.inf
> 
> OvmfPkg/VirtioNetDxe/VirtioNet.inf
> 
> OvmfPkg/VirtioRngDxe/VirtioRng.inf
> 
> 
> 
> [2] /Volumes/Case/edk2-github/OvmfPkg>git grep APPLICATION -- *.inf |
> grep MODULE_TYPE
> 
> EnrollDefaultKeys/EnrollDefaultKeys.inf:13:  MODULE_TYPE               
>     = UEFI_APPLICATION
> 
>  
> 
> Thanks,
> 
>  
> 
> Andrew Fish
> 
>  
> 
> 
> 
> 
>     On 3/30/21, Ethin Probst via groups.io <http://groups.io/>
>     <harlydavidsen=gmail.com@groups.io
>     <mailto:harlydavidsen=gmail.com@groups.io>> wrote:
> 
>         I agree. Plus, it gives me a chance to finally learn the EDK2 build
>         system and how it works! I've been working on a hobby OS as a side
>         project and, though learning from other code examples from OSes is
>         fun, I have to say that learning from the firmware code like from
>         SeaBIOS has been some of the most enlightening and interesting times
>         thus far.
>         Thanks for the link to your code, Rafael; once I get virtIO support
>         in, I can work on HDA support, though I might tackle USB support
>         second and HDA third. We'll see, but VirtIO definitely is coming
>         first.
> 
>         As I said before, I look forward to working with all of you
>         wonderful
>         people!
> 
>         On 3/30/21, Rafael Rodrigues Machado
>         <rafaelrodrigues.machado@gmail.com
>         <mailto:rafaelrodrigues.machado@gmail.com>>
>         wrote:
> 
>             This would be amazing so people can continue my work related to
>             accessibility at BIOS. Something desired by the blind people
>             since the
>             90's
>             Just for reference, this is what I have done:
> 
>             https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
> 
>             Thanks
>             Rafael
> 
>             Em seg, 29 de mar de 2021 20:24, Ethin Probst
>             <harlydavidsen@gmail.com>
>             escreveu:
> 
> 
>                 Hello everyone,
> 
>                 This is the first time I've ever contributed to EDK2. As
>                 part of GSoC
>                 2021, I have submitted a proposal to implement a UEFI
>                 audio output
>                 protocol that will utilize the VirtIO sound driver. I've
>                 already
>                 submitted a draft proposal, and apologize if I've done
>                 things out of
>                 order. This is my first time doing GSoC 2021, and
>                 contributing to EDK2
>                 felt like a really fun thing to do!
> 
>                 I look forward to working with you guys on this and any
>                 future projects!
>                 :-)
> 
>                 --
>                 Signed,
>                 Ethin D. Probst
> 
> 
> 
> 
> 
>              
> 
> 
> 
>         --
>         Signed,
>         Ethin D. Probst
> 
> 
> 
> 
> 
> 
> 
>     -- 
>     Signed,
>     Ethin D. Probst
> 
> 
> 
>  
> 
> 

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Ethin Probst]

I'll attach the bug for the build tools to the BZ shortly.
Laszlo, thanks for that. I don't know their email addresses though.
And yes, I was going to make it device independent, as the majority
(if not all) of UEFI protocols are.

On 4/6/21, Laszlo Ersek <lersek@redhat.com> wrote:
> On 03/31/21 08:41, Nate DeSimone wrote:
>> Another option is to put the protocol definition in MdeModulePkg and
>> mark it with the EDKII_ prefix. For my last “code first” UEFI spec
>> contribution I did this with the PPI that added up getting added.
>
> The new audio protocol should be generic, only its implementation in
> question should be virtio specific.
>
> Please include Gerd Hoffmann (CC'd) in the protocol design, as well as
> the developers of the virtio-sound device model in QEMU.
>
> Thanks
> Laszlo
>
>
>>
>>
>>
>> Thanks,
>>
>> Nate
>>
>>
>>
>> *From: *<devel@edk2.groups.io> on behalf of "Andrew Fish via groups.io"
>> <afish=apple.com@groups.io>
>> *Reply-To: *"devel@edk2.groups.io" <devel@edk2.groups.io>,
>> "afish@apple.com" <afish@apple.com>
>> *Date: *Tuesday, March 30, 2021 at 10:54 PM
>> *To: *edk2-devel-groups-io <devel@edk2.groups.io>,
>> "harlydavidsen@gmail.com" <harlydavidsen@gmail.com>
>> *Cc: *Rafael Rodrigues Machado <rafaelrodrigues.machado@gmail.com>
>> *Subject: *Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)
>>
>>
>>
>>
>>
>>     On Mar 30, 2021, at 5:01 PM, Ethin Probst <harlydavidsen@gmail.com
>>     <mailto:harlydavidsen@gmail.com>> wrote:
>>
>>
>>
>>     I'm wondering where exactly I should add the VirtIO sound protocol. I
>>     just familiarized myself with the build system and am about to test
>> it
>>     by building OVMF if possible, but I'm wondering where I should
>>     actually put the protocol and all that stuff. Maybe there's
>>     documentation I've missed as well.
>>
>>
>>
>> Ethin,
>>
>>
>>
>> For the driver I’d match the patter of OVMF [1] and use
>> OvmfPkg/VirtioSoundDxe/. Maybe even use one of the other drivers as a
>> template.
>>
>>
>>
>> The protocol is more of a public thing. I think eventually we would like
>> to publish the protocol in the UEFI Spec (I can help with that part) and
>> that would mean we put the Protocol definition in
>> MdePkg/Include/Protocol, but we don’t want to do that before it is
>> standardized as that causes compatibility issues. So this is a “code
>> first project” (code prototype and then contribute to the UEFI Forum for
>> inclusion in the specification) so we need to follow some code first
>> rules that I don’t remember of the top of my head? So why not start out
>> the protocol definition OvmfPkg/Include/Protocol. You can also add a
>> test application looks like you can just use the root [2] of OVMF for
>> that. That way the project is not blocked.
>>
>>
>>
>> We can have a conversation on the mailing list about better places to
>> put stuff, and it should be easy enough to move stuff around if
>> everything else is working.
>>
>>
>>
>> [1] find OvmfPkg  -iname '*Virtio*.inf'
>>
>> OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
>>
>> OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
>>
>> OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf
>>
>> OvmfPkg/Library/VirtioLib/VirtioLib.inf
>>
>> OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
>>
>> OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
>>
>> OvmfPkg/Virtio10Dxe/Virtio10.inf
>>
>> OvmfPkg/VirtioNetDxe/VirtioNet.inf
>>
>> OvmfPkg/VirtioRngDxe/VirtioRng.inf
>>
>>
>>
>> [2] /Volumes/Case/edk2-github/OvmfPkg>git grep APPLICATION -- *.inf |
>> grep MODULE_TYPE
>>
>> EnrollDefaultKeys/EnrollDefaultKeys.inf:13:  MODULE_TYPE
>>     = UEFI_APPLICATION
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Andrew Fish
>>
>>
>>
>>
>>
>>
>>     On 3/30/21, Ethin Probst via groups.io <http://groups.io/>
>>     <harlydavidsen=gmail.com@groups.io
>>     <mailto:harlydavidsen=gmail.com@groups.io>> wrote:
>>
>>         I agree. Plus, it gives me a chance to finally learn the EDK2
>> build
>>         system and how it works! I've been working on a hobby OS as a
>> side
>>         project and, though learning from other code examples from OSes
>> is
>>         fun, I have to say that learning from the firmware code like from
>>         SeaBIOS has been some of the most enlightening and interesting
>> times
>>         thus far.
>>         Thanks for the link to your code, Rafael; once I get virtIO
>> support
>>         in, I can work on HDA support, though I might tackle USB support
>>         second and HDA third. We'll see, but VirtIO definitely is coming
>>         first.
>>
>>         As I said before, I look forward to working with all of you
>>         wonderful
>>         people!
>>
>>         On 3/30/21, Rafael Rodrigues Machado
>>         <rafaelrodrigues.machado@gmail.com
>>         <mailto:rafaelrodrigues.machado@gmail.com>>
>>         wrote:
>>
>>             This would be amazing so people can continue my work related
>> to
>>             accessibility at BIOS. Something desired by the blind people
>>             since the
>>             90's
>>             Just for reference, this is what I have done:
>>
>>
>> https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
>>
>>             Thanks
>>             Rafael
>>
>>             Em seg, 29 de mar de 2021 20:24, Ethin Probst
>>             <harlydavidsen@gmail.com>
>>             escreveu:
>>
>>
>>                 Hello everyone,
>>
>>                 This is the first time I've ever contributed to EDK2. As
>>                 part of GSoC
>>                 2021, I have submitted a proposal to implement a UEFI
>>                 audio output
>>                 protocol that will utilize the VirtIO sound driver. I've
>>                 already
>>                 submitted a draft proposal, and apologize if I've done
>>                 things out of
>>                 order. This is my first time doing GSoC 2021, and
>>                 contributing to EDK2
>>                 felt like a really fun thing to do!
>>
>>                 I look forward to working with you guys on this and any
>>                 future projects!
>>                 :-)
>>
>>                 --
>>                 Signed,
>>                 Ethin D. Probst
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>         --
>>         Signed,
>>         Ethin D. Probst
>>
>>
>>
>>
>>
>>
>>
>>     --
>>     Signed,
>>     Ethin D. Probst
>>
>>
>>
>>
>>
>> 
>
>


-- 
Signed,
Ethin D. Probst

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Leif Lindholm]

[-- Attachment #1: Type: text/plain, Size: 7508 bytes --]

Hi all, especially Ethin.

Apologies for radio silence - last week I was off on holiday, and before
that ... let's just say corporate acquisitions generate some distractions.
Anyway, I'm back, and since I'm down as the mentor for this task, feel free
to spam me with any remaining/new questions.

/
    Leif

On Tue, Apr 6, 2021 at 4:17 PM Ethin Probst <harlydavidsen@gmail.com> wrote:

> I'll attach the bug for the build tools to the BZ shortly.
> Laszlo, thanks for that. I don't know their email addresses though.
> And yes, I was going to make it device independent, as the majority
> (if not all) of UEFI protocols are.
>
> On 4/6/21, Laszlo Ersek <lersek@redhat.com> wrote:
> > On 03/31/21 08:41, Nate DeSimone wrote:
> >> Another option is to put the protocol definition in MdeModulePkg and
> >> mark it with the EDKII_ prefix. For my last “code first” UEFI spec
> >> contribution I did this with the PPI that added up getting added.
> >
> > The new audio protocol should be generic, only its implementation in
> > question should be virtio specific.
> >
> > Please include Gerd Hoffmann (CC'd) in the protocol design, as well as
> > the developers of the virtio-sound device model in QEMU.
> >
> > Thanks
> > Laszlo
> >
> >
> >>
> >>
> >>
> >> Thanks,
> >>
> >> Nate
> >>
> >>
> >>
> >> *From: *<devel@edk2.groups.io> on behalf of "Andrew Fish via groups.io"
> >> <afish=apple.com@groups.io>
> >> *Reply-To: *"devel@edk2.groups.io" <devel@edk2.groups.io>,
> >> "afish@apple.com" <afish@apple.com>
> >> *Date: *Tuesday, March 30, 2021 at 10:54 PM
> >> *To: *edk2-devel-groups-io <devel@edk2.groups.io>,
> >> "harlydavidsen@gmail.com" <harlydavidsen@gmail.com>
> >> *Cc: *Rafael Rodrigues Machado <rafaelrodrigues.machado@gmail.com>
> >> *Subject: *Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)
> >>
> >>
> >>
> >>
> >>
> >>     On Mar 30, 2021, at 5:01 PM, Ethin Probst <harlydavidsen@gmail.com
> >>     <mailto:harlydavidsen@gmail.com>> wrote:
> >>
> >>
> >>
> >>     I'm wondering where exactly I should add the VirtIO sound protocol.
> I
> >>     just familiarized myself with the build system and am about to test
> >> it
> >>     by building OVMF if possible, but I'm wondering where I should
> >>     actually put the protocol and all that stuff. Maybe there's
> >>     documentation I've missed as well.
> >>
> >>
> >>
> >> Ethin,
> >>
> >>
> >>
> >> For the driver I’d match the patter of OVMF [1] and use
> >> OvmfPkg/VirtioSoundDxe/. Maybe even use one of the other drivers as a
> >> template.
> >>
> >>
> >>
> >> The protocol is more of a public thing. I think eventually we would like
> >> to publish the protocol in the UEFI Spec (I can help with that part) and
> >> that would mean we put the Protocol definition in
> >> MdePkg/Include/Protocol, but we don’t want to do that before it is
> >> standardized as that causes compatibility issues. So this is a “code
> >> first project” (code prototype and then contribute to the UEFI Forum for
> >> inclusion in the specification) so we need to follow some code first
> >> rules that I don’t remember of the top of my head? So why not start out
> >> the protocol definition OvmfPkg/Include/Protocol. You can also add a
> >> test application looks like you can just use the root [2] of OVMF for
> >> that. That way the project is not blocked.
> >>
> >>
> >>
> >> We can have a conversation on the mailing list about better places to
> >> put stuff, and it should be easy enough to move stuff around if
> >> everything else is working.
> >>
> >>
> >>
> >> [1] find OvmfPkg  -iname '*Virtio*.inf'
> >>
> >> OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
> >>
> >> OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
> >>
> >> OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf
> >>
> >> OvmfPkg/Library/VirtioLib/VirtioLib.inf
> >>
> >> OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
> >>
> >> OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
> >>
> >> OvmfPkg/Virtio10Dxe/Virtio10.inf
> >>
> >> OvmfPkg/VirtioNetDxe/VirtioNet.inf
> >>
> >> OvmfPkg/VirtioRngDxe/VirtioRng.inf
> >>
> >>
> >>
> >> [2] /Volumes/Case/edk2-github/OvmfPkg>git grep APPLICATION -- *.inf |
> >> grep MODULE_TYPE
> >>
> >> EnrollDefaultKeys/EnrollDefaultKeys.inf:13:  MODULE_TYPE
> >>     = UEFI_APPLICATION
> >>
> >>
> >>
> >> Thanks,
> >>
> >>
> >>
> >> Andrew Fish
> >>
> >>
> >>
> >>
> >>
> >>
> >>     On 3/30/21, Ethin Probst via groups.io <http://groups.io/>
> >>     <harlydavidsen=gmail.com@groups.io
> >>     <mailto:harlydavidsen=gmail.com@groups.io>> wrote:
> >>
> >>         I agree. Plus, it gives me a chance to finally learn the EDK2
> >> build
> >>         system and how it works! I've been working on a hobby OS as a
> >> side
> >>         project and, though learning from other code examples from OSes
> >> is
> >>         fun, I have to say that learning from the firmware code like
> from
> >>         SeaBIOS has been some of the most enlightening and interesting
> >> times
> >>         thus far.
> >>         Thanks for the link to your code, Rafael; once I get virtIO
> >> support
> >>         in, I can work on HDA support, though I might tackle USB support
> >>         second and HDA third. We'll see, but VirtIO definitely is coming
> >>         first.
> >>
> >>         As I said before, I look forward to working with all of you
> >>         wonderful
> >>         people!
> >>
> >>         On 3/30/21, Rafael Rodrigues Machado
> >>         <rafaelrodrigues.machado@gmail.com
> >>         <mailto:rafaelrodrigues.machado@gmail.com>>
> >>         wrote:
> >>
> >>             This would be amazing so people can continue my work related
> >> to
> >>             accessibility at BIOS. Something desired by the blind people
> >>             since the
> >>             90's
> >>             Just for reference, this is what I have done:
> >>
> >>
> >> https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
> >>
> >>             Thanks
> >>             Rafael
> >>
> >>             Em seg, 29 de mar de 2021 20:24, Ethin Probst
> >>             <harlydavidsen@gmail.com>
> >>             escreveu:
> >>
> >>
> >>                 Hello everyone,
> >>
> >>                 This is the first time I've ever contributed to EDK2. As
> >>                 part of GSoC
> >>                 2021, I have submitted a proposal to implement a UEFI
> >>                 audio output
> >>                 protocol that will utilize the VirtIO sound driver. I've
> >>                 already
> >>                 submitted a draft proposal, and apologize if I've done
> >>                 things out of
> >>                 order. This is my first time doing GSoC 2021, and
> >>                 contributing to EDK2
> >>                 felt like a really fun thing to do!
> >>
> >>                 I look forward to working with you guys on this and any
> >>                 future projects!
> >>                 :-)
> >>
> >>                 --
> >>                 Signed,
> >>                 Ethin D. Probst
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>         --
> >>         Signed,
> >>         Ethin D. Probst
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>     --
> >>     Signed,
> >>     Ethin D. Probst
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
>
>
> --
> Signed,
> Ethin D. Probst
>
>
> 
>
>
>

[-- Attachment #2: Type: text/html, Size: 11651 bytes --]

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Andrew Fish]

[-- Attachment #1: Type: text/plain, Size: 8814 bytes --]

Leif,

Since I have put some brain cells around this area in the past I can be the backup and help out too. 

I’d also point out if you are having issues building or have general questions on how things work it is fine to use the mailing list. I’ve got a lot of feedback that folks read or search the mailing list looking for answer to their questions so one person asking can help out a lot of other people. 

Thanks,

Andrew Fish

> On Apr 13, 2021, at 5:28 AM, Leif Lindholm <leif@nuviainc.com> wrote:
> 
> Hi all, especially Ethin.
> 
> Apologies for radio silence - last week I was off on holiday, and before that ... let's just say corporate acquisitions generate some distractions.
> Anyway, I'm back, and since I'm down as the mentor for this task, feel free to spam me with any remaining/new questions.
> 
> /
>     Leif
> 
> On Tue, Apr 6, 2021 at 4:17 PM Ethin Probst <harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>> wrote:
> I'll attach the bug for the build tools to the BZ shortly.
> Laszlo, thanks for that. I don't know their email addresses though.
> And yes, I was going to make it device independent, as the majority
> (if not all) of UEFI protocols are.
> 
> On 4/6/21, Laszlo Ersek <lersek@redhat.com <mailto:lersek@redhat.com>> wrote:
> > On 03/31/21 08:41, Nate DeSimone wrote:
> >> Another option is to put the protocol definition in MdeModulePkg and
> >> mark it with the EDKII_ prefix. For my last “code first” UEFI spec
> >> contribution I did this with the PPI that added up getting added.
> >
> > The new audio protocol should be generic, only its implementation in
> > question should be virtio specific.
> >
> > Please include Gerd Hoffmann (CC'd) in the protocol design, as well as
> > the developers of the virtio-sound device model in QEMU.
> >
> > Thanks
> > Laszlo
> >
> >
> >>
> >>
> >>
> >> Thanks,
> >>
> >> Nate
> >>
> >>
> >>
> >> *From: *<devel@edk2.groups.io <mailto:devel@edk2.groups.io>> on behalf of "Andrew Fish via groups.io <http://groups.io/>"
> >> <afish=apple.com@groups.io <mailto:apple.com@groups.io>>
> >> *Reply-To: *"devel@edk2.groups.io <mailto:devel@edk2.groups.io>" <devel@edk2.groups.io <mailto:devel@edk2.groups.io>>,
> >> "afish@apple.com <mailto:afish@apple.com>" <afish@apple.com <mailto:afish@apple.com>>
> >> *Date: *Tuesday, March 30, 2021 at 10:54 PM
> >> *To: *edk2-devel-groups-io <devel@edk2.groups.io <mailto:devel@edk2.groups.io>>,
> >> "harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>" <harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
> >> *Cc: *Rafael Rodrigues Machado <rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>>
> >> *Subject: *Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)
> >>
> >>
> >>
> >>
> >>
> >>     On Mar 30, 2021, at 5:01 PM, Ethin Probst <harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
> >>     <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>> wrote:
> >>
> >>
> >>
> >>     I'm wondering where exactly I should add the VirtIO sound protocol. I
> >>     just familiarized myself with the build system and am about to test
> >> it
> >>     by building OVMF if possible, but I'm wondering where I should
> >>     actually put the protocol and all that stuff. Maybe there's
> >>     documentation I've missed as well.
> >>
> >>
> >>
> >> Ethin,
> >>
> >>
> >>
> >> For the driver I’d match the patter of OVMF [1] and use
> >> OvmfPkg/VirtioSoundDxe/. Maybe even use one of the other drivers as a
> >> template.
> >>
> >>
> >>
> >> The protocol is more of a public thing. I think eventually we would like
> >> to publish the protocol in the UEFI Spec (I can help with that part) and
> >> that would mean we put the Protocol definition in
> >> MdePkg/Include/Protocol, but we don’t want to do that before it is
> >> standardized as that causes compatibility issues. So this is a “code
> >> first project” (code prototype and then contribute to the UEFI Forum for
> >> inclusion in the specification) so we need to follow some code first
> >> rules that I don’t remember of the top of my head? So why not start out
> >> the protocol definition OvmfPkg/Include/Protocol. You can also add a
> >> test application looks like you can just use the root [2] of OVMF for
> >> that. That way the project is not blocked.
> >>
> >>
> >>
> >> We can have a conversation on the mailing list about better places to
> >> put stuff, and it should be easy enough to move stuff around if
> >> everything else is working.
> >>
> >>
> >>
> >> [1] find OvmfPkg  -iname '*Virtio*.inf'
> >>
> >> OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
> >>
> >> OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
> >>
> >> OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf
> >>
> >> OvmfPkg/Library/VirtioLib/VirtioLib.inf
> >>
> >> OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
> >>
> >> OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
> >>
> >> OvmfPkg/Virtio10Dxe/Virtio10.inf
> >>
> >> OvmfPkg/VirtioNetDxe/VirtioNet.inf
> >>
> >> OvmfPkg/VirtioRngDxe/VirtioRng.inf
> >>
> >>
> >>
> >> [2] /Volumes/Case/edk2-github/OvmfPkg>git grep APPLICATION -- *.inf |
> >> grep MODULE_TYPE
> >>
> >> EnrollDefaultKeys/EnrollDefaultKeys.inf:13:  MODULE_TYPE
> >>     = UEFI_APPLICATION
> >>
> >>
> >>
> >> Thanks,
> >>
> >>
> >>
> >> Andrew Fish
> >>
> >>
> >>
> >>
> >>
> >>
> >>     On 3/30/21, Ethin Probst via groups.io <http://groups.io/> <http://groups.io/ <http://groups.io/>>
> >>     <harlydavidsen=gmail.com@groups.io <mailto:gmail.com@groups.io>
> >>     <mailto:harlydavidsen <mailto:harlydavidsen>=gmail.com@groups.io <mailto:gmail.com@groups.io>>> wrote:
> >>
> >>         I agree. Plus, it gives me a chance to finally learn the EDK2
> >> build
> >>         system and how it works! I've been working on a hobby OS as a
> >> side
> >>         project and, though learning from other code examples from OSes
> >> is
> >>         fun, I have to say that learning from the firmware code like from
> >>         SeaBIOS has been some of the most enlightening and interesting
> >> times
> >>         thus far.
> >>         Thanks for the link to your code, Rafael; once I get virtIO
> >> support
> >>         in, I can work on HDA support, though I might tackle USB support
> >>         second and HDA third. We'll see, but VirtIO definitely is coming
> >>         first.
> >>
> >>         As I said before, I look forward to working with all of you
> >>         wonderful
> >>         people!
> >>
> >>         On 3/30/21, Rafael Rodrigues Machado
> >>         <rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>
> >>         <mailto:rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>>>
> >>         wrote:
> >>
> >>             This would be amazing so people can continue my work related
> >> to
> >>             accessibility at BIOS. Something desired by the blind people
> >>             since the
> >>             90's
> >>             Just for reference, this is what I have done:
> >>
> >>
> >> https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>
> >>
> >>             Thanks
> >>             Rafael
> >>
> >>             Em seg, 29 de mar de 2021 20:24, Ethin Probst
> >>             <harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
> >>             escreveu:
> >>
> >>
> >>                 Hello everyone,
> >>
> >>                 This is the first time I've ever contributed to EDK2. As
> >>                 part of GSoC
> >>                 2021, I have submitted a proposal to implement a UEFI
> >>                 audio output
> >>                 protocol that will utilize the VirtIO sound driver. I've
> >>                 already
> >>                 submitted a draft proposal, and apologize if I've done
> >>                 things out of
> >>                 order. This is my first time doing GSoC 2021, and
> >>                 contributing to EDK2
> >>                 felt like a really fun thing to do!
> >>
> >>                 I look forward to working with you guys on this and any
> >>                 future projects!
> >>                 :-)
> >>
> >>                 --
> >>                 Signed,
> >>                 Ethin D. Probst
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>         --
> >>         Signed,
> >>         Ethin D. Probst
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>     --
> >>     Signed,
> >>     Ethin D. Probst
> >>
> >>
> >>
> >>
> >>
> >> 
> >
> >
> 
> 
> -- 
> Signed,
> Ethin D. Probst
> 
> 
> 
> 
> 
> 


[-- Attachment #2: Type: text/html, Size: 17497 bytes --]

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Ethin Probst]

Would it be possible for us to conduct discussion on the UEFI talkbox?
I don't mind using email, but things could definitely get moving
quicker over there (though its not a requirement obviously).

Here's how I generally envision the driver functioning:

1. Firmware/platform code calls InitaudioOutput() or something like
it. This function scans the PCIe bus and scans for one of the
following:
- Vendor ID 0x1AF4, device ID 0x1059: VirtIO sound device
- PCI class 0x0C, subclass 0x03, program interface 0x30 or 0x40: for
USB audio interface (I'm only thinking of targeting XHCI and USB 4,
and not UHCI, OHCI or EHCI). But maybe EDK2 will take that out of my
hands. If so, it will make things easier.
- For USB audio devices I'm not quite sure what to look for; I'm
definitely unused to USB.
2. If any of the above cases are found, appropriate driver
initialization occurs. Since for the time being I am solely focusing
on VirtIO sound devices, the VirtIO general initialization sequence
will occur as outlined in sec. 3 of the VirtIO specification available
at https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html.
As for actual protocol exposure that would be spec-worthy, for
EFI_AUDIO_OUTPUT_PROTOCOL, I'm not quite sure what to expose. VirtIO
is rather simple: there's a buffer for sending and receiving audio
data in PCM streams. So for that we could expose a Reset(),
RemapJack(), GetJackConfig(), GetPcmConfig(), SetPcmParams(),
Prepare(), Release(), Start(), and Stop() function for the
corresponding request types VIRTIO_SND_R_JACK_GET_CONFIG,
VIRTIO_SND_R_JACK_REMAP, VIRTIO_SND_R_PCM_GET_CONFIG,
VIRTIO_SND_R_PCM_SET_PARAMS, VIRTIO_SND_R_PCM_PREPARE,
VIRTIO_SND_R_PCM_RELEASE, VIRTIO_SND_R_PCM_START, and
VIRTIO_SND_R_PCM_STOP control requests. However, for HDA things are a
lot more complex, so I'm not sure how that should work.
For VirtIO -- which is what I'll focus on for now -- everything is
described, in excellent detail, in sec. 5.14 of the above-linked
document. What are your guys's thoughts thus far and how should
everything be mapped to UEFI interfaces?

On 4/13/21, Andrew Fish <afish@apple.com> wrote:
> Leif,
>
> Since I have put some brain cells around this area in the past I can be the
> backup and help out too.
>
> I’d also point out if you are having issues building or have general
> questions on how things work it is fine to use the mailing list. I’ve got a
> lot of feedback that folks read or search the mailing list looking for
> answer to their questions so one person asking can help out a lot of other
> people.
>
> Thanks,
>
> Andrew Fish
>
>> On Apr 13, 2021, at 5:28 AM, Leif Lindholm <leif@nuviainc.com> wrote:
>>
>> Hi all, especially Ethin.
>>
>> Apologies for radio silence - last week I was off on holiday, and before
>> that ... let's just say corporate acquisitions generate some
>> distractions.
>> Anyway, I'm back, and since I'm down as the mentor for this task, feel
>> free to spam me with any remaining/new questions.
>>
>> /
>>     Leif
>>
>> On Tue, Apr 6, 2021 at 4:17 PM Ethin Probst <harlydavidsen@gmail.com
>> <mailto:harlydavidsen@gmail.com>> wrote:
>> I'll attach the bug for the build tools to the BZ shortly.
>> Laszlo, thanks for that. I don't know their email addresses though.
>> And yes, I was going to make it device independent, as the majority
>> (if not all) of UEFI protocols are.
>>
>> On 4/6/21, Laszlo Ersek <lersek@redhat.com <mailto:lersek@redhat.com>>
>> wrote:
>> > On 03/31/21 08:41, Nate DeSimone wrote:
>> >> Another option is to put the protocol definition in MdeModulePkg and
>> >> mark it with the EDKII_ prefix. For my last “code first” UEFI spec
>> >> contribution I did this with the PPI that added up getting added.
>> >
>> > The new audio protocol should be generic, only its implementation in
>> > question should be virtio specific.
>> >
>> > Please include Gerd Hoffmann (CC'd) in the protocol design, as well as
>> > the developers of the virtio-sound device model in QEMU.
>> >
>> > Thanks
>> > Laszlo
>> >
>> >
>> >>
>> >>
>> >>
>> >> Thanks,
>> >>
>> >> Nate
>> >>
>> >>
>> >>
>> >> *From: *<devel@edk2.groups.io <mailto:devel@edk2.groups.io>> on behalf
>> >> of "Andrew Fish via groups.io <http://groups.io/>"
>> >> <afish=apple.com@groups.io <mailto:apple.com@groups.io>>
>> >> *Reply-To: *"devel@edk2.groups.io <mailto:devel@edk2.groups.io>"
>> >> <devel@edk2.groups.io <mailto:devel@edk2.groups.io>>,
>> >> "afish@apple.com <mailto:afish@apple.com>" <afish@apple.com
>> >> <mailto:afish@apple.com>>
>> >> *Date: *Tuesday, March 30, 2021 at 10:54 PM
>> >> *To: *edk2-devel-groups-io <devel@edk2.groups.io
>> >> <mailto:devel@edk2.groups.io>>,
>> >> "harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>"
>> >> <harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
>> >> *Cc: *Rafael Rodrigues Machado <rafaelrodrigues.machado@gmail.com
>> >> <mailto:rafaelrodrigues.machado@gmail.com>>
>> >> *Subject: *Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>     On Mar 30, 2021, at 5:01 PM, Ethin Probst <harlydavidsen@gmail.com
>> >> <mailto:harlydavidsen@gmail.com>
>> >>     <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>
>> >> wrote:
>> >>
>> >>
>> >>
>> >>     I'm wondering where exactly I should add the VirtIO sound protocol.
>> >> I
>> >>     just familiarized myself with the build system and am about to
>> >> test
>> >> it
>> >>     by building OVMF if possible, but I'm wondering where I should
>> >>     actually put the protocol and all that stuff. Maybe there's
>> >>     documentation I've missed as well.
>> >>
>> >>
>> >>
>> >> Ethin,
>> >>
>> >>
>> >>
>> >> For the driver I’d match the patter of OVMF [1] and use
>> >> OvmfPkg/VirtioSoundDxe/. Maybe even use one of the other drivers as a
>> >> template.
>> >>
>> >>
>> >>
>> >> The protocol is more of a public thing. I think eventually we would
>> >> like
>> >> to publish the protocol in the UEFI Spec (I can help with that part)
>> >> and
>> >> that would mean we put the Protocol definition in
>> >> MdePkg/Include/Protocol, but we don’t want to do that before it is
>> >> standardized as that causes compatibility issues. So this is a “code
>> >> first project” (code prototype and then contribute to the UEFI Forum
>> >> for
>> >> inclusion in the specification) so we need to follow some code first
>> >> rules that I don’t remember of the top of my head? So why not start
>> >> out
>> >> the protocol definition OvmfPkg/Include/Protocol. You can also add a
>> >> test application looks like you can just use the root [2] of OVMF for
>> >> that. That way the project is not blocked.
>> >>
>> >>
>> >>
>> >> We can have a conversation on the mailing list about better places to
>> >> put stuff, and it should be easy enough to move stuff around if
>> >> everything else is working.
>> >>
>> >>
>> >>
>> >> [1] find OvmfPkg  -iname '*Virtio*.inf'
>> >>
>> >> OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
>> >>
>> >> OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
>> >>
>> >> OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf
>> >>
>> >> OvmfPkg/Library/VirtioLib/VirtioLib.inf
>> >>
>> >> OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
>> >>
>> >> OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
>> >>
>> >> OvmfPkg/Virtio10Dxe/Virtio10.inf
>> >>
>> >> OvmfPkg/VirtioNetDxe/VirtioNet.inf
>> >>
>> >> OvmfPkg/VirtioRngDxe/VirtioRng.inf
>> >>
>> >>
>> >>
>> >> [2] /Volumes/Case/edk2-github/OvmfPkg>git grep APPLICATION -- *.inf |
>> >> grep MODULE_TYPE
>> >>
>> >> EnrollDefaultKeys/EnrollDefaultKeys.inf:13:  MODULE_TYPE
>> >>     = UEFI_APPLICATION
>> >>
>> >>
>> >>
>> >> Thanks,
>> >>
>> >>
>> >>
>> >> Andrew Fish
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>     On 3/30/21, Ethin Probst via groups.io <http://groups.io/>
>> >> <http://groups.io/ <http://groups.io/>>
>> >>     <harlydavidsen=gmail.com@groups.io <mailto:gmail.com@groups.io>
>> >>     <mailto:harlydavidsen <mailto:harlydavidsen>=gmail.com@groups.io
>> >> <mailto:gmail.com@groups.io>>> wrote:
>> >>
>> >>         I agree. Plus, it gives me a chance to finally learn the EDK2
>> >> build
>> >>         system and how it works! I've been working on a hobby OS as a
>> >> side
>> >>         project and, though learning from other code examples from
>> >> OSes
>> >> is
>> >>         fun, I have to say that learning from the firmware code like
>> >> from
>> >>         SeaBIOS has been some of the most enlightening and interesting
>> >> times
>> >>         thus far.
>> >>         Thanks for the link to your code, Rafael; once I get virtIO
>> >> support
>> >>         in, I can work on HDA support, though I might tackle USB
>> >> support
>> >>         second and HDA third. We'll see, but VirtIO definitely is
>> >> coming
>> >>         first.
>> >>
>> >>         As I said before, I look forward to working with all of you
>> >>         wonderful
>> >>         people!
>> >>
>> >>         On 3/30/21, Rafael Rodrigues Machado
>> >>         <rafaelrodrigues.machado@gmail.com
>> >> <mailto:rafaelrodrigues.machado@gmail.com>
>> >>         <mailto:rafaelrodrigues.machado@gmail.com
>> >> <mailto:rafaelrodrigues.machado@gmail.com>>>
>> >>         wrote:
>> >>
>> >>             This would be amazing so people can continue my work
>> >> related
>> >> to
>> >>             accessibility at BIOS. Something desired by the blind
>> >> people
>> >>             since the
>> >>             90's
>> >>             Just for reference, this is what I have done:
>> >>
>> >>
>> >> https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
>> >> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>
>> >>
>> >>             Thanks
>> >>             Rafael
>> >>
>> >>             Em seg, 29 de mar de 2021 20:24, Ethin Probst
>> >>             <harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
>> >>             escreveu:
>> >>
>> >>
>> >>                 Hello everyone,
>> >>
>> >>                 This is the first time I've ever contributed to EDK2.
>> >> As
>> >>                 part of GSoC
>> >>                 2021, I have submitted a proposal to implement a UEFI
>> >>                 audio output
>> >>                 protocol that will utilize the VirtIO sound driver.
>> >> I've
>> >>                 already
>> >>                 submitted a draft proposal, and apologize if I've done
>> >>                 things out of
>> >>                 order. This is my first time doing GSoC 2021, and
>> >>                 contributing to EDK2
>> >>                 felt like a really fun thing to do!
>> >>
>> >>                 I look forward to working with you guys on this and
>> >> any
>> >>                 future projects!
>> >>                 :-)
>> >>
>> >>                 --
>> >>                 Signed,
>> >>                 Ethin D. Probst
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>         --
>> >>         Signed,
>> >>         Ethin D. Probst
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>     --
>> >>     Signed,
>> >>     Ethin D. Probst
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>>
>>
>> --
>> Signed,
>> Ethin D. Probst
>>
>>
>>
>>
>>
>> 
>
>


-- 
Signed,
Ethin D. Probst

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Andrew Fish]

[-- Attachment #1: Type: text/plain, Size: 14042 bytes --]



> On Apr 13, 2021, at 9:53 AM, Ethin Probst <harlydavidsen@gmail.com> wrote:
> 
> Would it be possible for us to conduct discussion on the UEFI talkbox?
> I don't mind using email, but things could definitely get moving
> quicker over there (though its not a requirement obviously).
> 

Sure, don’t think I’ve really used that but as long as I get pointed int he right direction I can make it work.

For a device driver the general UEFI model is for the Entry point of the driver to publish a EFI_DRIVER_BINDING_PROTOCOL[1]. The Supported() function matches on the PCI devices. The Start() function installs the Protocols to do work, and the Stop() undoes the Start(). 

Mike Kinney started this back in the day and it describes how to write UEFI drivers: https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Driver-Writer%27s-Guide

[1]https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/DriverBinding.h#L157

Thanks,

Andrew Fish

> Here's how I generally envision the driver functioning:
> 
> 1. Firmware/platform code calls InitaudioOutput() or something like
> it. This function scans the PCIe bus and scans for one of the
> following:
> - Vendor ID 0x1AF4, device ID 0x1059: VirtIO sound device
> - PCI class 0x0C, subclass 0x03, program interface 0x30 or 0x40: for
> USB audio interface (I'm only thinking of targeting XHCI and USB 4,
> and not UHCI, OHCI or EHCI). But maybe EDK2 will take that out of my
> hands. If so, it will make things easier.
> - For USB audio devices I'm not quite sure what to look for; I'm
> definitely unused to USB.
> 2. If any of the above cases are found, appropriate driver
> initialization occurs. Since for the time being I am solely focusing
> on VirtIO sound devices, the VirtIO general initialization sequence
> will occur as outlined in sec. 3 of the VirtIO specification available
> at https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html <https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html>.
> As for actual protocol exposure that would be spec-worthy, for
> EFI_AUDIO_OUTPUT_PROTOCOL, I'm not quite sure what to expose. VirtIO
> is rather simple: there's a buffer for sending and receiving audio
> data in PCM streams. So for that we could expose a Reset(),
> RemapJack(), GetJackConfig(), GetPcmConfig(), SetPcmParams(),
> Prepare(), Release(), Start(), and Stop() function for the
> corresponding request types VIRTIO_SND_R_JACK_GET_CONFIG,
> VIRTIO_SND_R_JACK_REMAP, VIRTIO_SND_R_PCM_GET_CONFIG,
> VIRTIO_SND_R_PCM_SET_PARAMS, VIRTIO_SND_R_PCM_PREPARE,
> VIRTIO_SND_R_PCM_RELEASE, VIRTIO_SND_R_PCM_START, and
> VIRTIO_SND_R_PCM_STOP control requests. However, for HDA things are a
> lot more complex, so I'm not sure how that should work.
> For VirtIO -- which is what I'll focus on for now -- everything is
> described, in excellent detail, in sec. 5.14 of the above-linked
> document. What are your guys's thoughts thus far and how should
> everything be mapped to UEFI interfaces?
> 
> On 4/13/21, Andrew Fish <afish@apple.com <mailto:afish@apple.com>> wrote:
>> Leif,
>> 
>> Since I have put some brain cells around this area in the past I can be the
>> backup and help out too.
>> 
>> I’d also point out if you are having issues building or have general
>> questions on how things work it is fine to use the mailing list. I’ve got a
>> lot of feedback that folks read or search the mailing list looking for
>> answer to their questions so one person asking can help out a lot of other
>> people.
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
>>> On Apr 13, 2021, at 5:28 AM, Leif Lindholm <leif@nuviainc.com> wrote:
>>> 
>>> Hi all, especially Ethin.
>>> 
>>> Apologies for radio silence - last week I was off on holiday, and before
>>> that ... let's just say corporate acquisitions generate some
>>> distractions.
>>> Anyway, I'm back, and since I'm down as the mentor for this task, feel
>>> free to spam me with any remaining/new questions.
>>> 
>>> /
>>>    Leif
>>> 
>>> On Tue, Apr 6, 2021 at 4:17 PM Ethin Probst <harlydavidsen@gmail.com
>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>> wrote:
>>> I'll attach the bug for the build tools to the BZ shortly.
>>> Laszlo, thanks for that. I don't know their email addresses though.
>>> And yes, I was going to make it device independent, as the majority
>>> (if not all) of UEFI protocols are.
>>> 
>>> On 4/6/21, Laszlo Ersek <lersek@redhat.com <mailto:lersek@redhat.com> <mailto:lersek@redhat.com <mailto:lersek@redhat.com>>>
>>> wrote:
>>>> On 03/31/21 08:41, Nate DeSimone wrote:
>>>>> Another option is to put the protocol definition in MdeModulePkg and
>>>>> mark it with the EDKII_ prefix. For my last “code first” UEFI spec
>>>>> contribution I did this with the PPI that added up getting added.
>>>> 
>>>> The new audio protocol should be generic, only its implementation in
>>>> question should be virtio specific.
>>>> 
>>>> Please include Gerd Hoffmann (CC'd) in the protocol design, as well as
>>>> the developers of the virtio-sound device model in QEMU.
>>>> 
>>>> Thanks
>>>> Laszlo
>>>> 
>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> Nate
>>>>> 
>>>>> 
>>>>> 
>>>>> *From: *<devel@edk2.groups.io <mailto:devel@edk2.groups.io> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>> on behalf
>>>>> of "Andrew Fish via groups.io <http://groups.io/> <http://groups.io/ <http://groups.io/>>"
>>>>> <afish=apple.com@groups.io <mailto:afish=apple.com@groups.io> <mailto:apple.com@groups.io <mailto:apple.com@groups.io>>>
>>>>> *Reply-To: *"devel@edk2.groups.io <mailto:devel@edk2.groups.io> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>"
>>>>> <devel@edk2.groups.io <mailto:devel@edk2.groups.io> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>>,
>>>>> "afish@apple.com <mailto:afish@apple.com> <mailto:afish@apple.com <mailto:afish@apple.com>>" <afish@apple.com <mailto:afish@apple.com>
>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>>>
>>>>> *Date: *Tuesday, March 30, 2021 at 10:54 PM
>>>>> *To: *edk2-devel-groups-io <devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>>,
>>>>> "harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>"
>>>>> <harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>
>>>>> *Cc: *Rafael Rodrigues Machado <rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>
>>>>> <mailto:rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>>>
>>>>> *Subject: *Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>    On Mar 30, 2021, at 5:01 PM, Ethin Probst <harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
>>>>>    <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>>
>>>>> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>    I'm wondering where exactly I should add the VirtIO sound protocol.
>>>>> I
>>>>>    just familiarized myself with the build system and am about to
>>>>> test
>>>>> it
>>>>>    by building OVMF if possible, but I'm wondering where I should
>>>>>    actually put the protocol and all that stuff. Maybe there's
>>>>>    documentation I've missed as well.
>>>>> 
>>>>> 
>>>>> 
>>>>> Ethin,
>>>>> 
>>>>> 
>>>>> 
>>>>> For the driver I’d match the patter of OVMF [1] and use
>>>>> OvmfPkg/VirtioSoundDxe/. Maybe even use one of the other drivers as a
>>>>> template.
>>>>> 
>>>>> 
>>>>> 
>>>>> The protocol is more of a public thing. I think eventually we would
>>>>> like
>>>>> to publish the protocol in the UEFI Spec (I can help with that part)
>>>>> and
>>>>> that would mean we put the Protocol definition in
>>>>> MdePkg/Include/Protocol, but we don’t want to do that before it is
>>>>> standardized as that causes compatibility issues. So this is a “code
>>>>> first project” (code prototype and then contribute to the UEFI Forum
>>>>> for
>>>>> inclusion in the specification) so we need to follow some code first
>>>>> rules that I don’t remember of the top of my head? So why not start
>>>>> out
>>>>> the protocol definition OvmfPkg/Include/Protocol. You can also add a
>>>>> test application looks like you can just use the root [2] of OVMF for
>>>>> that. That way the project is not blocked.
>>>>> 
>>>>> 
>>>>> 
>>>>> We can have a conversation on the mailing list about better places to
>>>>> put stuff, and it should be easy enough to move stuff around if
>>>>> everything else is working.
>>>>> 
>>>>> 
>>>>> 
>>>>> [1] find OvmfPkg  -iname '*Virtio*.inf'
>>>>> 
>>>>> OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
>>>>> 
>>>>> OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
>>>>> 
>>>>> OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf
>>>>> 
>>>>> OvmfPkg/Library/VirtioLib/VirtioLib.inf
>>>>> 
>>>>> OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
>>>>> 
>>>>> OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
>>>>> 
>>>>> OvmfPkg/Virtio10Dxe/Virtio10.inf
>>>>> 
>>>>> OvmfPkg/VirtioNetDxe/VirtioNet.inf
>>>>> 
>>>>> OvmfPkg/VirtioRngDxe/VirtioRng.inf
>>>>> 
>>>>> 
>>>>> 
>>>>> [2] /Volumes/Case/edk2-github/OvmfPkg>git grep APPLICATION -- *.inf |
>>>>> grep MODULE_TYPE
>>>>> 
>>>>> EnrollDefaultKeys/EnrollDefaultKeys.inf:13:  MODULE_TYPE
>>>>>    = UEFI_APPLICATION
>>>>> 
>>>>> 
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> 
>>>>> 
>>>>> Andrew Fish
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>    On 3/30/21, Ethin Probst via groups.io <http://groups.io/> <http://groups.io/ <http://groups.io/>>
>>>>> <http://groups.io/ <http://groups.io/> <http://groups.io/ <http://groups.io/>>>
>>>>>    <harlydavidsen=gmail.com@groups.io <mailto:harlydavidsen=gmail.com@groups.io> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>>
>>>>>    <mailto:harlydavidsen <mailto:harlydavidsen>=gmail.com@groups.io <mailto:gmail.com@groups.io>
>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>>>> wrote:
>>>>> 
>>>>>        I agree. Plus, it gives me a chance to finally learn the EDK2
>>>>> build
>>>>>        system and how it works! I've been working on a hobby OS as a
>>>>> side
>>>>>        project and, though learning from other code examples from
>>>>> OSes
>>>>> is
>>>>>        fun, I have to say that learning from the firmware code like
>>>>> from
>>>>>        SeaBIOS has been some of the most enlightening and interesting
>>>>> times
>>>>>        thus far.
>>>>>        Thanks for the link to your code, Rafael; once I get virtIO
>>>>> support
>>>>>        in, I can work on HDA support, though I might tackle USB
>>>>> support
>>>>>        second and HDA third. We'll see, but VirtIO definitely is
>>>>> coming
>>>>>        first.
>>>>> 
>>>>>        As I said before, I look forward to working with all of you
>>>>>        wonderful
>>>>>        people!
>>>>> 
>>>>>        On 3/30/21, Rafael Rodrigues Machado
>>>>>        <rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>
>>>>> <mailto:rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>>
>>>>>        <mailto:rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>
>>>>> <mailto:rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>>>>
>>>>>        wrote:
>>>>> 
>>>>>            This would be amazing so people can continue my work
>>>>> related
>>>>> to
>>>>>            accessibility at BIOS. Something desired by the blind
>>>>> people
>>>>>            since the
>>>>>            90's
>>>>>            Just for reference, this is what I have done:
>>>>> 
>>>>> 
>>>>> https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>
>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>>
>>>>> 
>>>>>            Thanks
>>>>>            Rafael
>>>>> 
>>>>>            Em seg, 29 de mar de 2021 20:24, Ethin Probst
>>>>>            <harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>
>>>>>            escreveu:
>>>>> 
>>>>> 
>>>>>                Hello everyone,
>>>>> 
>>>>>                This is the first time I've ever contributed to EDK2.
>>>>> As
>>>>>                part of GSoC
>>>>>                2021, I have submitted a proposal to implement a UEFI
>>>>>                audio output
>>>>>                protocol that will utilize the VirtIO sound driver.
>>>>> I've
>>>>>                already
>>>>>                submitted a draft proposal, and apologize if I've done
>>>>>                things out of
>>>>>                order. This is my first time doing GSoC 2021, and
>>>>>                contributing to EDK2
>>>>>                felt like a really fun thing to do!
>>>>> 
>>>>>                I look forward to working with you guys on this and
>>>>> any
>>>>>                future projects!
>>>>>                :-)
>>>>> 
>>>>>                --
>>>>>                Signed,
>>>>>                Ethin D. Probst
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>        --
>>>>>        Signed,
>>>>>        Ethin D. Probst
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>    --
>>>>>    Signed,
>>>>>    Ethin D. Probst
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> Signed,
>>> Ethin D. Probst
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 
> 
> -- 
> Signed,
> Ethin D. Probst
> 
> 
> 


[-- Attachment #2: Type: text/html, Size: 54985 bytes --]

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Ethin Probst]

Hi Andrew,

The developer guide for EDK2 drivers is a godsend. Thank you very
much, and thank you, Mike, for your excellent work on the guide! I may
just ahve to do my building on Linux and not Windows -- unless the Bug
-- bug 3302 -- has been fixed. I'll have to do testing on Linux, at
any rate, since Windows hosts do not support VirtIO emulation and I
can't seem to find any way of emulating them in a guest machine with
Windows as a host.

On 4/13/21, Andrew Fish <afish@apple.com> wrote:
>
>
>> On Apr 13, 2021, at 9:53 AM, Ethin Probst <harlydavidsen@gmail.com>
>> wrote:
>>
>> Would it be possible for us to conduct discussion on the UEFI talkbox?
>> I don't mind using email, but things could definitely get moving
>> quicker over there (though its not a requirement obviously).
>>
>
> Sure, don’t think I’ve really used that but as long as I get pointed int he
> right direction I can make it work.
>
> For a device driver the general UEFI model is for the Entry point of the
> driver to publish a EFI_DRIVER_BINDING_PROTOCOL[1]. The Supported() function
> matches on the PCI devices. The Start() function installs the Protocols to
> do work, and the Stop() undoes the Start().
>
> Mike Kinney started this back in the day and it describes how to write UEFI
> drivers:
> https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Driver-Writer%27s-Guide
>
> [1]https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/DriverBinding.h#L157
>
> Thanks,
>
> Andrew Fish
>
>> Here's how I generally envision the driver functioning:
>>
>> 1. Firmware/platform code calls InitaudioOutput() or something like
>> it. This function scans the PCIe bus and scans for one of the
>> following:
>> - Vendor ID 0x1AF4, device ID 0x1059: VirtIO sound device
>> - PCI class 0x0C, subclass 0x03, program interface 0x30 or 0x40: for
>> USB audio interface (I'm only thinking of targeting XHCI and USB 4,
>> and not UHCI, OHCI or EHCI). But maybe EDK2 will take that out of my
>> hands. If so, it will make things easier.
>> - For USB audio devices I'm not quite sure what to look for; I'm
>> definitely unused to USB.
>> 2. If any of the above cases are found, appropriate driver
>> initialization occurs. Since for the time being I am solely focusing
>> on VirtIO sound devices, the VirtIO general initialization sequence
>> will occur as outlined in sec. 3 of the VirtIO specification available
>> at https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html
>> <https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html>.
>> As for actual protocol exposure that would be spec-worthy, for
>> EFI_AUDIO_OUTPUT_PROTOCOL, I'm not quite sure what to expose. VirtIO
>> is rather simple: there's a buffer for sending and receiving audio
>> data in PCM streams. So for that we could expose a Reset(),
>> RemapJack(), GetJackConfig(), GetPcmConfig(), SetPcmParams(),
>> Prepare(), Release(), Start(), and Stop() function for the
>> corresponding request types VIRTIO_SND_R_JACK_GET_CONFIG,
>> VIRTIO_SND_R_JACK_REMAP, VIRTIO_SND_R_PCM_GET_CONFIG,
>> VIRTIO_SND_R_PCM_SET_PARAMS, VIRTIO_SND_R_PCM_PREPARE,
>> VIRTIO_SND_R_PCM_RELEASE, VIRTIO_SND_R_PCM_START, and
>> VIRTIO_SND_R_PCM_STOP control requests. However, for HDA things are a
>> lot more complex, so I'm not sure how that should work.
>> For VirtIO -- which is what I'll focus on for now -- everything is
>> described, in excellent detail, in sec. 5.14 of the above-linked
>> document. What are your guys's thoughts thus far and how should
>> everything be mapped to UEFI interfaces?
>>
>> On 4/13/21, Andrew Fish <afish@apple.com <mailto:afish@apple.com>> wrote:
>>> Leif,
>>>
>>> Since I have put some brain cells around this area in the past I can be
>>> the
>>> backup and help out too.
>>>
>>> I’d also point out if you are having issues building or have general
>>> questions on how things work it is fine to use the mailing list. I’ve got
>>> a
>>> lot of feedback that folks read or search the mailing list looking for
>>> answer to their questions so one person asking can help out a lot of
>>> other
>>> people.
>>>
>>> Thanks,
>>>
>>> Andrew Fish
>>>
>>>> On Apr 13, 2021, at 5:28 AM, Leif Lindholm <leif@nuviainc.com> wrote:
>>>>
>>>> Hi all, especially Ethin.
>>>>
>>>> Apologies for radio silence - last week I was off on holiday, and
>>>> before
>>>> that ... let's just say corporate acquisitions generate some
>>>> distractions.
>>>> Anyway, I'm back, and since I'm down as the mentor for this task, feel
>>>> free to spam me with any remaining/new questions.
>>>>
>>>> /
>>>>    Leif
>>>>
>>>> On Tue, Apr 6, 2021 at 4:17 PM Ethin Probst <harlydavidsen@gmail.com
>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>
>>>> wrote:
>>>> I'll attach the bug for the build tools to the BZ shortly.
>>>> Laszlo, thanks for that. I don't know their email addresses though.
>>>> And yes, I was going to make it device independent, as the majority
>>>> (if not all) of UEFI protocols are.
>>>>
>>>> On 4/6/21, Laszlo Ersek <lersek@redhat.com <mailto:lersek@redhat.com>
>>>> <mailto:lersek@redhat.com <mailto:lersek@redhat.com>>>
>>>> wrote:
>>>>> On 03/31/21 08:41, Nate DeSimone wrote:
>>>>>> Another option is to put the protocol definition in MdeModulePkg and
>>>>>> mark it with the EDKII_ prefix. For my last “code first” UEFI spec
>>>>>> contribution I did this with the PPI that added up getting added.
>>>>>
>>>>> The new audio protocol should be generic, only its implementation in
>>>>> question should be virtio specific.
>>>>>
>>>>> Please include Gerd Hoffmann (CC'd) in the protocol design, as well as
>>>>> the developers of the virtio-sound device model in QEMU.
>>>>>
>>>>> Thanks
>>>>> Laszlo
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Nate
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From: *<devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>> on
>>>>>> behalf
>>>>>> of "Andrew Fish via groups.io <http://groups.io/> <http://groups.io/
>>>>>> <http://groups.io/>>"
>>>>>> <afish=apple.com@groups.io <mailto:afish=apple.com@groups.io>
>>>>>> <mailto:apple.com@groups.io <mailto:apple.com@groups.io>>>
>>>>>> *Reply-To: *"devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>"
>>>>>> <devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>>,
>>>>>> "afish@apple.com <mailto:afish@apple.com> <mailto:afish@apple.com
>>>>>> <mailto:afish@apple.com>>" <afish@apple.com <mailto:afish@apple.com>
>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>>>
>>>>>> *Date: *Tuesday, March 30, 2021 at 10:54 PM
>>>>>> *To: *edk2-devel-groups-io <devel@edk2.groups.io
>>>>>> <mailto:devel@edk2.groups.io>
>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>>,
>>>>>> "harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>"
>>>>>> <harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>
>>>>>> *Cc: *Rafael Rodrigues Machado <rafaelrodrigues.machado@gmail.com
>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>>
>>>>>> *Subject: *Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>    On Mar 30, 2021, at 5:01 PM, Ethin Probst <harlydavidsen@gmail.com
>>>>>> <mailto:harlydavidsen@gmail.com>
>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
>>>>>>    <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>    I'm wondering where exactly I should add the VirtIO sound
>>>>>> protocol.
>>>>>> I
>>>>>>    just familiarized myself with the build system and am about to
>>>>>> test
>>>>>> it
>>>>>>    by building OVMF if possible, but I'm wondering where I should
>>>>>>    actually put the protocol and all that stuff. Maybe there's
>>>>>>    documentation I've missed as well.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Ethin,
>>>>>>
>>>>>>
>>>>>>
>>>>>> For the driver I’d match the patter of OVMF [1] and use
>>>>>> OvmfPkg/VirtioSoundDxe/. Maybe even use one of the other drivers as a
>>>>>> template.
>>>>>>
>>>>>>
>>>>>>
>>>>>> The protocol is more of a public thing. I think eventually we would
>>>>>> like
>>>>>> to publish the protocol in the UEFI Spec (I can help with that part)
>>>>>> and
>>>>>> that would mean we put the Protocol definition in
>>>>>> MdePkg/Include/Protocol, but we don’t want to do that before it is
>>>>>> standardized as that causes compatibility issues. So this is a “code
>>>>>> first project” (code prototype and then contribute to the UEFI Forum
>>>>>> for
>>>>>> inclusion in the specification) so we need to follow some code first
>>>>>> rules that I don’t remember of the top of my head? So why not start
>>>>>> out
>>>>>> the protocol definition OvmfPkg/Include/Protocol. You can also add a
>>>>>> test application looks like you can just use the root [2] of OVMF for
>>>>>> that. That way the project is not blocked.
>>>>>>
>>>>>>
>>>>>>
>>>>>> We can have a conversation on the mailing list about better places to
>>>>>> put stuff, and it should be easy enough to move stuff around if
>>>>>> everything else is working.
>>>>>>
>>>>>>
>>>>>>
>>>>>> [1] find OvmfPkg  -iname '*Virtio*.inf'
>>>>>>
>>>>>> OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
>>>>>>
>>>>>> OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
>>>>>>
>>>>>> OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf
>>>>>>
>>>>>> OvmfPkg/Library/VirtioLib/VirtioLib.inf
>>>>>>
>>>>>> OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
>>>>>>
>>>>>> OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
>>>>>>
>>>>>> OvmfPkg/Virtio10Dxe/Virtio10.inf
>>>>>>
>>>>>> OvmfPkg/VirtioNetDxe/VirtioNet.inf
>>>>>>
>>>>>> OvmfPkg/VirtioRngDxe/VirtioRng.inf
>>>>>>
>>>>>>
>>>>>>
>>>>>> [2] /Volumes/Case/edk2-github/OvmfPkg>git grep APPLICATION -- *.inf |
>>>>>> grep MODULE_TYPE
>>>>>>
>>>>>> EnrollDefaultKeys/EnrollDefaultKeys.inf:13:  MODULE_TYPE
>>>>>>    = UEFI_APPLICATION
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>>
>>>>>>
>>>>>> Andrew Fish
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>    On 3/30/21, Ethin Probst via groups.io <http://groups.io/>
>>>>>> <http://groups.io/ <http://groups.io/>>
>>>>>> <http://groups.io/ <http://groups.io/> <http://groups.io/
>>>>>> <http://groups.io/>>>
>>>>>>    <harlydavidsen=gmail.com@groups.io
>>>>>> <mailto:harlydavidsen=gmail.com@groups.io> <mailto:gmail.com@groups.io
>>>>>> <mailto:gmail.com@groups.io>>
>>>>>>    <mailto:harlydavidsen <mailto:harlydavidsen>=gmail.com@groups.io
>>>>>> <mailto:gmail.com@groups.io>
>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>>>> wrote:
>>>>>>
>>>>>>        I agree. Plus, it gives me a chance to finally learn the EDK2
>>>>>> build
>>>>>>        system and how it works! I've been working on a hobby OS as a
>>>>>> side
>>>>>>        project and, though learning from other code examples from
>>>>>> OSes
>>>>>> is
>>>>>>        fun, I have to say that learning from the firmware code like
>>>>>> from
>>>>>>        SeaBIOS has been some of the most enlightening and interesting
>>>>>> times
>>>>>>        thus far.
>>>>>>        Thanks for the link to your code, Rafael; once I get virtIO
>>>>>> support
>>>>>>        in, I can work on HDA support, though I might tackle USB
>>>>>> support
>>>>>>        second and HDA third. We'll see, but VirtIO definitely is
>>>>>> coming
>>>>>>        first.
>>>>>>
>>>>>>        As I said before, I look forward to working with all of you
>>>>>>        wonderful
>>>>>>        people!
>>>>>>
>>>>>>        On 3/30/21, Rafael Rodrigues Machado
>>>>>>        <rafaelrodrigues.machado@gmail.com
>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>
>>>>>>        <mailto:rafaelrodrigues.machado@gmail.com
>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>>>
>>>>>>        wrote:
>>>>>>
>>>>>>            This would be amazing so people can continue my work
>>>>>> related
>>>>>> to
>>>>>>            accessibility at BIOS. Something desired by the blind
>>>>>> people
>>>>>>            since the
>>>>>>            90's
>>>>>>            Just for reference, this is what I have done:
>>>>>>
>>>>>>
>>>>>> https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>
>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>>
>>>>>>
>>>>>>            Thanks
>>>>>>            Rafael
>>>>>>
>>>>>>            Em seg, 29 de mar de 2021 20:24, Ethin Probst
>>>>>>            <harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>
>>>>>>            escreveu:
>>>>>>
>>>>>>
>>>>>>                Hello everyone,
>>>>>>
>>>>>>                This is the first time I've ever contributed to EDK2.
>>>>>> As
>>>>>>                part of GSoC
>>>>>>                2021, I have submitted a proposal to implement a UEFI
>>>>>>                audio output
>>>>>>                protocol that will utilize the VirtIO sound driver.
>>>>>> I've
>>>>>>                already
>>>>>>                submitted a draft proposal, and apologize if I've done
>>>>>>                things out of
>>>>>>                order. This is my first time doing GSoC 2021, and
>>>>>>                contributing to EDK2
>>>>>>                felt like a really fun thing to do!
>>>>>>
>>>>>>                I look forward to working with you guys on this and
>>>>>> any
>>>>>>                future projects!
>>>>>>                :-)
>>>>>>
>>>>>>                --
>>>>>>                Signed,
>>>>>>                Ethin D. Probst
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>        --
>>>>>>        Signed,
>>>>>>        Ethin D. Probst
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>    --
>>>>>>    Signed,
>>>>>>    Ethin D. Probst
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Signed,
>>>> Ethin D. Probst
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>> --
>> Signed,
>> Ethin D. Probst
>>
>>
>> 
>
>


-- 
Signed,
Ethin D. Probst

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Ethin Probst]

Okay, so looking at the EDK2 driver developers guide, here are my thoughts:

- Each audio driver will be a bus driver, even if it doesn't control
buses in the traditional sense.
- I think the initialization sequence should be different: there
should be an AudioDxe, but it should contain three separate bus
drivers for each kind of audio device supported.
- For the VirtIO audio device driver, it'll most likely consume the
PCI I/O protocol and produce the EFI_VIRTIO_AUDIO_OUTPUT_PROTOCOL and
EFI_VIRTIO_AUDIO_INPUT_PROTOCOL protocols. This will just be an
ordinary UEFI device driver.
- The HDA audio device driver will consume the PCI I/O protocol and
will produce different device handles per HDA controller found. I'd
produce a handle per codec, but that seems overkill. Each handle will
be attached to both an audio stream protocol and a controller
management protocol. The audio stream protocol will manage the
creation, control, and deletion of audio streams as well as the
processing of audio data. The controller management protocol is
responsible for allowing applications or other drivers to manage the
HDA controller itself.

I haven't planned for the USB audio device driver yet, but these are
my thoughts so far. What do you guys think? Am I over-complicating
this setup? How can it be improved upon?

On 4/13/21, Ethin Probst via groups.io
<harlydavidsen=gmail.com@groups.io> wrote:
> Hi Andrew,
>
> The developer guide for EDK2 drivers is a godsend. Thank you very
> much, and thank you, Mike, for your excellent work on the guide! I may
> just ahve to do my building on Linux and not Windows -- unless the Bug
> -- bug 3302 -- has been fixed. I'll have to do testing on Linux, at
> any rate, since Windows hosts do not support VirtIO emulation and I
> can't seem to find any way of emulating them in a guest machine with
> Windows as a host.
>
> On 4/13/21, Andrew Fish <afish@apple.com> wrote:
>>
>>
>>> On Apr 13, 2021, at 9:53 AM, Ethin Probst <harlydavidsen@gmail.com>
>>> wrote:
>>>
>>> Would it be possible for us to conduct discussion on the UEFI talkbox?
>>> I don't mind using email, but things could definitely get moving
>>> quicker over there (though its not a requirement obviously).
>>>
>>
>> Sure, don’t think I’ve really used that but as long as I get pointed int
>> he
>> right direction I can make it work.
>>
>> For a device driver the general UEFI model is for the Entry point of the
>> driver to publish a EFI_DRIVER_BINDING_PROTOCOL[1]. The Supported()
>> function
>> matches on the PCI devices. The Start() function installs the Protocols
>> to
>> do work, and the Stop() undoes the Start().
>>
>> Mike Kinney started this back in the day and it describes how to write
>> UEFI
>> drivers:
>> https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Driver-Writer%27s-Guide
>>
>> [1]https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/DriverBinding.h#L157
>>
>> Thanks,
>>
>> Andrew Fish
>>
>>> Here's how I generally envision the driver functioning:
>>>
>>> 1. Firmware/platform code calls InitaudioOutput() or something like
>>> it. This function scans the PCIe bus and scans for one of the
>>> following:
>>> - Vendor ID 0x1AF4, device ID 0x1059: VirtIO sound device
>>> - PCI class 0x0C, subclass 0x03, program interface 0x30 or 0x40: for
>>> USB audio interface (I'm only thinking of targeting XHCI and USB 4,
>>> and not UHCI, OHCI or EHCI). But maybe EDK2 will take that out of my
>>> hands. If so, it will make things easier.
>>> - For USB audio devices I'm not quite sure what to look for; I'm
>>> definitely unused to USB.
>>> 2. If any of the above cases are found, appropriate driver
>>> initialization occurs. Since for the time being I am solely focusing
>>> on VirtIO sound devices, the VirtIO general initialization sequence
>>> will occur as outlined in sec. 3 of the VirtIO specification available
>>> at https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html
>>> <https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html>.
>>> As for actual protocol exposure that would be spec-worthy, for
>>> EFI_AUDIO_OUTPUT_PROTOCOL, I'm not quite sure what to expose. VirtIO
>>> is rather simple: there's a buffer for sending and receiving audio
>>> data in PCM streams. So for that we could expose a Reset(),
>>> RemapJack(), GetJackConfig(), GetPcmConfig(), SetPcmParams(),
>>> Prepare(), Release(), Start(), and Stop() function for the
>>> corresponding request types VIRTIO_SND_R_JACK_GET_CONFIG,
>>> VIRTIO_SND_R_JACK_REMAP, VIRTIO_SND_R_PCM_GET_CONFIG,
>>> VIRTIO_SND_R_PCM_SET_PARAMS, VIRTIO_SND_R_PCM_PREPARE,
>>> VIRTIO_SND_R_PCM_RELEASE, VIRTIO_SND_R_PCM_START, and
>>> VIRTIO_SND_R_PCM_STOP control requests. However, for HDA things are a
>>> lot more complex, so I'm not sure how that should work.
>>> For VirtIO -- which is what I'll focus on for now -- everything is
>>> described, in excellent detail, in sec. 5.14 of the above-linked
>>> document. What are your guys's thoughts thus far and how should
>>> everything be mapped to UEFI interfaces?
>>>
>>> On 4/13/21, Andrew Fish <afish@apple.com <mailto:afish@apple.com>>
>>> wrote:
>>>> Leif,
>>>>
>>>> Since I have put some brain cells around this area in the past I can be
>>>> the
>>>> backup and help out too.
>>>>
>>>> I’d also point out if you are having issues building or have general
>>>> questions on how things work it is fine to use the mailing list. I’ve
>>>> got
>>>> a
>>>> lot of feedback that folks read or search the mailing list looking for
>>>> answer to their questions so one person asking can help out a lot of
>>>> other
>>>> people.
>>>>
>>>> Thanks,
>>>>
>>>> Andrew Fish
>>>>
>>>>> On Apr 13, 2021, at 5:28 AM, Leif Lindholm <leif@nuviainc.com> wrote:
>>>>>
>>>>> Hi all, especially Ethin.
>>>>>
>>>>> Apologies for radio silence - last week I was off on holiday, and
>>>>> before
>>>>> that ... let's just say corporate acquisitions generate some
>>>>> distractions.
>>>>> Anyway, I'm back, and since I'm down as the mentor for this task, feel
>>>>> free to spam me with any remaining/new questions.
>>>>>
>>>>> /
>>>>>    Leif
>>>>>
>>>>> On Tue, Apr 6, 2021 at 4:17 PM Ethin Probst <harlydavidsen@gmail.com
>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>
>>>>> wrote:
>>>>> I'll attach the bug for the build tools to the BZ shortly.
>>>>> Laszlo, thanks for that. I don't know their email addresses though.
>>>>> And yes, I was going to make it device independent, as the majority
>>>>> (if not all) of UEFI protocols are.
>>>>>
>>>>> On 4/6/21, Laszlo Ersek <lersek@redhat.com <mailto:lersek@redhat.com>
>>>>> <mailto:lersek@redhat.com <mailto:lersek@redhat.com>>>
>>>>> wrote:
>>>>>> On 03/31/21 08:41, Nate DeSimone wrote:
>>>>>>> Another option is to put the protocol definition in MdeModulePkg and
>>>>>>> mark it with the EDKII_ prefix. For my last “code first” UEFI spec
>>>>>>> contribution I did this with the PPI that added up getting added.
>>>>>>
>>>>>> The new audio protocol should be generic, only its implementation in
>>>>>> question should be virtio specific.
>>>>>>
>>>>>> Please include Gerd Hoffmann (CC'd) in the protocol design, as well
>>>>>> as
>>>>>> the developers of the virtio-sound device model in QEMU.
>>>>>>
>>>>>> Thanks
>>>>>> Laszlo
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Nate
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *From: *<devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>> on
>>>>>>> behalf
>>>>>>> of "Andrew Fish via groups.io <http://groups.io/> <http://groups.io/
>>>>>>> <http://groups.io/>>"
>>>>>>> <afish=apple.com@groups.io <mailto:afish=apple.com@groups.io>
>>>>>>> <mailto:apple.com@groups.io <mailto:apple.com@groups.io>>>
>>>>>>> *Reply-To: *"devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>"
>>>>>>> <devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>>,
>>>>>>> "afish@apple.com <mailto:afish@apple.com> <mailto:afish@apple.com
>>>>>>> <mailto:afish@apple.com>>" <afish@apple.com <mailto:afish@apple.com>
>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>>>
>>>>>>> *Date: *Tuesday, March 30, 2021 at 10:54 PM
>>>>>>> *To: *edk2-devel-groups-io <devel@edk2.groups.io
>>>>>>> <mailto:devel@edk2.groups.io>
>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>>,
>>>>>>> "harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>"
>>>>>>> <harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>
>>>>>>> *Cc: *Rafael Rodrigues Machado <rafaelrodrigues.machado@gmail.com
>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>>
>>>>>>> *Subject: *Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>    On Mar 30, 2021, at 5:01 PM, Ethin Probst
>>>>>>> <harlydavidsen@gmail.com
>>>>>>> <mailto:harlydavidsen@gmail.com>
>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
>>>>>>>    <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>    I'm wondering where exactly I should add the VirtIO sound
>>>>>>> protocol.
>>>>>>> I
>>>>>>>    just familiarized myself with the build system and am about to
>>>>>>> test
>>>>>>> it
>>>>>>>    by building OVMF if possible, but I'm wondering where I should
>>>>>>>    actually put the protocol and all that stuff. Maybe there's
>>>>>>>    documentation I've missed as well.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Ethin,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> For the driver I’d match the patter of OVMF [1] and use
>>>>>>> OvmfPkg/VirtioSoundDxe/. Maybe even use one of the other drivers as
>>>>>>> a
>>>>>>> template.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The protocol is more of a public thing. I think eventually we would
>>>>>>> like
>>>>>>> to publish the protocol in the UEFI Spec (I can help with that part)
>>>>>>> and
>>>>>>> that would mean we put the Protocol definition in
>>>>>>> MdePkg/Include/Protocol, but we don’t want to do that before it is
>>>>>>> standardized as that causes compatibility issues. So this is a “code
>>>>>>> first project” (code prototype and then contribute to the UEFI Forum
>>>>>>> for
>>>>>>> inclusion in the specification) so we need to follow some code first
>>>>>>> rules that I don’t remember of the top of my head? So why not start
>>>>>>> out
>>>>>>> the protocol definition OvmfPkg/Include/Protocol. You can also add a
>>>>>>> test application looks like you can just use the root [2] of OVMF
>>>>>>> for
>>>>>>> that. That way the project is not blocked.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> We can have a conversation on the mailing list about better places
>>>>>>> to
>>>>>>> put stuff, and it should be easy enough to move stuff around if
>>>>>>> everything else is working.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> [1] find OvmfPkg  -iname '*Virtio*.inf'
>>>>>>>
>>>>>>> OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
>>>>>>>
>>>>>>> OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
>>>>>>>
>>>>>>> OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf
>>>>>>>
>>>>>>> OvmfPkg/Library/VirtioLib/VirtioLib.inf
>>>>>>>
>>>>>>> OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
>>>>>>>
>>>>>>> OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
>>>>>>>
>>>>>>> OvmfPkg/Virtio10Dxe/Virtio10.inf
>>>>>>>
>>>>>>> OvmfPkg/VirtioNetDxe/VirtioNet.inf
>>>>>>>
>>>>>>> OvmfPkg/VirtioRngDxe/VirtioRng.inf
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> [2] /Volumes/Case/edk2-github/OvmfPkg>git grep APPLICATION -- *.inf
>>>>>>> |
>>>>>>> grep MODULE_TYPE
>>>>>>>
>>>>>>> EnrollDefaultKeys/EnrollDefaultKeys.inf:13:  MODULE_TYPE
>>>>>>>    = UEFI_APPLICATION
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Andrew Fish
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>    On 3/30/21, Ethin Probst via groups.io <http://groups.io/>
>>>>>>> <http://groups.io/ <http://groups.io/>>
>>>>>>> <http://groups.io/ <http://groups.io/> <http://groups.io/
>>>>>>> <http://groups.io/>>>
>>>>>>>    <harlydavidsen=gmail.com@groups.io
>>>>>>> <mailto:harlydavidsen=gmail.com@groups.io>
>>>>>>> <mailto:gmail.com@groups.io
>>>>>>> <mailto:gmail.com@groups.io>>
>>>>>>>    <mailto:harlydavidsen <mailto:harlydavidsen>=gmail.com@groups.io
>>>>>>> <mailto:gmail.com@groups.io>
>>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>>>> wrote:
>>>>>>>
>>>>>>>        I agree. Plus, it gives me a chance to finally learn the EDK2
>>>>>>> build
>>>>>>>        system and how it works! I've been working on a hobby OS as a
>>>>>>> side
>>>>>>>        project and, though learning from other code examples from
>>>>>>> OSes
>>>>>>> is
>>>>>>>        fun, I have to say that learning from the firmware code like
>>>>>>> from
>>>>>>>        SeaBIOS has been some of the most enlightening and
>>>>>>> interesting
>>>>>>> times
>>>>>>>        thus far.
>>>>>>>        Thanks for the link to your code, Rafael; once I get virtIO
>>>>>>> support
>>>>>>>        in, I can work on HDA support, though I might tackle USB
>>>>>>> support
>>>>>>>        second and HDA third. We'll see, but VirtIO definitely is
>>>>>>> coming
>>>>>>>        first.
>>>>>>>
>>>>>>>        As I said before, I look forward to working with all of you
>>>>>>>        wonderful
>>>>>>>        people!
>>>>>>>
>>>>>>>        On 3/30/21, Rafael Rodrigues Machado
>>>>>>>        <rafaelrodrigues.machado@gmail.com
>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>
>>>>>>>        <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>>>
>>>>>>>        wrote:
>>>>>>>
>>>>>>>            This would be amazing so people can continue my work
>>>>>>> related
>>>>>>> to
>>>>>>>            accessibility at BIOS. Something desired by the blind
>>>>>>> people
>>>>>>>            since the
>>>>>>>            90's
>>>>>>>            Just for reference, this is what I have done:
>>>>>>>
>>>>>>>
>>>>>>> https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>
>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>>
>>>>>>>
>>>>>>>            Thanks
>>>>>>>            Rafael
>>>>>>>
>>>>>>>            Em seg, 29 de mar de 2021 20:24, Ethin Probst
>>>>>>>            <harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>
>>>>>>>            escreveu:
>>>>>>>
>>>>>>>
>>>>>>>                Hello everyone,
>>>>>>>
>>>>>>>                This is the first time I've ever contributed to EDK2.
>>>>>>> As
>>>>>>>                part of GSoC
>>>>>>>                2021, I have submitted a proposal to implement a UEFI
>>>>>>>                audio output
>>>>>>>                protocol that will utilize the VirtIO sound driver.
>>>>>>> I've
>>>>>>>                already
>>>>>>>                submitted a draft proposal, and apologize if I've
>>>>>>> done
>>>>>>>                things out of
>>>>>>>                order. This is my first time doing GSoC 2021, and
>>>>>>>                contributing to EDK2
>>>>>>>                felt like a really fun thing to do!
>>>>>>>
>>>>>>>                I look forward to working with you guys on this and
>>>>>>> any
>>>>>>>                future projects!
>>>>>>>                :-)
>>>>>>>
>>>>>>>                --
>>>>>>>                Signed,
>>>>>>>                Ethin D. Probst
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>        --
>>>>>>>        Signed,
>>>>>>>        Ethin D. Probst
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>    --
>>>>>>>    Signed,
>>>>>>>    Ethin D. Probst
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Signed,
>>>>> Ethin D. Probst
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Signed,
>>> Ethin D. Probst
>>>
>>>
>>>
>>
>>
>
>
> --
> Signed,
> Ethin D. Probst
>
>
> 
>
>
>


-- 
Signed,
Ethin D. Probst

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Andrew Fish]

[-- Attachment #1: Type: text/plain, Size: 25665 bytes --]

Ethin,

In terms of defining the protocol stack it is good to start with the producers and consumers and think about the problem from both perspectives. It is easy enough to think about the producer part of it as you are thinking about writing the driver. The driver is going to consume things like the PCI I/O Protocol. 

The consumer of the sound Protocol is going to most likely be generic EFI platform code, and possibly an OS loader. In the boot process Audio has traditionally be used for error codes, sign of life (for example the famous Mac startup sound). We are also would like to have the option of enabling better accessibility features, especially for people how are visually impaired. These days a lot of software engineers think of disk space as free and really don’t consider the size of software, but this is not true for firmware. Firmware generally lives in NOR FLASH that is considered expensive (it is more expensive than NAND, but at the same time more reliable) so firmware implementations are constrained by the size of the code that can be carried, and the size of assets/resources that can be used for user interfaces. The OS loader is some what less constrained, but it still has to share the EFI System Partition on the disk with potentially other OS loaders. 

So the consumer wants a protocol that is unleveled and focused on the task at hand. I’m not too caught up on the names but in general I think things you want are (How many knobs we need is probably better answered by an audiophile, and that is not me):
1) CompatibleBuffer() - Does driver support this buffer format. 
2) PlayBuffer() - Play the sound
	a) We probably want a synchronous and asynchronous version of this API. For example you don’t want to slow down the boot to wait for a boot beep to complete, and you may chose to implement an API that waits for the sound to complete (and do some GUI work in parallel) vs. blocking on the sound. 
	b) async in EFI usually means you return a pointer to an EFI_EVENT that gets signaled on completion.
3) StopBuffer() - In case the asynchronous PlayBuffer() needs to be stopped. Think error exit. 
3) SetVolume()/GetVolume() - Set/Get Volume in units of 0 - 100 (trying to avoid db as that gets into capability and math that is likely best abstracted by the driver)?
4) Mute()/UnMute() - Mute and volume are often independent features in a UI keeping them separate in API makes it easier to implement things. 
5) PlayTone() - Maybe for error sounds that don’t require canned sound files. Maybe TimeOn, TimeOff, Frequency, and how many times to repeat. 
6) Do we need tuning values or Tone settings? 

At some point we might consider defining nvram variable for the default state of some of the tunable, especially mute and volume. For example the user may want to turn off all volume on the system so it would be nice if the OS can set the EFI volume and mute. In the short run we can probably use PCD values to set the default values. 

So I think we have a generic AUDIO API on top and likely a PCI I/O on the bottom. If we need more protocols to manage hardware devices then those protocols can be defined in the context of that hardware. So for example we would probably end up with an HDA_CODEC protocol. I think the best way to think about this is a disk. A lot of disk adapters just produce a raw Block I/O  protocol, but for a more common bus like ATA or SCSI you might have an extra driver in place to make the common bits common code. I think some of the same layers may be in place here. So likely VirtIo is simple and just produces the generic AUDIO API, while an HDA audio driver also has to abstract some of the complexity of its hardware implementation and standard. 

In terms of picking the set of APIs and tunables it is probably good to start with VirtIo and USB and see what set make sense and what you could and could not implement. HDA Audio is so complex you might want to look at it in terms of the minute you have to implement to make it function. Think what assumptions are you forced to make to implement. 

This is a vey 10,000 foot view to start with. I think you will need to mix this in the the reality of how it works in the real world to figure out the right abstraction, but then again that is the beauty of having an implementation. Likely also get some feedback from audiophiles. 

Oh and make sure you don’t go off an implement a lot of code just because we chose the wrong complexity or abstraction point. This is the one time we get to change the public APIs so lets feel free to adjust them to make the most sense for the job at hand. 

Thanks,

Andrew Fish

> On Apr 13, 2021, at 6:20 PM, Ethin Probst <harlydavidsen@gmail.com> wrote:
> 
> Okay, so looking at the EDK2 driver developers guide, here are my thoughts:
> 
> - Each audio driver will be a bus driver, even if it doesn't control
> buses in the traditional sense.
> - I think the initialization sequence should be different: there
> should be an AudioDxe, but it should contain three separate bus
> drivers for each kind of audio device supported.
> - For the VirtIO audio device driver, it'll most likely consume the
> PCI I/O protocol and produce the EFI_VIRTIO_AUDIO_OUTPUT_PROTOCOL and
> EFI_VIRTIO_AUDIO_INPUT_PROTOCOL protocols. This will just be an
> ordinary UEFI device driver.
> - The HDA audio device driver will consume the PCI I/O protocol and
> will produce different device handles per HDA controller found. I'd
> produce a handle per codec, but that seems overkill. Each handle will
> be attached to both an audio stream protocol and a controller
> management protocol. The audio stream protocol will manage the
> creation, control, and deletion of audio streams as well as the
> processing of audio data. The controller management protocol is
> responsible for allowing applications or other drivers to manage the
> HDA controller itself.
> 
> I haven't planned for the USB audio device driver yet, but these are
> my thoughts so far. What do you guys think? Am I over-complicating
> this setup? How can it be improved upon?
> 
> On 4/13/21, Ethin Probst via groups.io <http://groups.io/>
> <harlydavidsen=gmail.com@groups.io <mailto:harlydavidsen=gmail.com@groups.io>> wrote:
>> Hi Andrew,
>> 
>> The developer guide for EDK2 drivers is a godsend. Thank you very
>> much, and thank you, Mike, for your excellent work on the guide! I may
>> just ahve to do my building on Linux and not Windows -- unless the Bug
>> -- bug 3302 -- has been fixed. I'll have to do testing on Linux, at
>> any rate, since Windows hosts do not support VirtIO emulation and I
>> can't seem to find any way of emulating them in a guest machine with
>> Windows as a host.
>> 
>> On 4/13/21, Andrew Fish <afish@apple.com <mailto:afish@apple.com>> wrote:
>>> 
>>> 
>>>> On Apr 13, 2021, at 9:53 AM, Ethin Probst <harlydavidsen@gmail.com>
>>>> wrote:
>>>> 
>>>> Would it be possible for us to conduct discussion on the UEFI talkbox?
>>>> I don't mind using email, but things could definitely get moving
>>>> quicker over there (though its not a requirement obviously).
>>>> 
>>> 
>>> Sure, don’t think I’ve really used that but as long as I get pointed int
>>> he
>>> right direction I can make it work.
>>> 
>>> For a device driver the general UEFI model is for the Entry point of the
>>> driver to publish a EFI_DRIVER_BINDING_PROTOCOL[1]. The Supported()
>>> function
>>> matches on the PCI devices. The Start() function installs the Protocols
>>> to
>>> do work, and the Stop() undoes the Start().
>>> 
>>> Mike Kinney started this back in the day and it describes how to write
>>> UEFI
>>> drivers:
>>> https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Driver-Writer%27s-Guide
>>> 
>>> [1]https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/DriverBinding.h#L157
>>> 
>>> Thanks,
>>> 
>>> Andrew Fish
>>> 
>>>> Here's how I generally envision the driver functioning:
>>>> 
>>>> 1. Firmware/platform code calls InitaudioOutput() or something like
>>>> it. This function scans the PCIe bus and scans for one of the
>>>> following:
>>>> - Vendor ID 0x1AF4, device ID 0x1059: VirtIO sound device
>>>> - PCI class 0x0C, subclass 0x03, program interface 0x30 or 0x40: for
>>>> USB audio interface (I'm only thinking of targeting XHCI and USB 4,
>>>> and not UHCI, OHCI or EHCI). But maybe EDK2 will take that out of my
>>>> hands. If so, it will make things easier.
>>>> - For USB audio devices I'm not quite sure what to look for; I'm
>>>> definitely unused to USB.
>>>> 2. If any of the above cases are found, appropriate driver
>>>> initialization occurs. Since for the time being I am solely focusing
>>>> on VirtIO sound devices, the VirtIO general initialization sequence
>>>> will occur as outlined in sec. 3 of the VirtIO specification available
>>>> at https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html
>>>> <https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html <https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html>>.
>>>> As for actual protocol exposure that would be spec-worthy, for
>>>> EFI_AUDIO_OUTPUT_PROTOCOL, I'm not quite sure what to expose. VirtIO
>>>> is rather simple: there's a buffer for sending and receiving audio
>>>> data in PCM streams. So for that we could expose a Reset(),
>>>> RemapJack(), GetJackConfig(), GetPcmConfig(), SetPcmParams(),
>>>> Prepare(), Release(), Start(), and Stop() function for the
>>>> corresponding request types VIRTIO_SND_R_JACK_GET_CONFIG,
>>>> VIRTIO_SND_R_JACK_REMAP, VIRTIO_SND_R_PCM_GET_CONFIG,
>>>> VIRTIO_SND_R_PCM_SET_PARAMS, VIRTIO_SND_R_PCM_PREPARE,
>>>> VIRTIO_SND_R_PCM_RELEASE, VIRTIO_SND_R_PCM_START, and
>>>> VIRTIO_SND_R_PCM_STOP control requests. However, for HDA things are a
>>>> lot more complex, so I'm not sure how that should work.
>>>> For VirtIO -- which is what I'll focus on for now -- everything is
>>>> described, in excellent detail, in sec. 5.14 of the above-linked
>>>> document. What are your guys's thoughts thus far and how should
>>>> everything be mapped to UEFI interfaces?
>>>> 
>>>> On 4/13/21, Andrew Fish <afish@apple.com <mailto:afish@apple.com> <mailto:afish@apple.com <mailto:afish@apple.com>>>
>>>> wrote:
>>>>> Leif,
>>>>> 
>>>>> Since I have put some brain cells around this area in the past I can be
>>>>> the
>>>>> backup and help out too.
>>>>> 
>>>>> I’d also point out if you are having issues building or have general
>>>>> questions on how things work it is fine to use the mailing list. I’ve
>>>>> got
>>>>> a
>>>>> lot of feedback that folks read or search the mailing list looking for
>>>>> answer to their questions so one person asking can help out a lot of
>>>>> other
>>>>> people.
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> Andrew Fish
>>>>> 
>>>>>> On Apr 13, 2021, at 5:28 AM, Leif Lindholm <leif@nuviainc.com <mailto:leif@nuviainc.com>> wrote:
>>>>>> 
>>>>>> Hi all, especially Ethin.
>>>>>> 
>>>>>> Apologies for radio silence - last week I was off on holiday, and
>>>>>> before
>>>>>> that ... let's just say corporate acquisitions generate some
>>>>>> distractions.
>>>>>> Anyway, I'm back, and since I'm down as the mentor for this task, feel
>>>>>> free to spam me with any remaining/new questions.
>>>>>> 
>>>>>> /
>>>>>>   Leif
>>>>>> 
>>>>>> On Tue, Apr 6, 2021 at 4:17 PM Ethin Probst <harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>>
>>>>>> wrote:
>>>>>> I'll attach the bug for the build tools to the BZ shortly.
>>>>>> Laszlo, thanks for that. I don't know their email addresses though.
>>>>>> And yes, I was going to make it device independent, as the majority
>>>>>> (if not all) of UEFI protocols are.
>>>>>> 
>>>>>> On 4/6/21, Laszlo Ersek <lersek@redhat.com <mailto:lersek@redhat.com> <mailto:lersek@redhat.com <mailto:lersek@redhat.com>>
>>>>>> <mailto:lersek@redhat.com <mailto:lersek@redhat.com> <mailto:lersek@redhat.com <mailto:lersek@redhat.com>>>>
>>>>>> wrote:
>>>>>>> On 03/31/21 08:41, Nate DeSimone wrote:
>>>>>>>> Another option is to put the protocol definition in MdeModulePkg and
>>>>>>>> mark it with the EDKII_ prefix. For my last “code first” UEFI spec
>>>>>>>> contribution I did this with the PPI that added up getting added.
>>>>>>> 
>>>>>>> The new audio protocol should be generic, only its implementation in
>>>>>>> question should be virtio specific.
>>>>>>> 
>>>>>>> Please include Gerd Hoffmann (CC'd) in the protocol design, as well
>>>>>>> as
>>>>>>> the developers of the virtio-sound device model in QEMU.
>>>>>>> 
>>>>>>> Thanks
>>>>>>> Laszlo
>>>>>>> 
>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> 
>>>>>>>> Nate
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> *From: *<devel@edk2.groups.io <mailto:devel@edk2.groups.io> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>>> on
>>>>>>>> behalf
>>>>>>>> of "Andrew Fish via groups.io <http://groups.io/> <http://groups.io/ <http://groups.io/>> <http://groups.io/ <http://groups.io/>
>>>>>>>> <http://groups.io/ <http://groups.io/>>>"
>>>>>>>> <afish=apple.com@groups.io <mailto:afish=apple.com@groups.io> <mailto:afish=apple.com@groups.io <mailto:afish=apple.com@groups.io>>
>>>>>>>> <mailto:apple.com@groups.io <mailto:apple.com@groups.io> <mailto:apple.com@groups.io <mailto:apple.com@groups.io>>>>
>>>>>>>> *Reply-To: *"devel@edk2.groups.io <mailto:devel@edk2.groups.io> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>>"
>>>>>>>> <devel@edk2.groups.io <mailto:devel@edk2.groups.io> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>>>,
>>>>>>>> "afish@apple.com <mailto:afish@apple.com> <mailto:afish@apple.com <mailto:afish@apple.com>> <mailto:afish@apple.com <mailto:afish@apple.com>
>>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>>>" <afish@apple.com <mailto:afish@apple.com> <mailto:afish@apple.com <mailto:afish@apple.com>>
>>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com> <mailto:afish@apple.com <mailto:afish@apple.com>>>>
>>>>>>>> *Date: *Tuesday, March 30, 2021 at 10:54 PM
>>>>>>>> *To: *edk2-devel-groups-io <devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>>>,
>>>>>>>> "harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>"
>>>>>>>> <harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>>
>>>>>>>> *Cc: *Rafael Rodrigues Machado <rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>>
>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>>>>
>>>>>>>> *Subject: *Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>   On Mar 30, 2021, at 5:01 PM, Ethin Probst
>>>>>>>> <harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>
>>>>>>>>   <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>>>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>   I'm wondering where exactly I should add the VirtIO sound
>>>>>>>> protocol.
>>>>>>>> I
>>>>>>>>   just familiarized myself with the build system and am about to
>>>>>>>> test
>>>>>>>> it
>>>>>>>>   by building OVMF if possible, but I'm wondering where I should
>>>>>>>>   actually put the protocol and all that stuff. Maybe there's
>>>>>>>>   documentation I've missed as well.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Ethin,
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> For the driver I’d match the patter of OVMF [1] and use
>>>>>>>> OvmfPkg/VirtioSoundDxe/. Maybe even use one of the other drivers as
>>>>>>>> a
>>>>>>>> template.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> The protocol is more of a public thing. I think eventually we would
>>>>>>>> like
>>>>>>>> to publish the protocol in the UEFI Spec (I can help with that part)
>>>>>>>> and
>>>>>>>> that would mean we put the Protocol definition in
>>>>>>>> MdePkg/Include/Protocol, but we don’t want to do that before it is
>>>>>>>> standardized as that causes compatibility issues. So this is a “code
>>>>>>>> first project” (code prototype and then contribute to the UEFI Forum
>>>>>>>> for
>>>>>>>> inclusion in the specification) so we need to follow some code first
>>>>>>>> rules that I don’t remember of the top of my head? So why not start
>>>>>>>> out
>>>>>>>> the protocol definition OvmfPkg/Include/Protocol. You can also add a
>>>>>>>> test application looks like you can just use the root [2] of OVMF
>>>>>>>> for
>>>>>>>> that. That way the project is not blocked.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> We can have a conversation on the mailing list about better places
>>>>>>>> to
>>>>>>>> put stuff, and it should be easy enough to move stuff around if
>>>>>>>> everything else is working.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> [1] find OvmfPkg  -iname '*Virtio*.inf'
>>>>>>>> 
>>>>>>>> OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
>>>>>>>> 
>>>>>>>> OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
>>>>>>>> 
>>>>>>>> OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf
>>>>>>>> 
>>>>>>>> OvmfPkg/Library/VirtioLib/VirtioLib.inf
>>>>>>>> 
>>>>>>>> OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
>>>>>>>> 
>>>>>>>> OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
>>>>>>>> 
>>>>>>>> OvmfPkg/Virtio10Dxe/Virtio10.inf
>>>>>>>> 
>>>>>>>> OvmfPkg/VirtioNetDxe/VirtioNet.inf
>>>>>>>> 
>>>>>>>> OvmfPkg/VirtioRngDxe/VirtioRng.inf
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> [2] /Volumes/Case/edk2-github/OvmfPkg>git grep APPLICATION -- *.inf
>>>>>>>> |
>>>>>>>> grep MODULE_TYPE
>>>>>>>> 
>>>>>>>> EnrollDefaultKeys/EnrollDefaultKeys.inf:13:  MODULE_TYPE
>>>>>>>>   = UEFI_APPLICATION
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Andrew Fish
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>   On 3/30/21, Ethin Probst via groups.io <http://groups.io/> <http://groups.io/ <http://groups.io/>>
>>>>>>>> <http://groups.io/ <http://groups.io/> <http://groups.io/ <http://groups.io/>>>
>>>>>>>> <http://groups.io/ <http://groups.io/> <http://groups.io/ <http://groups.io/>> <http://groups.io/ <http://groups.io/>
>>>>>>>> <http://groups.io/ <http://groups.io/>>>>
>>>>>>>>   <harlydavidsen=gmail.com@groups.io <mailto:harlydavidsen=gmail.com@groups.io>
>>>>>>>> <mailto:harlydavidsen=gmail.com@groups.io <mailto:harlydavidsen=gmail.com@groups.io>>
>>>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>
>>>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>>>
>>>>>>>>   <mailto:harlydavidsen <mailto:harlydavidsen>=gmail.com@groups.io <mailto:gmail.com@groups.io>
>>>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>>
>>>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>>>>> wrote:
>>>>>>>> 
>>>>>>>>       I agree. Plus, it gives me a chance to finally learn the EDK2
>>>>>>>> build
>>>>>>>>       system and how it works! I've been working on a hobby OS as a
>>>>>>>> side
>>>>>>>>       project and, though learning from other code examples from
>>>>>>>> OSes
>>>>>>>> is
>>>>>>>>       fun, I have to say that learning from the firmware code like
>>>>>>>> from
>>>>>>>>       SeaBIOS has been some of the most enlightening and
>>>>>>>> interesting
>>>>>>>> times
>>>>>>>>       thus far.
>>>>>>>>       Thanks for the link to your code, Rafael; once I get virtIO
>>>>>>>> support
>>>>>>>>       in, I can work on HDA support, though I might tackle USB
>>>>>>>> support
>>>>>>>>       second and HDA third. We'll see, but VirtIO definitely is
>>>>>>>> coming
>>>>>>>>       first.
>>>>>>>> 
>>>>>>>>       As I said before, I look forward to working with all of you
>>>>>>>>       wonderful
>>>>>>>>       people!
>>>>>>>> 
>>>>>>>>       On 3/30/21, Rafael Rodrigues Machado
>>>>>>>>       <rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>>
>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>>>
>>>>>>>>       <mailto:rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>>
>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>>>>>
>>>>>>>>       wrote:
>>>>>>>> 
>>>>>>>>           This would be amazing so people can continue my work
>>>>>>>> related
>>>>>>>> to
>>>>>>>>           accessibility at BIOS. Something desired by the blind
>>>>>>>> people
>>>>>>>>           since the
>>>>>>>>           90's
>>>>>>>>           Just for reference, this is what I have done:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>
>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>>
>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>
>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>>>
>>>>>>>> 
>>>>>>>>           Thanks
>>>>>>>>           Rafael
>>>>>>>> 
>>>>>>>>           Em seg, 29 de mar de 2021 20:24, Ethin Probst
>>>>>>>>           <harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>>
>>>>>>>>           escreveu:
>>>>>>>> 
>>>>>>>> 
>>>>>>>>               Hello everyone,
>>>>>>>> 
>>>>>>>>               This is the first time I've ever contributed to EDK2.
>>>>>>>> As
>>>>>>>>               part of GSoC
>>>>>>>>               2021, I have submitted a proposal to implement a UEFI
>>>>>>>>               audio output
>>>>>>>>               protocol that will utilize the VirtIO sound driver.
>>>>>>>> I've
>>>>>>>>               already
>>>>>>>>               submitted a draft proposal, and apologize if I've
>>>>>>>> done
>>>>>>>>               things out of
>>>>>>>>               order. This is my first time doing GSoC 2021, and
>>>>>>>>               contributing to EDK2
>>>>>>>>               felt like a really fun thing to do!
>>>>>>>> 
>>>>>>>>               I look forward to working with you guys on this and
>>>>>>>> any
>>>>>>>>               future projects!
>>>>>>>>               :-)
>>>>>>>> 
>>>>>>>>               --
>>>>>>>>               Signed,
>>>>>>>>               Ethin D. Probst
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>       --
>>>>>>>>       Signed,
>>>>>>>>       Ethin D. Probst
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>   --
>>>>>>>>   Signed,
>>>>>>>>   Ethin D. Probst
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Signed,
>>>>>> Ethin D. Probst
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> Signed,
>>>> Ethin D. Probst
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
>> --
>> Signed,
>> Ethin D. Probst
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 
> -- 
> Signed,
> Ethin D. Probst


[-- Attachment #2: Type: text/html, Size: 57885 bytes --]

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Ethin Probst]

These are some pretty good suggestions; however, while reading through
the VirtIO specification again yesterday, I (re)-discovered that
VirtIO devices are usually interrupt based. In particular, a VirtIO
PCI/PCIe device defines the common, notifications, ISR status,
device-specific configuration, PCI configuration access, shared memory
region, and vendor-specific data capability structures in PCI
configuration space. It doesn't look like the EFI_CREATE_EVENT or
EFI_CREATE_EVENT_EX function works via interrupts, from what I can
tell. I'm not sure but it doesn't seem like there's a way I can poll
the device, though I might be missing something.
The idea for the generic protocol is good. The interrupt issue might
be a problem though and I'm not sure how to actually solve that.

On 4/13/21, Andrew Fish <afish@apple.com> wrote:
> Ethin,
>
> In terms of defining the protocol stack it is good to start with the
> producers and consumers and think about the problem from both perspectives.
> It is easy enough to think about the producer part of it as you are thinking
> about writing the driver. The driver is going to consume things like the PCI
> I/O Protocol.
>
> The consumer of the sound Protocol is going to most likely be generic EFI
> platform code, and possibly an OS loader. In the boot process Audio has
> traditionally be used for error codes, sign of life (for example the famous
> Mac startup sound). We are also would like to have the option of enabling
> better accessibility features, especially for people how are visually
> impaired. These days a lot of software engineers think of disk space as free
> and really don’t consider the size of software, but this is not true for
> firmware. Firmware generally lives in NOR FLASH that is considered expensive
> (it is more expensive than NAND, but at the same time more reliable) so
> firmware implementations are constrained by the size of the code that can be
> carried, and the size of assets/resources that can be used for user
> interfaces. The OS loader is some what less constrained, but it still has to
> share the EFI System Partition on the disk with potentially other OS
> loaders.
>
> So the consumer wants a protocol that is unleveled and focused on the task
> at hand. I’m not too caught up on the names but in general I think things
> you want are (How many knobs we need is probably better answered by an
> audiophile, and that is not me):
> 1) CompatibleBuffer() - Does driver support this buffer format.
> 2) PlayBuffer() - Play the sound
> 	a) We probably want a synchronous and asynchronous version of this API. For
> example you don’t want to slow down the boot to wait for a boot beep to
> complete, and you may chose to implement an API that waits for the sound to
> complete (and do some GUI work in parallel) vs. blocking on the sound.
> 	b) async in EFI usually means you return a pointer to an EFI_EVENT that
> gets signaled on completion.
> 3) StopBuffer() - In case the asynchronous PlayBuffer() needs to be stopped.
> Think error exit.
> 3) SetVolume()/GetVolume() - Set/Get Volume in units of 0 - 100 (trying to
> avoid db as that gets into capability and math that is likely best
> abstracted by the driver)?
> 4) Mute()/UnMute() - Mute and volume are often independent features in a UI
> keeping them separate in API makes it easier to implement things.
> 5) PlayTone() - Maybe for error sounds that don’t require canned sound
> files. Maybe TimeOn, TimeOff, Frequency, and how many times to repeat.
> 6) Do we need tuning values or Tone settings?
>
> At some point we might consider defining nvram variable for the default
> state of some of the tunable, especially mute and volume. For example the
> user may want to turn off all volume on the system so it would be nice if
> the OS can set the EFI volume and mute. In the short run we can probably use
> PCD values to set the default values.
>
> So I think we have a generic AUDIO API on top and likely a PCI I/O on the
> bottom. If we need more protocols to manage hardware devices then those
> protocols can be defined in the context of that hardware. So for example we
> would probably end up with an HDA_CODEC protocol. I think the best way to
> think about this is a disk. A lot of disk adapters just produce a raw Block
> I/O  protocol, but for a more common bus like ATA or SCSI you might have an
> extra driver in place to make the common bits common code. I think some of
> the same layers may be in place here. So likely VirtIo is simple and just
> produces the generic AUDIO API, while an HDA audio driver also has to
> abstract some of the complexity of its hardware implementation and standard.
>
>
> In terms of picking the set of APIs and tunables it is probably good to
> start with VirtIo and USB and see what set make sense and what you could and
> could not implement. HDA Audio is so complex you might want to look at it in
> terms of the minute you have to implement to make it function. Think what
> assumptions are you forced to make to implement.
>
> This is a vey 10,000 foot view to start with. I think you will need to mix
> this in the the reality of how it works in the real world to figure out the
> right abstraction, but then again that is the beauty of having an
> implementation. Likely also get some feedback from audiophiles.
>
> Oh and make sure you don’t go off an implement a lot of code just because we
> chose the wrong complexity or abstraction point. This is the one time we get
> to change the public APIs so lets feel free to adjust them to make the most
> sense for the job at hand.
>
> Thanks,
>
> Andrew Fish
>
>> On Apr 13, 2021, at 6:20 PM, Ethin Probst <harlydavidsen@gmail.com>
>> wrote:
>>
>> Okay, so looking at the EDK2 driver developers guide, here are my
>> thoughts:
>>
>> - Each audio driver will be a bus driver, even if it doesn't control
>> buses in the traditional sense.
>> - I think the initialization sequence should be different: there
>> should be an AudioDxe, but it should contain three separate bus
>> drivers for each kind of audio device supported.
>> - For the VirtIO audio device driver, it'll most likely consume the
>> PCI I/O protocol and produce the EFI_VIRTIO_AUDIO_OUTPUT_PROTOCOL and
>> EFI_VIRTIO_AUDIO_INPUT_PROTOCOL protocols. This will just be an
>> ordinary UEFI device driver.
>> - The HDA audio device driver will consume the PCI I/O protocol and
>> will produce different device handles per HDA controller found. I'd
>> produce a handle per codec, but that seems overkill. Each handle will
>> be attached to both an audio stream protocol and a controller
>> management protocol. The audio stream protocol will manage the
>> creation, control, and deletion of audio streams as well as the
>> processing of audio data. The controller management protocol is
>> responsible for allowing applications or other drivers to manage the
>> HDA controller itself.
>>
>> I haven't planned for the USB audio device driver yet, but these are
>> my thoughts so far. What do you guys think? Am I over-complicating
>> this setup? How can it be improved upon?
>>
>> On 4/13/21, Ethin Probst via groups.io <http://groups.io/>
>> <harlydavidsen=gmail.com@groups.io
>> <mailto:harlydavidsen=gmail.com@groups.io>> wrote:
>>> Hi Andrew,
>>>
>>> The developer guide for EDK2 drivers is a godsend. Thank you very
>>> much, and thank you, Mike, for your excellent work on the guide! I may
>>> just ahve to do my building on Linux and not Windows -- unless the Bug
>>> -- bug 3302 -- has been fixed. I'll have to do testing on Linux, at
>>> any rate, since Windows hosts do not support VirtIO emulation and I
>>> can't seem to find any way of emulating them in a guest machine with
>>> Windows as a host.
>>>
>>> On 4/13/21, Andrew Fish <afish@apple.com <mailto:afish@apple.com>>
>>> wrote:
>>>>
>>>>
>>>>> On Apr 13, 2021, at 9:53 AM, Ethin Probst <harlydavidsen@gmail.com>
>>>>> wrote:
>>>>>
>>>>> Would it be possible for us to conduct discussion on the UEFI talkbox?
>>>>> I don't mind using email, but things could definitely get moving
>>>>> quicker over there (though its not a requirement obviously).
>>>>>
>>>>
>>>> Sure, don’t think I’ve really used that but as long as I get pointed
>>>> int
>>>> he
>>>> right direction I can make it work.
>>>>
>>>> For a device driver the general UEFI model is for the Entry point of
>>>> the
>>>> driver to publish a EFI_DRIVER_BINDING_PROTOCOL[1]. The Supported()
>>>> function
>>>> matches on the PCI devices. The Start() function installs the Protocols
>>>> to
>>>> do work, and the Stop() undoes the Start().
>>>>
>>>> Mike Kinney started this back in the day and it describes how to write
>>>> UEFI
>>>> drivers:
>>>> https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Driver-Writer%27s-Guide
>>>>
>>>> [1]https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/DriverBinding.h#L157
>>>>
>>>> Thanks,
>>>>
>>>> Andrew Fish
>>>>
>>>>> Here's how I generally envision the driver functioning:
>>>>>
>>>>> 1. Firmware/platform code calls InitaudioOutput() or something like
>>>>> it. This function scans the PCIe bus and scans for one of the
>>>>> following:
>>>>> - Vendor ID 0x1AF4, device ID 0x1059: VirtIO sound device
>>>>> - PCI class 0x0C, subclass 0x03, program interface 0x30 or 0x40: for
>>>>> USB audio interface (I'm only thinking of targeting XHCI and USB 4,
>>>>> and not UHCI, OHCI or EHCI). But maybe EDK2 will take that out of my
>>>>> hands. If so, it will make things easier.
>>>>> - For USB audio devices I'm not quite sure what to look for; I'm
>>>>> definitely unused to USB.
>>>>> 2. If any of the above cases are found, appropriate driver
>>>>> initialization occurs. Since for the time being I am solely focusing
>>>>> on VirtIO sound devices, the VirtIO general initialization sequence
>>>>> will occur as outlined in sec. 3 of the VirtIO specification available
>>>>> at https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html
>>>>> <https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html
>>>>> <https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html>>.
>>>>> As for actual protocol exposure that would be spec-worthy, for
>>>>> EFI_AUDIO_OUTPUT_PROTOCOL, I'm not quite sure what to expose. VirtIO
>>>>> is rather simple: there's a buffer for sending and receiving audio
>>>>> data in PCM streams. So for that we could expose a Reset(),
>>>>> RemapJack(), GetJackConfig(), GetPcmConfig(), SetPcmParams(),
>>>>> Prepare(), Release(), Start(), and Stop() function for the
>>>>> corresponding request types VIRTIO_SND_R_JACK_GET_CONFIG,
>>>>> VIRTIO_SND_R_JACK_REMAP, VIRTIO_SND_R_PCM_GET_CONFIG,
>>>>> VIRTIO_SND_R_PCM_SET_PARAMS, VIRTIO_SND_R_PCM_PREPARE,
>>>>> VIRTIO_SND_R_PCM_RELEASE, VIRTIO_SND_R_PCM_START, and
>>>>> VIRTIO_SND_R_PCM_STOP control requests. However, for HDA things are a
>>>>> lot more complex, so I'm not sure how that should work.
>>>>> For VirtIO -- which is what I'll focus on for now -- everything is
>>>>> described, in excellent detail, in sec. 5.14 of the above-linked
>>>>> document. What are your guys's thoughts thus far and how should
>>>>> everything be mapped to UEFI interfaces?
>>>>>
>>>>> On 4/13/21, Andrew Fish <afish@apple.com <mailto:afish@apple.com>
>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>>>
>>>>> wrote:
>>>>>> Leif,
>>>>>>
>>>>>> Since I have put some brain cells around this area in the past I can
>>>>>> be
>>>>>> the
>>>>>> backup and help out too.
>>>>>>
>>>>>> I’d also point out if you are having issues building or have general
>>>>>> questions on how things work it is fine to use the mailing list. I’ve
>>>>>> got
>>>>>> a
>>>>>> lot of feedback that folks read or search the mailing list looking
>>>>>> for
>>>>>> answer to their questions so one person asking can help out a lot of
>>>>>> other
>>>>>> people.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Andrew Fish
>>>>>>
>>>>>>> On Apr 13, 2021, at 5:28 AM, Leif Lindholm <leif@nuviainc.com
>>>>>>> <mailto:leif@nuviainc.com>> wrote:
>>>>>>>
>>>>>>> Hi all, especially Ethin.
>>>>>>>
>>>>>>> Apologies for radio silence - last week I was off on holiday, and
>>>>>>> before
>>>>>>> that ... let's just say corporate acquisitions generate some
>>>>>>> distractions.
>>>>>>> Anyway, I'm back, and since I'm down as the mentor for this task,
>>>>>>> feel
>>>>>>> free to spam me with any remaining/new questions.
>>>>>>>
>>>>>>> /
>>>>>>>   Leif
>>>>>>>
>>>>>>> On Tue, Apr 6, 2021 at 4:17 PM Ethin Probst <harlydavidsen@gmail.com
>>>>>>> <mailto:harlydavidsen@gmail.com>
>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>>
>>>>>>> wrote:
>>>>>>> I'll attach the bug for the build tools to the BZ shortly.
>>>>>>> Laszlo, thanks for that. I don't know their email addresses though.
>>>>>>> And yes, I was going to make it device independent, as the majority
>>>>>>> (if not all) of UEFI protocols are.
>>>>>>>
>>>>>>> On 4/6/21, Laszlo Ersek <lersek@redhat.com <mailto:lersek@redhat.com>
>>>>>>> <mailto:lersek@redhat.com <mailto:lersek@redhat.com>>
>>>>>>> <mailto:lersek@redhat.com <mailto:lersek@redhat.com>
>>>>>>> <mailto:lersek@redhat.com <mailto:lersek@redhat.com>>>>
>>>>>>> wrote:
>>>>>>>> On 03/31/21 08:41, Nate DeSimone wrote:
>>>>>>>>> Another option is to put the protocol definition in MdeModulePkg
>>>>>>>>> and
>>>>>>>>> mark it with the EDKII_ prefix. For my last “code first” UEFI spec
>>>>>>>>> contribution I did this with the PPI that added up getting added.
>>>>>>>>
>>>>>>>> The new audio protocol should be generic, only its implementation
>>>>>>>> in
>>>>>>>> question should be virtio specific.
>>>>>>>>
>>>>>>>> Please include Gerd Hoffmann (CC'd) in the protocol design, as well
>>>>>>>> as
>>>>>>>> the developers of the virtio-sound device model in QEMU.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Laszlo
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Nate
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *From: *<devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>>> on
>>>>>>>>> behalf
>>>>>>>>> of "Andrew Fish via groups.io <http://groups.io/>
>>>>>>>>> <http://groups.io/ <http://groups.io/>> <http://groups.io/
>>>>>>>>> <http://groups.io/>
>>>>>>>>> <http://groups.io/ <http://groups.io/>>>"
>>>>>>>>> <afish=apple.com@groups.io <mailto:afish=apple.com@groups.io>
>>>>>>>>> <mailto:afish=apple.com@groups.io
>>>>>>>>> <mailto:afish=apple.com@groups.io>>
>>>>>>>>> <mailto:apple.com@groups.io <mailto:apple.com@groups.io>
>>>>>>>>> <mailto:apple.com@groups.io <mailto:apple.com@groups.io>>>>
>>>>>>>>> *Reply-To: *"devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>>"
>>>>>>>>> <devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>>>,
>>>>>>>>> "afish@apple.com <mailto:afish@apple.com> <mailto:afish@apple.com
>>>>>>>>> <mailto:afish@apple.com>> <mailto:afish@apple.com
>>>>>>>>> <mailto:afish@apple.com>
>>>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>>>"
>>>>>>>>> <afish@apple.com <mailto:afish@apple.com> <mailto:afish@apple.com
>>>>>>>>> <mailto:afish@apple.com>>
>>>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>
>>>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>>>>
>>>>>>>>> *Date: *Tuesday, March 30, 2021 at 10:54 PM
>>>>>>>>> *To: *edk2-devel-groups-io <devel@edk2.groups.io
>>>>>>>>> <mailto:devel@edk2.groups.io>
>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>>>,
>>>>>>>>> "harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>> <mailto:harlydavidsen@gmail.com>>>"
>>>>>>>>> <harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>> <mailto:harlydavidsen@gmail.com>>>>
>>>>>>>>> *Cc: *Rafael Rodrigues Machado <rafaelrodrigues.machado@gmail.com
>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>
>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>>>
>>>>>>>>> *Subject: *Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>   On Mar 30, 2021, at 5:01 PM, Ethin Probst
>>>>>>>>> <harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>
>>>>>>>>>   <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>> <mailto:harlydavidsen@gmail.com>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>   I'm wondering where exactly I should add the VirtIO sound
>>>>>>>>> protocol.
>>>>>>>>> I
>>>>>>>>>   just familiarized myself with the build system and am about to
>>>>>>>>> test
>>>>>>>>> it
>>>>>>>>>   by building OVMF if possible, but I'm wondering where I should
>>>>>>>>>   actually put the protocol and all that stuff. Maybe there's
>>>>>>>>>   documentation I've missed as well.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Ethin,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> For the driver I’d match the patter of OVMF [1] and use
>>>>>>>>> OvmfPkg/VirtioSoundDxe/. Maybe even use one of the other drivers
>>>>>>>>> as
>>>>>>>>> a
>>>>>>>>> template.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The protocol is more of a public thing. I think eventually we
>>>>>>>>> would
>>>>>>>>> like
>>>>>>>>> to publish the protocol in the UEFI Spec (I can help with that
>>>>>>>>> part)
>>>>>>>>> and
>>>>>>>>> that would mean we put the Protocol definition in
>>>>>>>>> MdePkg/Include/Protocol, but we don’t want to do that before it is
>>>>>>>>> standardized as that causes compatibility issues. So this is a
>>>>>>>>> “code
>>>>>>>>> first project” (code prototype and then contribute to the UEFI
>>>>>>>>> Forum
>>>>>>>>> for
>>>>>>>>> inclusion in the specification) so we need to follow some code
>>>>>>>>> first
>>>>>>>>> rules that I don’t remember of the top of my head? So why not
>>>>>>>>> start
>>>>>>>>> out
>>>>>>>>> the protocol definition OvmfPkg/Include/Protocol. You can also add
>>>>>>>>> a
>>>>>>>>> test application looks like you can just use the root [2] of OVMF
>>>>>>>>> for
>>>>>>>>> that. That way the project is not blocked.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> We can have a conversation on the mailing list about better places
>>>>>>>>> to
>>>>>>>>> put stuff, and it should be easy enough to move stuff around if
>>>>>>>>> everything else is working.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> [1] find OvmfPkg  -iname '*Virtio*.inf'
>>>>>>>>>
>>>>>>>>> OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
>>>>>>>>>
>>>>>>>>> OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
>>>>>>>>>
>>>>>>>>> OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf
>>>>>>>>>
>>>>>>>>> OvmfPkg/Library/VirtioLib/VirtioLib.inf
>>>>>>>>>
>>>>>>>>> OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
>>>>>>>>>
>>>>>>>>> OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
>>>>>>>>>
>>>>>>>>> OvmfPkg/Virtio10Dxe/Virtio10.inf
>>>>>>>>>
>>>>>>>>> OvmfPkg/VirtioNetDxe/VirtioNet.inf
>>>>>>>>>
>>>>>>>>> OvmfPkg/VirtioRngDxe/VirtioRng.inf
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> [2] /Volumes/Case/edk2-github/OvmfPkg>git grep APPLICATION --
>>>>>>>>> *.inf
>>>>>>>>> |
>>>>>>>>> grep MODULE_TYPE
>>>>>>>>>
>>>>>>>>> EnrollDefaultKeys/EnrollDefaultKeys.inf:13:  MODULE_TYPE
>>>>>>>>>   = UEFI_APPLICATION
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Andrew Fish
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>   On 3/30/21, Ethin Probst via groups.io <http://groups.io/>
>>>>>>>>> <http://groups.io/ <http://groups.io/>>
>>>>>>>>> <http://groups.io/ <http://groups.io/> <http://groups.io/
>>>>>>>>> <http://groups.io/>>>
>>>>>>>>> <http://groups.io/ <http://groups.io/> <http://groups.io/
>>>>>>>>> <http://groups.io/>> <http://groups.io/ <http://groups.io/>
>>>>>>>>> <http://groups.io/ <http://groups.io/>>>>
>>>>>>>>>   <harlydavidsen=gmail.com@groups.io
>>>>>>>>> <mailto:harlydavidsen=gmail.com@groups.io>
>>>>>>>>> <mailto:harlydavidsen=gmail.com@groups.io
>>>>>>>>> <mailto:harlydavidsen=gmail.com@groups.io>>
>>>>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>
>>>>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>>>
>>>>>>>>>   <mailto:harlydavidsen <mailto:harlydavidsen>=gmail.com@groups.io
>>>>>>>>> <mailto:gmail.com@groups.io>
>>>>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>>
>>>>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>
>>>>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>       I agree. Plus, it gives me a chance to finally learn the
>>>>>>>>> EDK2
>>>>>>>>> build
>>>>>>>>>       system and how it works! I've been working on a hobby OS as
>>>>>>>>> a
>>>>>>>>> side
>>>>>>>>>       project and, though learning from other code examples from
>>>>>>>>> OSes
>>>>>>>>> is
>>>>>>>>>       fun, I have to say that learning from the firmware code like
>>>>>>>>> from
>>>>>>>>>       SeaBIOS has been some of the most enlightening and
>>>>>>>>> interesting
>>>>>>>>> times
>>>>>>>>>       thus far.
>>>>>>>>>       Thanks for the link to your code, Rafael; once I get virtIO
>>>>>>>>> support
>>>>>>>>>       in, I can work on HDA support, though I might tackle USB
>>>>>>>>> support
>>>>>>>>>       second and HDA third. We'll see, but VirtIO definitely is
>>>>>>>>> coming
>>>>>>>>>       first.
>>>>>>>>>
>>>>>>>>>       As I said before, I look forward to working with all of you
>>>>>>>>>       wonderful
>>>>>>>>>       people!
>>>>>>>>>
>>>>>>>>>       On 3/30/21, Rafael Rodrigues Machado
>>>>>>>>>       <rafaelrodrigues.machado@gmail.com
>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>
>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>>
>>>>>>>>>       <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>
>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>>>>
>>>>>>>>>       wrote:
>>>>>>>>>
>>>>>>>>>           This would be amazing so people can continue my work
>>>>>>>>> related
>>>>>>>>> to
>>>>>>>>>           accessibility at BIOS. Something desired by the blind
>>>>>>>>> people
>>>>>>>>>           since the
>>>>>>>>>           90's
>>>>>>>>>           Just for reference, this is what I have done:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
>>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>
>>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
>>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>>
>>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
>>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>
>>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
>>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>>>
>>>>>>>>>
>>>>>>>>>           Thanks
>>>>>>>>>           Rafael
>>>>>>>>>
>>>>>>>>>           Em seg, 29 de mar de 2021 20:24, Ethin Probst
>>>>>>>>>           <harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>> <mailto:harlydavidsen@gmail.com>>>>
>>>>>>>>>           escreveu:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>               Hello everyone,
>>>>>>>>>
>>>>>>>>>               This is the first time I've ever contributed to
>>>>>>>>> EDK2.
>>>>>>>>> As
>>>>>>>>>               part of GSoC
>>>>>>>>>               2021, I have submitted a proposal to implement a
>>>>>>>>> UEFI
>>>>>>>>>               audio output
>>>>>>>>>               protocol that will utilize the VirtIO sound driver.
>>>>>>>>> I've
>>>>>>>>>               already
>>>>>>>>>               submitted a draft proposal, and apologize if I've
>>>>>>>>> done
>>>>>>>>>               things out of
>>>>>>>>>               order. This is my first time doing GSoC 2021, and
>>>>>>>>>               contributing to EDK2
>>>>>>>>>               felt like a really fun thing to do!
>>>>>>>>>
>>>>>>>>>               I look forward to working with you guys on this and
>>>>>>>>> any
>>>>>>>>>               future projects!
>>>>>>>>>               :-)
>>>>>>>>>
>>>>>>>>>               --
>>>>>>>>>               Signed,
>>>>>>>>>               Ethin D. Probst
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>       --
>>>>>>>>>       Signed,
>>>>>>>>>       Ethin D. Probst
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>   --
>>>>>>>>>   Signed,
>>>>>>>>>   Ethin D. Probst
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Signed,
>>>>>>> Ethin D. Probst
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Signed,
>>>>> Ethin D. Probst
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Signed,
>>> Ethin D. Probst
>>>
>>>
>>> 
>>>
>>>
>>>
>>
>>
>> --
>> Signed,
>> Ethin D. Probst
>
>


-- 
Signed,
Ethin D. Probst

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Michael D Kinney]

Hi Ethin,

Most UEFI Drivers do use polling.

If it is a blocking I/O operation the UEFI Driver waits for completion.  Typically by polling a status register until the I/O is complete and then return status.

If it is a non-blocking I/O Operation, then the UEFI Driver can create a timer event to periodically check the completion status.  

Non-blocking APIs may also use an event to know when the I/O operation is completed and this can be used with the CheckEvent() service to poll for event completion.

These concepts are discussed in the UEFI Driver Writer's Guide.

https://tianocore-docs.github.io/edk2-UefiDriverWritersGuide/draft/edk2-UefiDriverWritersGuide-draft.pdf

Specifically for audio.  If there is an audio playback buffer that will take some time to send,
the Audio Protocol would likely define a non-blocking interface to start playback.  You may need
an event that is signaled when more audio data is needed or when the playback is complete.  You
will need to think about the consumer of the Audio Protocol and how it will interact with the 
Audio Protocol and if the consumer also needs to do other activities while audio is playing or
if it is ok for the consumer to wait until the audio playback is completed.

Mike

> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Ethin Probst
> Sent: Wednesday, April 14, 2021 1:48 PM
> To: Andrew Fish <afish@apple.com>
> Cc: edk2-devel-groups-io <devel@edk2.groups.io>; Leif Lindholm <leif@nuviainc.com>; Laszlo Ersek <lersek@redhat.com>;
> Desimone, Nathaniel L <nathaniel.l.desimone@intel.com>; Rafael Rodrigues Machado <rafaelrodrigues.machado@gmail.com>; Gerd
> Hoffmann <kraxel@redhat.com>
> Subject: Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)
> 
> These are some pretty good suggestions; however, while reading through
> the VirtIO specification again yesterday, I (re)-discovered that
> VirtIO devices are usually interrupt based. In particular, a VirtIO
> PCI/PCIe device defines the common, notifications, ISR status,
> device-specific configuration, PCI configuration access, shared memory
> region, and vendor-specific data capability structures in PCI
> configuration space. It doesn't look like the EFI_CREATE_EVENT or
> EFI_CREATE_EVENT_EX function works via interrupts, from what I can
> tell. I'm not sure but it doesn't seem like there's a way I can poll
> the device, though I might be missing something.
> The idea for the generic protocol is good. The interrupt issue might
> be a problem though and I'm not sure how to actually solve that.
> 
> On 4/13/21, Andrew Fish <afish@apple.com> wrote:
> > Ethin,
> >
> > In terms of defining the protocol stack it is good to start with the
> > producers and consumers and think about the problem from both perspectives.
> > It is easy enough to think about the producer part of it as you are thinking
> > about writing the driver. The driver is going to consume things like the PCI
> > I/O Protocol.
> >
> > The consumer of the sound Protocol is going to most likely be generic EFI
> > platform code, and possibly an OS loader. In the boot process Audio has
> > traditionally be used for error codes, sign of life (for example the famous
> > Mac startup sound). We are also would like to have the option of enabling
> > better accessibility features, especially for people how are visually
> > impaired. These days a lot of software engineers think of disk space as free
> > and really don’t consider the size of software, but this is not true for
> > firmware. Firmware generally lives in NOR FLASH that is considered expensive
> > (it is more expensive than NAND, but at the same time more reliable) so
> > firmware implementations are constrained by the size of the code that can be
> > carried, and the size of assets/resources that can be used for user
> > interfaces. The OS loader is some what less constrained, but it still has to
> > share the EFI System Partition on the disk with potentially other OS
> > loaders.
> >
> > So the consumer wants a protocol that is unleveled and focused on the task
> > at hand. I’m not too caught up on the names but in general I think things
> > you want are (How many knobs we need is probably better answered by an
> > audiophile, and that is not me):
> > 1) CompatibleBuffer() - Does driver support this buffer format.
> > 2) PlayBuffer() - Play the sound
> > 	a) We probably want a synchronous and asynchronous version of this API. For
> > example you don’t want to slow down the boot to wait for a boot beep to
> > complete, and you may chose to implement an API that waits for the sound to
> > complete (and do some GUI work in parallel) vs. blocking on the sound.
> > 	b) async in EFI usually means you return a pointer to an EFI_EVENT that
> > gets signaled on completion.
> > 3) StopBuffer() - In case the asynchronous PlayBuffer() needs to be stopped.
> > Think error exit.
> > 3) SetVolume()/GetVolume() - Set/Get Volume in units of 0 - 100 (trying to
> > avoid db as that gets into capability and math that is likely best
> > abstracted by the driver)?
> > 4) Mute()/UnMute() - Mute and volume are often independent features in a UI
> > keeping them separate in API makes it easier to implement things.
> > 5) PlayTone() - Maybe for error sounds that don’t require canned sound
> > files. Maybe TimeOn, TimeOff, Frequency, and how many times to repeat.
> > 6) Do we need tuning values or Tone settings?
> >
> > At some point we might consider defining nvram variable for the default
> > state of some of the tunable, especially mute and volume. For example the
> > user may want to turn off all volume on the system so it would be nice if
> > the OS can set the EFI volume and mute. In the short run we can probably use
> > PCD values to set the default values.
> >
> > So I think we have a generic AUDIO API on top and likely a PCI I/O on the
> > bottom. If we need more protocols to manage hardware devices then those
> > protocols can be defined in the context of that hardware. So for example we
> > would probably end up with an HDA_CODEC protocol. I think the best way to
> > think about this is a disk. A lot of disk adapters just produce a raw Block
> > I/O  protocol, but for a more common bus like ATA or SCSI you might have an
> > extra driver in place to make the common bits common code. I think some of
> > the same layers may be in place here. So likely VirtIo is simple and just
> > produces the generic AUDIO API, while an HDA audio driver also has to
> > abstract some of the complexity of its hardware implementation and standard.
> >
> >
> > In terms of picking the set of APIs and tunables it is probably good to
> > start with VirtIo and USB and see what set make sense and what you could and
> > could not implement. HDA Audio is so complex you might want to look at it in
> > terms of the minute you have to implement to make it function. Think what
> > assumptions are you forced to make to implement.
> >
> > This is a vey 10,000 foot view to start with. I think you will need to mix
> > this in the the reality of how it works in the real world to figure out the
> > right abstraction, but then again that is the beauty of having an
> > implementation. Likely also get some feedback from audiophiles.
> >
> > Oh and make sure you don’t go off an implement a lot of code just because we
> > chose the wrong complexity or abstraction point. This is the one time we get
> > to change the public APIs so lets feel free to adjust them to make the most
> > sense for the job at hand.
> >
> > Thanks,
> >
> > Andrew Fish
> >
> >> On Apr 13, 2021, at 6:20 PM, Ethin Probst <harlydavidsen@gmail.com>
> >> wrote:
> >>
> >> Okay, so looking at the EDK2 driver developers guide, here are my
> >> thoughts:
> >>
> >> - Each audio driver will be a bus driver, even if it doesn't control
> >> buses in the traditional sense.
> >> - I think the initialization sequence should be different: there
> >> should be an AudioDxe, but it should contain three separate bus
> >> drivers for each kind of audio device supported.
> >> - For the VirtIO audio device driver, it'll most likely consume the
> >> PCI I/O protocol and produce the EFI_VIRTIO_AUDIO_OUTPUT_PROTOCOL and
> >> EFI_VIRTIO_AUDIO_INPUT_PROTOCOL protocols. This will just be an
> >> ordinary UEFI device driver.
> >> - The HDA audio device driver will consume the PCI I/O protocol and
> >> will produce different device handles per HDA controller found. I'd
> >> produce a handle per codec, but that seems overkill. Each handle will
> >> be attached to both an audio stream protocol and a controller
> >> management protocol. The audio stream protocol will manage the
> >> creation, control, and deletion of audio streams as well as the
> >> processing of audio data. The controller management protocol is
> >> responsible for allowing applications or other drivers to manage the
> >> HDA controller itself.
> >>
> >> I haven't planned for the USB audio device driver yet, but these are
> >> my thoughts so far. What do you guys think? Am I over-complicating
> >> this setup? How can it be improved upon?
> >>
> >> On 4/13/21, Ethin Probst via groups.io <http://groups.io/>
> >> <harlydavidsen=gmail.com@groups.io
> >> <mailto:harlydavidsen=gmail.com@groups.io>> wrote:
> >>> Hi Andrew,
> >>>
> >>> The developer guide for EDK2 drivers is a godsend. Thank you very
> >>> much, and thank you, Mike, for your excellent work on the guide! I may
> >>> just ahve to do my building on Linux and not Windows -- unless the Bug
> >>> -- bug 3302 -- has been fixed. I'll have to do testing on Linux, at
> >>> any rate, since Windows hosts do not support VirtIO emulation and I
> >>> can't seem to find any way of emulating them in a guest machine with
> >>> Windows as a host.
> >>>
> >>> On 4/13/21, Andrew Fish <afish@apple.com <mailto:afish@apple.com>>
> >>> wrote:
> >>>>
> >>>>
> >>>>> On Apr 13, 2021, at 9:53 AM, Ethin Probst <harlydavidsen@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>> Would it be possible for us to conduct discussion on the UEFI talkbox?
> >>>>> I don't mind using email, but things could definitely get moving
> >>>>> quicker over there (though its not a requirement obviously).
> >>>>>
> >>>>
> >>>> Sure, don’t think I’ve really used that but as long as I get pointed
> >>>> int
> >>>> he
> >>>> right direction I can make it work.
> >>>>
> >>>> For a device driver the general UEFI model is for the Entry point of
> >>>> the
> >>>> driver to publish a EFI_DRIVER_BINDING_PROTOCOL[1]. The Supported()
> >>>> function
> >>>> matches on the PCI devices. The Start() function installs the Protocols
> >>>> to
> >>>> do work, and the Stop() undoes the Start().
> >>>>
> >>>> Mike Kinney started this back in the day and it describes how to write
> >>>> UEFI
> >>>> drivers:
> >>>> https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Driver-Writer%27s-Guide
> >>>>
> >>>> [1]https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/DriverBinding.h#L157
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Andrew Fish
> >>>>
> >>>>> Here's how I generally envision the driver functioning:
> >>>>>
> >>>>> 1. Firmware/platform code calls InitaudioOutput() or something like
> >>>>> it. This function scans the PCIe bus and scans for one of the
> >>>>> following:
> >>>>> - Vendor ID 0x1AF4, device ID 0x1059: VirtIO sound device
> >>>>> - PCI class 0x0C, subclass 0x03, program interface 0x30 or 0x40: for
> >>>>> USB audio interface (I'm only thinking of targeting XHCI and USB 4,
> >>>>> and not UHCI, OHCI or EHCI). But maybe EDK2 will take that out of my
> >>>>> hands. If so, it will make things easier.
> >>>>> - For USB audio devices I'm not quite sure what to look for; I'm
> >>>>> definitely unused to USB.
> >>>>> 2. If any of the above cases are found, appropriate driver
> >>>>> initialization occurs. Since for the time being I am solely focusing
> >>>>> on VirtIO sound devices, the VirtIO general initialization sequence
> >>>>> will occur as outlined in sec. 3 of the VirtIO specification available
> >>>>> at https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html
> >>>>> <https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html
> >>>>> <https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html>>.
> >>>>> As for actual protocol exposure that would be spec-worthy, for
> >>>>> EFI_AUDIO_OUTPUT_PROTOCOL, I'm not quite sure what to expose. VirtIO
> >>>>> is rather simple: there's a buffer for sending and receiving audio
> >>>>> data in PCM streams. So for that we could expose a Reset(),
> >>>>> RemapJack(), GetJackConfig(), GetPcmConfig(), SetPcmParams(),
> >>>>> Prepare(), Release(), Start(), and Stop() function for the
> >>>>> corresponding request types VIRTIO_SND_R_JACK_GET_CONFIG,
> >>>>> VIRTIO_SND_R_JACK_REMAP, VIRTIO_SND_R_PCM_GET_CONFIG,
> >>>>> VIRTIO_SND_R_PCM_SET_PARAMS, VIRTIO_SND_R_PCM_PREPARE,
> >>>>> VIRTIO_SND_R_PCM_RELEASE, VIRTIO_SND_R_PCM_START, and
> >>>>> VIRTIO_SND_R_PCM_STOP control requests. However, for HDA things are a
> >>>>> lot more complex, so I'm not sure how that should work.
> >>>>> For VirtIO -- which is what I'll focus on for now -- everything is
> >>>>> described, in excellent detail, in sec. 5.14 of the above-linked
> >>>>> document. What are your guys's thoughts thus far and how should
> >>>>> everything be mapped to UEFI interfaces?
> >>>>>
> >>>>> On 4/13/21, Andrew Fish <afish@apple.com <mailto:afish@apple.com>
> >>>>> <mailto:afish@apple.com <mailto:afish@apple.com>>>
> >>>>> wrote:
> >>>>>> Leif,
> >>>>>>
> >>>>>> Since I have put some brain cells around this area in the past I can
> >>>>>> be
> >>>>>> the
> >>>>>> backup and help out too.
> >>>>>>
> >>>>>> I’d also point out if you are having issues building or have general
> >>>>>> questions on how things work it is fine to use the mailing list. I’ve
> >>>>>> got
> >>>>>> a
> >>>>>> lot of feedback that folks read or search the mailing list looking
> >>>>>> for
> >>>>>> answer to their questions so one person asking can help out a lot of
> >>>>>> other
> >>>>>> people.
> >>>>>>
> >>>>>> Thanks,
> >>>>>>
> >>>>>> Andrew Fish
> >>>>>>
> >>>>>>> On Apr 13, 2021, at 5:28 AM, Leif Lindholm <leif@nuviainc.com
> >>>>>>> <mailto:leif@nuviainc.com>> wrote:
> >>>>>>>
> >>>>>>> Hi all, especially Ethin.
> >>>>>>>
> >>>>>>> Apologies for radio silence - last week I was off on holiday, and
> >>>>>>> before
> >>>>>>> that ... let's just say corporate acquisitions generate some
> >>>>>>> distractions.
> >>>>>>> Anyway, I'm back, and since I'm down as the mentor for this task,
> >>>>>>> feel
> >>>>>>> free to spam me with any remaining/new questions.
> >>>>>>>
> >>>>>>> /
> >>>>>>>   Leif
> >>>>>>>
> >>>>>>> On Tue, Apr 6, 2021 at 4:17 PM Ethin Probst <harlydavidsen@gmail.com
> >>>>>>> <mailto:harlydavidsen@gmail.com>
> >>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
> >>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>>
> >>>>>>> wrote:
> >>>>>>> I'll attach the bug for the build tools to the BZ shortly.
> >>>>>>> Laszlo, thanks for that. I don't know their email addresses though.
> >>>>>>> And yes, I was going to make it device independent, as the majority
> >>>>>>> (if not all) of UEFI protocols are.
> >>>>>>>
> >>>>>>> On 4/6/21, Laszlo Ersek <lersek@redhat.com <mailto:lersek@redhat.com>
> >>>>>>> <mailto:lersek@redhat.com <mailto:lersek@redhat.com>>
> >>>>>>> <mailto:lersek@redhat.com <mailto:lersek@redhat.com>
> >>>>>>> <mailto:lersek@redhat.com <mailto:lersek@redhat.com>>>>
> >>>>>>> wrote:
> >>>>>>>> On 03/31/21 08:41, Nate DeSimone wrote:
> >>>>>>>>> Another option is to put the protocol definition in MdeModulePkg
> >>>>>>>>> and
> >>>>>>>>> mark it with the EDKII_ prefix. For my last “code first” UEFI spec
> >>>>>>>>> contribution I did this with the PPI that added up getting added.
> >>>>>>>>
> >>>>>>>> The new audio protocol should be generic, only its implementation
> >>>>>>>> in
> >>>>>>>> question should be virtio specific.
> >>>>>>>>
> >>>>>>>> Please include Gerd Hoffmann (CC'd) in the protocol design, as well
> >>>>>>>> as
> >>>>>>>> the developers of the virtio-sound device model in QEMU.
> >>>>>>>>
> >>>>>>>> Thanks
> >>>>>>>> Laszlo
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>>
> >>>>>>>>> Nate
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> *From: *<devel@edk2.groups.io <mailto:devel@edk2.groups.io>
> >>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
> >>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
> >>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>>> on
> >>>>>>>>> behalf
> >>>>>>>>> of "Andrew Fish via groups.io <http://groups.io/>
> >>>>>>>>> <http://groups.io/ <http://groups.io/>> <http://groups.io/
> >>>>>>>>> <http://groups.io/>
> >>>>>>>>> <http://groups.io/ <http://groups.io/>>>"
> >>>>>>>>> <afish=apple.com@groups.io <mailto:afish=apple.com@groups.io>
> >>>>>>>>> <mailto:afish=apple.com@groups.io
> >>>>>>>>> <mailto:afish=apple.com@groups.io>>
> >>>>>>>>> <mailto:apple.com@groups.io <mailto:apple.com@groups.io>
> >>>>>>>>> <mailto:apple.com@groups.io <mailto:apple.com@groups.io>>>>
> >>>>>>>>> *Reply-To: *"devel@edk2.groups.io <mailto:devel@edk2.groups.io>
> >>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
> >>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
> >>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>>"
> >>>>>>>>> <devel@edk2.groups.io <mailto:devel@edk2.groups.io>
> >>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
> >>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
> >>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>>>,
> >>>>>>>>> "afish@apple.com <mailto:afish@apple.com> <mailto:afish@apple.com
> >>>>>>>>> <mailto:afish@apple.com>> <mailto:afish@apple.com
> >>>>>>>>> <mailto:afish@apple.com>
> >>>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>>>"
> >>>>>>>>> <afish@apple.com <mailto:afish@apple.com> <mailto:afish@apple.com
> >>>>>>>>> <mailto:afish@apple.com>>
> >>>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>
> >>>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>>>>
> >>>>>>>>> *Date: *Tuesday, March 30, 2021 at 10:54 PM
> >>>>>>>>> *To: *edk2-devel-groups-io <devel@edk2.groups.io
> >>>>>>>>> <mailto:devel@edk2.groups.io>
> >>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
> >>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
> >>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>>>,
> >>>>>>>>> "harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
> >>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
> >>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
> >>>>>>>>> <mailto:harlydavidsen@gmail.com
> >>>>>>>>> <mailto:harlydavidsen@gmail.com>>>"
> >>>>>>>>> <harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
> >>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
> >>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
> >>>>>>>>> <mailto:harlydavidsen@gmail.com
> >>>>>>>>> <mailto:harlydavidsen@gmail.com>>>>
> >>>>>>>>> *Cc: *Rafael Rodrigues Machado <rafaelrodrigues.machado@gmail.com
> >>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
> >>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
> >>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>
> >>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
> >>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
> >>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
> >>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>>>
> >>>>>>>>> *Subject: *Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>   On Mar 30, 2021, at 5:01 PM, Ethin Probst
> >>>>>>>>> <harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
> >>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
> >>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
> >>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>
> >>>>>>>>>   <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
> >>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
> >>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
> >>>>>>>>> <mailto:harlydavidsen@gmail.com
> >>>>>>>>> <mailto:harlydavidsen@gmail.com>>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>   I'm wondering where exactly I should add the VirtIO sound
> >>>>>>>>> protocol.
> >>>>>>>>> I
> >>>>>>>>>   just familiarized myself with the build system and am about to
> >>>>>>>>> test
> >>>>>>>>> it
> >>>>>>>>>   by building OVMF if possible, but I'm wondering where I should
> >>>>>>>>>   actually put the protocol and all that stuff. Maybe there's
> >>>>>>>>>   documentation I've missed as well.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Ethin,
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> For the driver I’d match the patter of OVMF [1] and use
> >>>>>>>>> OvmfPkg/VirtioSoundDxe/. Maybe even use one of the other drivers
> >>>>>>>>> as
> >>>>>>>>> a
> >>>>>>>>> template.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> The protocol is more of a public thing. I think eventually we
> >>>>>>>>> would
> >>>>>>>>> like
> >>>>>>>>> to publish the protocol in the UEFI Spec (I can help with that
> >>>>>>>>> part)
> >>>>>>>>> and
> >>>>>>>>> that would mean we put the Protocol definition in
> >>>>>>>>> MdePkg/Include/Protocol, but we don’t want to do that before it is
> >>>>>>>>> standardized as that causes compatibility issues. So this is a
> >>>>>>>>> “code
> >>>>>>>>> first project” (code prototype and then contribute to the UEFI
> >>>>>>>>> Forum
> >>>>>>>>> for
> >>>>>>>>> inclusion in the specification) so we need to follow some code
> >>>>>>>>> first
> >>>>>>>>> rules that I don’t remember of the top of my head? So why not
> >>>>>>>>> start
> >>>>>>>>> out
> >>>>>>>>> the protocol definition OvmfPkg/Include/Protocol. You can also add
> >>>>>>>>> a
> >>>>>>>>> test application looks like you can just use the root [2] of OVMF
> >>>>>>>>> for
> >>>>>>>>> that. That way the project is not blocked.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> We can have a conversation on the mailing list about better places
> >>>>>>>>> to
> >>>>>>>>> put stuff, and it should be easy enough to move stuff around if
> >>>>>>>>> everything else is working.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> [1] find OvmfPkg  -iname '*Virtio*.inf'
> >>>>>>>>>
> >>>>>>>>> OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
> >>>>>>>>>
> >>>>>>>>> OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
> >>>>>>>>>
> >>>>>>>>> OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf
> >>>>>>>>>
> >>>>>>>>> OvmfPkg/Library/VirtioLib/VirtioLib.inf
> >>>>>>>>>
> >>>>>>>>> OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
> >>>>>>>>>
> >>>>>>>>> OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
> >>>>>>>>>
> >>>>>>>>> OvmfPkg/Virtio10Dxe/Virtio10.inf
> >>>>>>>>>
> >>>>>>>>> OvmfPkg/VirtioNetDxe/VirtioNet.inf
> >>>>>>>>>
> >>>>>>>>> OvmfPkg/VirtioRngDxe/VirtioRng.inf
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> [2] /Volumes/Case/edk2-github/OvmfPkg>git grep APPLICATION --
> >>>>>>>>> *.inf
> >>>>>>>>> |
> >>>>>>>>> grep MODULE_TYPE
> >>>>>>>>>
> >>>>>>>>> EnrollDefaultKeys/EnrollDefaultKeys.inf:13:  MODULE_TYPE
> >>>>>>>>>   = UEFI_APPLICATION
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Andrew Fish
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>   On 3/30/21, Ethin Probst via groups.io <http://groups.io/>
> >>>>>>>>> <http://groups.io/ <http://groups.io/>>
> >>>>>>>>> <http://groups.io/ <http://groups.io/> <http://groups.io/
> >>>>>>>>> <http://groups.io/>>>
> >>>>>>>>> <http://groups.io/ <http://groups.io/> <http://groups.io/
> >>>>>>>>> <http://groups.io/>> <http://groups.io/ <http://groups.io/>
> >>>>>>>>> <http://groups.io/ <http://groups.io/>>>>
> >>>>>>>>>   <harlydavidsen=gmail.com@groups.io
> >>>>>>>>> <mailto:harlydavidsen=gmail.com@groups.io>
> >>>>>>>>> <mailto:harlydavidsen=gmail.com@groups.io
> >>>>>>>>> <mailto:harlydavidsen=gmail.com@groups.io>>
> >>>>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>
> >>>>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>>>
> >>>>>>>>>   <mailto:harlydavidsen <mailto:harlydavidsen>=gmail.com@groups.io
> >>>>>>>>> <mailto:gmail.com@groups.io>
> >>>>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>>
> >>>>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>
> >>>>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>       I agree. Plus, it gives me a chance to finally learn the
> >>>>>>>>> EDK2
> >>>>>>>>> build
> >>>>>>>>>       system and how it works! I've been working on a hobby OS as
> >>>>>>>>> a
> >>>>>>>>> side
> >>>>>>>>>       project and, though learning from other code examples from
> >>>>>>>>> OSes
> >>>>>>>>> is
> >>>>>>>>>       fun, I have to say that learning from the firmware code like
> >>>>>>>>> from
> >>>>>>>>>       SeaBIOS has been some of the most enlightening and
> >>>>>>>>> interesting
> >>>>>>>>> times
> >>>>>>>>>       thus far.
> >>>>>>>>>       Thanks for the link to your code, Rafael; once I get virtIO
> >>>>>>>>> support
> >>>>>>>>>       in, I can work on HDA support, though I might tackle USB
> >>>>>>>>> support
> >>>>>>>>>       second and HDA third. We'll see, but VirtIO definitely is
> >>>>>>>>> coming
> >>>>>>>>>       first.
> >>>>>>>>>
> >>>>>>>>>       As I said before, I look forward to working with all of you
> >>>>>>>>>       wonderful
> >>>>>>>>>       people!
> >>>>>>>>>
> >>>>>>>>>       On 3/30/21, Rafael Rodrigues Machado
> >>>>>>>>>       <rafaelrodrigues.machado@gmail.com
> >>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
> >>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
> >>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>
> >>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
> >>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
> >>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
> >>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>>
> >>>>>>>>>       <mailto:rafaelrodrigues.machado@gmail.com
> >>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
> >>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
> >>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>
> >>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
> >>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
> >>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
> >>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>>>>
> >>>>>>>>>       wrote:
> >>>>>>>>>
> >>>>>>>>>           This would be amazing so people can continue my work
> >>>>>>>>> related
> >>>>>>>>> to
> >>>>>>>>>           accessibility at BIOS. Something desired by the blind
> >>>>>>>>> people
> >>>>>>>>>           since the
> >>>>>>>>>           90's
> >>>>>>>>>           Just for reference, this is what I have done:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
> >>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>
> >>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
> >>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>>
> >>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
> >>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>
> >>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
> >>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>>>
> >>>>>>>>>
> >>>>>>>>>           Thanks
> >>>>>>>>>           Rafael
> >>>>>>>>>
> >>>>>>>>>           Em seg, 29 de mar de 2021 20:24, Ethin Probst
> >>>>>>>>>           <harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
> >>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
> >>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
> >>>>>>>>> <mailto:harlydavidsen@gmail.com
> >>>>>>>>> <mailto:harlydavidsen@gmail.com>>>>
> >>>>>>>>>           escreveu:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>               Hello everyone,
> >>>>>>>>>
> >>>>>>>>>               This is the first time I've ever contributed to
> >>>>>>>>> EDK2.
> >>>>>>>>> As
> >>>>>>>>>               part of GSoC
> >>>>>>>>>               2021, I have submitted a proposal to implement a
> >>>>>>>>> UEFI
> >>>>>>>>>               audio output
> >>>>>>>>>               protocol that will utilize the VirtIO sound driver.
> >>>>>>>>> I've
> >>>>>>>>>               already
> >>>>>>>>>               submitted a draft proposal, and apologize if I've
> >>>>>>>>> done
> >>>>>>>>>               things out of
> >>>>>>>>>               order. This is my first time doing GSoC 2021, and
> >>>>>>>>>               contributing to EDK2
> >>>>>>>>>               felt like a really fun thing to do!
> >>>>>>>>>
> >>>>>>>>>               I look forward to working with you guys on this and
> >>>>>>>>> any
> >>>>>>>>>               future projects!
> >>>>>>>>>               :-)
> >>>>>>>>>
> >>>>>>>>>               --
> >>>>>>>>>               Signed,
> >>>>>>>>>               Ethin D. Probst
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>       --
> >>>>>>>>>       Signed,
> >>>>>>>>>       Ethin D. Probst
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>   --
> >>>>>>>>>   Signed,
> >>>>>>>>>   Ethin D. Probst
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Signed,
> >>>>>>> Ethin D. Probst
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Signed,
> >>>>> Ethin D. Probst
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Signed,
> >>> Ethin D. Probst
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >> --
> >> Signed,
> >> Ethin D. Probst
> >
> >
> 
> 
> --
> Signed,
> Ethin D. Probst
> 
> 
> 
> 

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Andrew Fish]

[-- Attachment #1: Type: text/plain, Size: 33826 bytes --]



> On Apr 14, 2021, at 3:30 PM, Kinney, Michael D <michael.d.kinney@intel.com> wrote:
> 
> Hi Ethin,
> 
> Most UEFI Drivers do use polling.
> 
> If it is a blocking I/O operation the UEFI Driver waits for completion.  Typically by polling a status register until the I/O is complete and then return status.
> 
> If it is a non-blocking I/O Operation, then the UEFI Driver can create a timer event to periodically check the completion status.
> 
> Non-blocking APIs may also use an event to know when the I/O operation is completed and this can be used with the CheckEvent() service to poll for event completion.
> 
> These concepts are discussed in the UEFI Driver Writer's Guide.
> 
> https://tianocore-docs.github.io/edk2-UefiDriverWritersGuide/draft/edk2-UefiDriverWritersGuide-draft.pdf <https://tianocore-docs.github.io/edk2-UefiDriverWritersGuide/draft/edk2-UefiDriverWritersGuide-draft.pdf>
> 
> Specifically for audio.  If there is an audio playback buffer that will take some time to send,
> the Audio Protocol would likely define a non-blocking interface to start playback.  You may need
> an event that is signaled when more audio data is needed or when the playback is complete.  You
> will need to think about the consumer of the Audio Protocol and how it will interact with the 
> Audio Protocol and if the consumer also needs to do other activities while audio is playing or
> if it is ok for the consumer to wait until the audio playback is completed.
> 

Mike,

It is likely we want async and synchronous playback. If you are playing a boot bong you don’t want to block on its completion. If you are doing a GUI UI you don’t want to block on playback and then do a bunch of GUI math etc. 

Ethin,

I’d take a look at some example drivers like VirtioBlkDxe[1]. It also looks like there is already a VirtioLib[2] to help with house keeping. I did a quick skim and I don’t see a VirtIo device with an Event driven API.  It looks like VirtioNetDxe[3] does have the concept of a callback to poll [4], so you might be able to leverage that concept into a timer event to check for completion. 

I’d not get hung up on the asynchronous part of the API. It might make sense to implement the synchronous version of the API in the driver 1st and fake the async for your 1st pass. 

If you look at other UEFI Async APIs they generally pass around a Token (usually an Event to signal on completion, and an EFI_STATUS)[5]. Thus faking the Async means making it look like the event fired before your API returned. Assuming that *Token is an argument to the protocol you do this to fake the Async transaction….

If (Token != NULL) {
  Token->TransactionStatus = Status;
  gBS->SignalEvent (Token->Event);
}

This just make it look to the caller like the transaction completed by the time you returned to the caller. So from a caller perspective that is a valid way the API could work. The other upside to this is you can make a UEFI Shell App to test the protocol and also add a path to test the async API, even if for the 1st pass implementation that is faked out. 

[1] https://github.com/tianocore/edk2/tree/master/OvmfPkg/VirtioBlkDxe
[2] https://github.com/tianocore/edk2/blob/master/OvmfPkg/Library/VirtioLib/VirtioLib.c
[3] https://github.com/tianocore/edk2/tree/master/OvmfPkg/VirtioNetDxe
[4] https://github.com/tianocore/edk2/blob/master/OvmfPkg/VirtioNetDxe/Events.c#L32
[5] https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/BlockIo2.h#L41

Thanks,

Andrew Fish

> Mike
> 
>> -----Original Message-----
>> From: devel@edk2.groups.io <mailto:devel@edk2.groups.io> <devel@edk2.groups.io <mailto:devel@edk2.groups.io>> On Behalf Of Ethin Probst
>> Sent: Wednesday, April 14, 2021 1:48 PM
>> To: Andrew Fish <afish@apple.com <mailto:afish@apple.com>>
>> Cc: edk2-devel-groups-io <devel@edk2.groups.io <mailto:devel@edk2.groups.io>>; Leif Lindholm <leif@nuviainc.com <mailto:leif@nuviainc.com>>; Laszlo Ersek <lersek@redhat.com <mailto:lersek@redhat.com>>;
>> Desimone, Nathaniel L <nathaniel.l.desimone@intel.com <mailto:nathaniel.l.desimone@intel.com>>; Rafael Rodrigues Machado <rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>>; Gerd
>> Hoffmann <kraxel@redhat.com <mailto:kraxel@redhat.com>>
>> Subject: Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)
>> 
>> These are some pretty good suggestions; however, while reading through
>> the VirtIO specification again yesterday, I (re)-discovered that
>> VirtIO devices are usually interrupt based. In particular, a VirtIO
>> PCI/PCIe device defines the common, notifications, ISR status,
>> device-specific configuration, PCI configuration access, shared memory
>> region, and vendor-specific data capability structures in PCI
>> configuration space. It doesn't look like the EFI_CREATE_EVENT or
>> EFI_CREATE_EVENT_EX function works via interrupts, from what I can
>> tell. I'm not sure but it doesn't seem like there's a way I can poll
>> the device, though I might be missing something.
>> The idea for the generic protocol is good. The interrupt issue might
>> be a problem though and I'm not sure how to actually solve that.
>> 
>> On 4/13/21, Andrew Fish <afish@apple.com> wrote:
>>> Ethin,
>>> 
>>> In terms of defining the protocol stack it is good to start with the
>>> producers and consumers and think about the problem from both perspectives.
>>> It is easy enough to think about the producer part of it as you are thinking
>>> about writing the driver. The driver is going to consume things like the PCI
>>> I/O Protocol.
>>> 
>>> The consumer of the sound Protocol is going to most likely be generic EFI
>>> platform code, and possibly an OS loader. In the boot process Audio has
>>> traditionally be used for error codes, sign of life (for example the famous
>>> Mac startup sound). We are also would like to have the option of enabling
>>> better accessibility features, especially for people how are visually
>>> impaired. These days a lot of software engineers think of disk space as free
>>> and really don’t consider the size of software, but this is not true for
>>> firmware. Firmware generally lives in NOR FLASH that is considered expensive
>>> (it is more expensive than NAND, but at the same time more reliable) so
>>> firmware implementations are constrained by the size of the code that can be
>>> carried, and the size of assets/resources that can be used for user
>>> interfaces. The OS loader is some what less constrained, but it still has to
>>> share the EFI System Partition on the disk with potentially other OS
>>> loaders.
>>> 
>>> So the consumer wants a protocol that is unleveled and focused on the task
>>> at hand. I’m not too caught up on the names but in general I think things
>>> you want are (How many knobs we need is probably better answered by an
>>> audiophile, and that is not me):
>>> 1) CompatibleBuffer() - Does driver support this buffer format.
>>> 2) PlayBuffer() - Play the sound
>>> 	a) We probably want a synchronous and asynchronous version of this API. For
>>> example you don’t want to slow down the boot to wait for a boot beep to
>>> complete, and you may chose to implement an API that waits for the sound to
>>> complete (and do some GUI work in parallel) vs. blocking on the sound.
>>> 	b) async in EFI usually means you return a pointer to an EFI_EVENT that
>>> gets signaled on completion.
>>> 3) StopBuffer() - In case the asynchronous PlayBuffer() needs to be stopped.
>>> Think error exit.
>>> 3) SetVolume()/GetVolume() - Set/Get Volume in units of 0 - 100 (trying to
>>> avoid db as that gets into capability and math that is likely best
>>> abstracted by the driver)?
>>> 4) Mute()/UnMute() - Mute and volume are often independent features in a UI
>>> keeping them separate in API makes it easier to implement things.
>>> 5) PlayTone() - Maybe for error sounds that don’t require canned sound
>>> files. Maybe TimeOn, TimeOff, Frequency, and how many times to repeat.
>>> 6) Do we need tuning values or Tone settings?
>>> 
>>> At some point we might consider defining nvram variable for the default
>>> state of some of the tunable, especially mute and volume. For example the
>>> user may want to turn off all volume on the system so it would be nice if
>>> the OS can set the EFI volume and mute. In the short run we can probably use
>>> PCD values to set the default values.
>>> 
>>> So I think we have a generic AUDIO API on top and likely a PCI I/O on the
>>> bottom. If we need more protocols to manage hardware devices then those
>>> protocols can be defined in the context of that hardware. So for example we
>>> would probably end up with an HDA_CODEC protocol. I think the best way to
>>> think about this is a disk. A lot of disk adapters just produce a raw Block
>>> I/O  protocol, but for a more common bus like ATA or SCSI you might have an
>>> extra driver in place to make the common bits common code. I think some of
>>> the same layers may be in place here. So likely VirtIo is simple and just
>>> produces the generic AUDIO API, while an HDA audio driver also has to
>>> abstract some of the complexity of its hardware implementation and standard.
>>> 
>>> 
>>> In terms of picking the set of APIs and tunables it is probably good to
>>> start with VirtIo and USB and see what set make sense and what you could and
>>> could not implement. HDA Audio is so complex you might want to look at it in
>>> terms of the minute you have to implement to make it function. Think what
>>> assumptions are you forced to make to implement.
>>> 
>>> This is a vey 10,000 foot view to start with. I think you will need to mix
>>> this in the the reality of how it works in the real world to figure out the
>>> right abstraction, but then again that is the beauty of having an
>>> implementation. Likely also get some feedback from audiophiles.
>>> 
>>> Oh and make sure you don’t go off an implement a lot of code just because we
>>> chose the wrong complexity or abstraction point. This is the one time we get
>>> to change the public APIs so lets feel free to adjust them to make the most
>>> sense for the job at hand.
>>> 
>>> Thanks,
>>> 
>>> Andrew Fish
>>> 
>>>> On Apr 13, 2021, at 6:20 PM, Ethin Probst <harlydavidsen@gmail.com>
>>>> wrote:
>>>> 
>>>> Okay, so looking at the EDK2 driver developers guide, here are my
>>>> thoughts:
>>>> 
>>>> - Each audio driver will be a bus driver, even if it doesn't control
>>>> buses in the traditional sense.
>>>> - I think the initialization sequence should be different: there
>>>> should be an AudioDxe, but it should contain three separate bus
>>>> drivers for each kind of audio device supported.
>>>> - For the VirtIO audio device driver, it'll most likely consume the
>>>> PCI I/O protocol and produce the EFI_VIRTIO_AUDIO_OUTPUT_PROTOCOL and
>>>> EFI_VIRTIO_AUDIO_INPUT_PROTOCOL protocols. This will just be an
>>>> ordinary UEFI device driver.
>>>> - The HDA audio device driver will consume the PCI I/O protocol and
>>>> will produce different device handles per HDA controller found. I'd
>>>> produce a handle per codec, but that seems overkill. Each handle will
>>>> be attached to both an audio stream protocol and a controller
>>>> management protocol. The audio stream protocol will manage the
>>>> creation, control, and deletion of audio streams as well as the
>>>> processing of audio data. The controller management protocol is
>>>> responsible for allowing applications or other drivers to manage the
>>>> HDA controller itself.
>>>> 
>>>> I haven't planned for the USB audio device driver yet, but these are
>>>> my thoughts so far. What do you guys think? Am I over-complicating
>>>> this setup? How can it be improved upon?
>>>> 
>>>> On 4/13/21, Ethin Probst via groups.io <http://groups.io/>
>>>> <harlydavidsen=gmail.com@groups.io
>>>> <mailto:harlydavidsen=gmail.com@groups.io>> wrote:
>>>>> Hi Andrew,
>>>>> 
>>>>> The developer guide for EDK2 drivers is a godsend. Thank you very
>>>>> much, and thank you, Mike, for your excellent work on the guide! I may
>>>>> just ahve to do my building on Linux and not Windows -- unless the Bug
>>>>> -- bug 3302 -- has been fixed. I'll have to do testing on Linux, at
>>>>> any rate, since Windows hosts do not support VirtIO emulation and I
>>>>> can't seem to find any way of emulating them in a guest machine with
>>>>> Windows as a host.
>>>>> 
>>>>> On 4/13/21, Andrew Fish <afish@apple.com <mailto:afish@apple.com>>
>>>>> wrote:
>>>>>> 
>>>>>> 
>>>>>>> On Apr 13, 2021, at 9:53 AM, Ethin Probst <harlydavidsen@gmail.com>
>>>>>>> wrote:
>>>>>>> 
>>>>>>> Would it be possible for us to conduct discussion on the UEFI talkbox?
>>>>>>> I don't mind using email, but things could definitely get moving
>>>>>>> quicker over there (though its not a requirement obviously).
>>>>>>> 
>>>>>> 
>>>>>> Sure, don’t think I’ve really used that but as long as I get pointed
>>>>>> int
>>>>>> he
>>>>>> right direction I can make it work.
>>>>>> 
>>>>>> For a device driver the general UEFI model is for the Entry point of
>>>>>> the
>>>>>> driver to publish a EFI_DRIVER_BINDING_PROTOCOL[1]. The Supported()
>>>>>> function
>>>>>> matches on the PCI devices. The Start() function installs the Protocols
>>>>>> to
>>>>>> do work, and the Stop() undoes the Start().
>>>>>> 
>>>>>> Mike Kinney started this back in the day and it describes how to write
>>>>>> UEFI
>>>>>> drivers:
>>>>>> https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Driver-Writer%27s-Guide
>>>>>> 
>>>>>> [1]https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/DriverBinding.h#L157
>>>>>> 
>>>>>> Thanks,
>>>>>> 
>>>>>> Andrew Fish
>>>>>> 
>>>>>>> Here's how I generally envision the driver functioning:
>>>>>>> 
>>>>>>> 1. Firmware/platform code calls InitaudioOutput() or something like
>>>>>>> it. This function scans the PCIe bus and scans for one of the
>>>>>>> following:
>>>>>>> - Vendor ID 0x1AF4, device ID 0x1059: VirtIO sound device
>>>>>>> - PCI class 0x0C, subclass 0x03, program interface 0x30 or 0x40: for
>>>>>>> USB audio interface (I'm only thinking of targeting XHCI and USB 4,
>>>>>>> and not UHCI, OHCI or EHCI). But maybe EDK2 will take that out of my
>>>>>>> hands. If so, it will make things easier.
>>>>>>> - For USB audio devices I'm not quite sure what to look for; I'm
>>>>>>> definitely unused to USB.
>>>>>>> 2. If any of the above cases are found, appropriate driver
>>>>>>> initialization occurs. Since for the time being I am solely focusing
>>>>>>> on VirtIO sound devices, the VirtIO general initialization sequence
>>>>>>> will occur as outlined in sec. 3 of the VirtIO specification available
>>>>>>> at https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html
>>>>>>> <https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html
>>>>>>> <https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html>>.
>>>>>>> As for actual protocol exposure that would be spec-worthy, for
>>>>>>> EFI_AUDIO_OUTPUT_PROTOCOL, I'm not quite sure what to expose. VirtIO
>>>>>>> is rather simple: there's a buffer for sending and receiving audio
>>>>>>> data in PCM streams. So for that we could expose a Reset(),
>>>>>>> RemapJack(), GetJackConfig(), GetPcmConfig(), SetPcmParams(),
>>>>>>> Prepare(), Release(), Start(), and Stop() function for the
>>>>>>> corresponding request types VIRTIO_SND_R_JACK_GET_CONFIG,
>>>>>>> VIRTIO_SND_R_JACK_REMAP, VIRTIO_SND_R_PCM_GET_CONFIG,
>>>>>>> VIRTIO_SND_R_PCM_SET_PARAMS, VIRTIO_SND_R_PCM_PREPARE,
>>>>>>> VIRTIO_SND_R_PCM_RELEASE, VIRTIO_SND_R_PCM_START, and
>>>>>>> VIRTIO_SND_R_PCM_STOP control requests. However, for HDA things are a
>>>>>>> lot more complex, so I'm not sure how that should work.
>>>>>>> For VirtIO -- which is what I'll focus on for now -- everything is
>>>>>>> described, in excellent detail, in sec. 5.14 of the above-linked
>>>>>>> document. What are your guys's thoughts thus far and how should
>>>>>>> everything be mapped to UEFI interfaces?
>>>>>>> 
>>>>>>> On 4/13/21, Andrew Fish <afish@apple.com <mailto:afish@apple.com>
>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>>>
>>>>>>> wrote:
>>>>>>>> Leif,
>>>>>>>> 
>>>>>>>> Since I have put some brain cells around this area in the past I can
>>>>>>>> be
>>>>>>>> the
>>>>>>>> backup and help out too.
>>>>>>>> 
>>>>>>>> I’d also point out if you are having issues building or have general
>>>>>>>> questions on how things work it is fine to use the mailing list. I’ve
>>>>>>>> got
>>>>>>>> a
>>>>>>>> lot of feedback that folks read or search the mailing list looking
>>>>>>>> for
>>>>>>>> answer to their questions so one person asking can help out a lot of
>>>>>>>> other
>>>>>>>> people.
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> 
>>>>>>>> Andrew Fish
>>>>>>>> 
>>>>>>>>> On Apr 13, 2021, at 5:28 AM, Leif Lindholm <leif@nuviainc.com
>>>>>>>>> <mailto:leif@nuviainc.com>> wrote:
>>>>>>>>> 
>>>>>>>>> Hi all, especially Ethin.
>>>>>>>>> 
>>>>>>>>> Apologies for radio silence - last week I was off on holiday, and
>>>>>>>>> before
>>>>>>>>> that ... let's just say corporate acquisitions generate some
>>>>>>>>> distractions.
>>>>>>>>> Anyway, I'm back, and since I'm down as the mentor for this task,
>>>>>>>>> feel
>>>>>>>>> free to spam me with any remaining/new questions.
>>>>>>>>> 
>>>>>>>>> /
>>>>>>>>>  Leif
>>>>>>>>> 
>>>>>>>>> On Tue, Apr 6, 2021 at 4:17 PM Ethin Probst <harlydavidsen@gmail.com
>>>>>>>>> <mailto:harlydavidsen@gmail.com>
>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>>
>>>>>>>>> wrote:
>>>>>>>>> I'll attach the bug for the build tools to the BZ shortly.
>>>>>>>>> Laszlo, thanks for that. I don't know their email addresses though.
>>>>>>>>> And yes, I was going to make it device independent, as the majority
>>>>>>>>> (if not all) of UEFI protocols are.
>>>>>>>>> 
>>>>>>>>> On 4/6/21, Laszlo Ersek <lersek@redhat.com <mailto:lersek@redhat.com>
>>>>>>>>> <mailto:lersek@redhat.com <mailto:lersek@redhat.com>>
>>>>>>>>> <mailto:lersek@redhat.com <mailto:lersek@redhat.com>
>>>>>>>>> <mailto:lersek@redhat.com <mailto:lersek@redhat.com>>>>
>>>>>>>>> wrote:
>>>>>>>>>> On 03/31/21 08:41, Nate DeSimone wrote:
>>>>>>>>>>> Another option is to put the protocol definition in MdeModulePkg
>>>>>>>>>>> and
>>>>>>>>>>> mark it with the EDKII_ prefix. For my last “code first” UEFI spec
>>>>>>>>>>> contribution I did this with the PPI that added up getting added.
>>>>>>>>>> 
>>>>>>>>>> The new audio protocol should be generic, only its implementation
>>>>>>>>>> in
>>>>>>>>>> question should be virtio specific.
>>>>>>>>>> 
>>>>>>>>>> Please include Gerd Hoffmann (CC'd) in the protocol design, as well
>>>>>>>>>> as
>>>>>>>>>> the developers of the virtio-sound device model in QEMU.
>>>>>>>>>> 
>>>>>>>>>> Thanks
>>>>>>>>>> Laszlo
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Thanks,
>>>>>>>>>>> 
>>>>>>>>>>> Nate
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> *From: *<devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>>> on
>>>>>>>>>>> behalf
>>>>>>>>>>> of "Andrew Fish via groups.io <http://groups.io/>
>>>>>>>>>>> <http://groups.io/ <http://groups.io/>> <http://groups.io/
>>>>>>>>>>> <http://groups.io/>
>>>>>>>>>>> <http://groups.io/ <http://groups.io/>>>"
>>>>>>>>>>> <afish=apple.com@groups.io <mailto:afish=apple.com@groups.io>
>>>>>>>>>>> <mailto:afish=apple.com@groups.io
>>>>>>>>>>> <mailto:afish=apple.com@groups.io>>
>>>>>>>>>>> <mailto:apple.com@groups.io <mailto:apple.com@groups.io>
>>>>>>>>>>> <mailto:apple.com@groups.io <mailto:apple.com@groups.io>>>>
>>>>>>>>>>> *Reply-To: *"devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>>"
>>>>>>>>>>> <devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>>>,
>>>>>>>>>>> "afish@apple.com <mailto:afish@apple.com> <mailto:afish@apple.com
>>>>>>>>>>> <mailto:afish@apple.com>> <mailto:afish@apple.com
>>>>>>>>>>> <mailto:afish@apple.com>
>>>>>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>>>"
>>>>>>>>>>> <afish@apple.com <mailto:afish@apple.com> <mailto:afish@apple.com
>>>>>>>>>>> <mailto:afish@apple.com>>
>>>>>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>
>>>>>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>>>>
>>>>>>>>>>> *Date: *Tuesday, March 30, 2021 at 10:54 PM
>>>>>>>>>>> *To: *edk2-devel-groups-io <devel@edk2.groups.io
>>>>>>>>>>> <mailto:devel@edk2.groups.io>
>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>>>,
>>>>>>>>>>> "harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>>>"
>>>>>>>>>>> <harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>>>>
>>>>>>>>>>> *Cc: *Rafael Rodrigues Machado <rafaelrodrigues.machado@gmail.com
>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>
>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>>>
>>>>>>>>>>> *Subject: *Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>  On Mar 30, 2021, at 5:01 PM, Ethin Probst
>>>>>>>>>>> <harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>
>>>>>>>>>>>  <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>  I'm wondering where exactly I should add the VirtIO sound
>>>>>>>>>>> protocol.
>>>>>>>>>>> I
>>>>>>>>>>>  just familiarized myself with the build system and am about to
>>>>>>>>>>> test
>>>>>>>>>>> it
>>>>>>>>>>>  by building OVMF if possible, but I'm wondering where I should
>>>>>>>>>>>  actually put the protocol and all that stuff. Maybe there's
>>>>>>>>>>>  documentation I've missed as well.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Ethin,
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> For the driver I’d match the patter of OVMF [1] and use
>>>>>>>>>>> OvmfPkg/VirtioSoundDxe/. Maybe even use one of the other drivers
>>>>>>>>>>> as
>>>>>>>>>>> a
>>>>>>>>>>> template.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> The protocol is more of a public thing. I think eventually we
>>>>>>>>>>> would
>>>>>>>>>>> like
>>>>>>>>>>> to publish the protocol in the UEFI Spec (I can help with that
>>>>>>>>>>> part)
>>>>>>>>>>> and
>>>>>>>>>>> that would mean we put the Protocol definition in
>>>>>>>>>>> MdePkg/Include/Protocol, but we don’t want to do that before it is
>>>>>>>>>>> standardized as that causes compatibility issues. So this is a
>>>>>>>>>>> “code
>>>>>>>>>>> first project” (code prototype and then contribute to the UEFI
>>>>>>>>>>> Forum
>>>>>>>>>>> for
>>>>>>>>>>> inclusion in the specification) so we need to follow some code
>>>>>>>>>>> first
>>>>>>>>>>> rules that I don’t remember of the top of my head? So why not
>>>>>>>>>>> start
>>>>>>>>>>> out
>>>>>>>>>>> the protocol definition OvmfPkg/Include/Protocol. You can also add
>>>>>>>>>>> a
>>>>>>>>>>> test application looks like you can just use the root [2] of OVMF
>>>>>>>>>>> for
>>>>>>>>>>> that. That way the project is not blocked.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> We can have a conversation on the mailing list about better places
>>>>>>>>>>> to
>>>>>>>>>>> put stuff, and it should be easy enough to move stuff around if
>>>>>>>>>>> everything else is working.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> [1] find OvmfPkg  -iname '*Virtio*.inf'
>>>>>>>>>>> 
>>>>>>>>>>> OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
>>>>>>>>>>> 
>>>>>>>>>>> OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
>>>>>>>>>>> 
>>>>>>>>>>> OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf
>>>>>>>>>>> 
>>>>>>>>>>> OvmfPkg/Library/VirtioLib/VirtioLib.inf
>>>>>>>>>>> 
>>>>>>>>>>> OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
>>>>>>>>>>> 
>>>>>>>>>>> OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
>>>>>>>>>>> 
>>>>>>>>>>> OvmfPkg/Virtio10Dxe/Virtio10.inf
>>>>>>>>>>> 
>>>>>>>>>>> OvmfPkg/VirtioNetDxe/VirtioNet.inf
>>>>>>>>>>> 
>>>>>>>>>>> OvmfPkg/VirtioRngDxe/VirtioRng.inf
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> [2] /Volumes/Case/edk2-github/OvmfPkg>git grep APPLICATION --
>>>>>>>>>>> *.inf
>>>>>>>>>>> |
>>>>>>>>>>> grep MODULE_TYPE
>>>>>>>>>>> 
>>>>>>>>>>> EnrollDefaultKeys/EnrollDefaultKeys.inf:13:  MODULE_TYPE
>>>>>>>>>>>  = UEFI_APPLICATION
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Thanks,
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Andrew Fish
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>  On 3/30/21, Ethin Probst via groups.io <http://groups.io/>
>>>>>>>>>>> <http://groups.io/ <http://groups.io/>>
>>>>>>>>>>> <http://groups.io/ <http://groups.io/> <http://groups.io/
>>>>>>>>>>> <http://groups.io/>>>
>>>>>>>>>>> <http://groups.io/ <http://groups.io/> <http://groups.io/
>>>>>>>>>>> <http://groups.io/>> <http://groups.io/ <http://groups.io/>
>>>>>>>>>>> <http://groups.io/ <http://groups.io/>>>>
>>>>>>>>>>>  <harlydavidsen=gmail.com@groups.io
>>>>>>>>>>> <mailto:harlydavidsen=gmail.com@groups.io>
>>>>>>>>>>> <mailto:harlydavidsen=gmail.com@groups.io
>>>>>>>>>>> <mailto:harlydavidsen=gmail.com@groups.io>>
>>>>>>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>
>>>>>>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>>>
>>>>>>>>>>>  <mailto:harlydavidsen <mailto:harlydavidsen>=gmail.com@groups.io
>>>>>>>>>>> <mailto:gmail.com@groups.io>
>>>>>>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>>
>>>>>>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>
>>>>>>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>      I agree. Plus, it gives me a chance to finally learn the
>>>>>>>>>>> EDK2
>>>>>>>>>>> build
>>>>>>>>>>>      system and how it works! I've been working on a hobby OS as
>>>>>>>>>>> a
>>>>>>>>>>> side
>>>>>>>>>>>      project and, though learning from other code examples from
>>>>>>>>>>> OSes
>>>>>>>>>>> is
>>>>>>>>>>>      fun, I have to say that learning from the firmware code like
>>>>>>>>>>> from
>>>>>>>>>>>      SeaBIOS has been some of the most enlightening and
>>>>>>>>>>> interesting
>>>>>>>>>>> times
>>>>>>>>>>>      thus far.
>>>>>>>>>>>      Thanks for the link to your code, Rafael; once I get virtIO
>>>>>>>>>>> support
>>>>>>>>>>>      in, I can work on HDA support, though I might tackle USB
>>>>>>>>>>> support
>>>>>>>>>>>      second and HDA third. We'll see, but VirtIO definitely is
>>>>>>>>>>> coming
>>>>>>>>>>>      first.
>>>>>>>>>>> 
>>>>>>>>>>>      As I said before, I look forward to working with all of you
>>>>>>>>>>>      wonderful
>>>>>>>>>>>      people!
>>>>>>>>>>> 
>>>>>>>>>>>      On 3/30/21, Rafael Rodrigues Machado
>>>>>>>>>>>      <rafaelrodrigues.machado@gmail.com
>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>
>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>>
>>>>>>>>>>>      <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>
>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>>>>
>>>>>>>>>>>      wrote:
>>>>>>>>>>> 
>>>>>>>>>>>          This would be amazing so people can continue my work
>>>>>>>>>>> related
>>>>>>>>>>> to
>>>>>>>>>>>          accessibility at BIOS. Something desired by the blind
>>>>>>>>>>> people
>>>>>>>>>>>          since the
>>>>>>>>>>>          90's
>>>>>>>>>>>          Just for reference, this is what I have done:
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
>>>>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>
>>>>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
>>>>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>>
>>>>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
>>>>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>
>>>>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
>>>>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>>>
>>>>>>>>>>> 
>>>>>>>>>>>          Thanks
>>>>>>>>>>>          Rafael
>>>>>>>>>>> 
>>>>>>>>>>>          Em seg, 29 de mar de 2021 20:24, Ethin Probst
>>>>>>>>>>>          <harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>>>>
>>>>>>>>>>>          escreveu:
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>              Hello everyone,
>>>>>>>>>>> 
>>>>>>>>>>>              This is the first time I've ever contributed to
>>>>>>>>>>> EDK2.
>>>>>>>>>>> As
>>>>>>>>>>>              part of GSoC
>>>>>>>>>>>              2021, I have submitted a proposal to implement a
>>>>>>>>>>> UEFI
>>>>>>>>>>>              audio output
>>>>>>>>>>>              protocol that will utilize the VirtIO sound driver.
>>>>>>>>>>> I've
>>>>>>>>>>>              already
>>>>>>>>>>>              submitted a draft proposal, and apologize if I've
>>>>>>>>>>> done
>>>>>>>>>>>              things out of
>>>>>>>>>>>              order. This is my first time doing GSoC 2021, and
>>>>>>>>>>>              contributing to EDK2
>>>>>>>>>>>              felt like a really fun thing to do!
>>>>>>>>>>> 
>>>>>>>>>>>              I look forward to working with you guys on this and
>>>>>>>>>>> any
>>>>>>>>>>>              future projects!
>>>>>>>>>>>              :-)
>>>>>>>>>>> 
>>>>>>>>>>>              --
>>>>>>>>>>>              Signed,
>>>>>>>>>>>              Ethin D. Probst
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>      --
>>>>>>>>>>>      Signed,
>>>>>>>>>>>      Ethin D. Probst
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>  --
>>>>>>>>>>>  Signed,
>>>>>>>>>>>  Ethin D. Probst
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> Signed,
>>>>>>>>> Ethin D. Probst
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> Signed,
>>>>>>> Ethin D. Probst
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Signed,
>>>>> Ethin D. Probst
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> Signed,
>>>> Ethin D. Probst
>>> 
>>> 
>> 
>> 
>> --
>> Signed,
>> Ethin D. Probst
>> 
>> 
>> 


[-- Attachment #2: Type: text/html, Size: 54883 bytes --]

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Ethin Probst]

Hi Mike and Andrew,

Thanks for your responses. I'm looking at the VirtIO block device now
but will certainly have a look at the others as well. We'll also need
to define a completely new protocol for audio, as well, as no existing
protocol will fit the bill. The generic protocol proposed by Andrew
might work, though I was thinking of a couple modifications: primarily
that the audio interface will most likely be asynchronous in nature.
Every audio library I've looked at out there that's open-source is
fully asynchronous, as are operating-system level APIs. For example,
the Microsoft Windows WASAPI audio API requires the application that
uses the audio engine to poll a particular variable that's updated as
the audio stream progresses, as demonstrated here
(https://docs.microsoft.com/en-us/windows/win32/coreaudio/rendering-a-stream).
Obviously, I'm not going to make the code as complicated as the code
shown in the aforementioned example, since this is UEFI and not an
operating system, and making it too complicated would make it
difficult to use and understand, something that I'd like to avoid.
Therefore, for protocol design, would this be satisfactory? Not all of
it needs to be finished for GSoC; I can implement stubs for those that
I don't have time to implement, but I'd like to discuss the protocol
before I start working on a driver for it. I have a (incomplete)
outline of a (hopefully) good protocol at
https://gist.github.com/ethindp/56066e0561b901c1e276e82ff469436d. I'd
appreciate your thoughts on it.

On 4/14/21, Andrew Fish <afish@apple.com> wrote:
>
>
>> On Apr 14, 2021, at 3:30 PM, Kinney, Michael D
>> <michael.d.kinney@intel.com> wrote:
>>
>> Hi Ethin,
>>
>> Most UEFI Drivers do use polling.
>>
>> If it is a blocking I/O operation the UEFI Driver waits for completion.
>> Typically by polling a status register until the I/O is complete and then
>> return status.
>>
>> If it is a non-blocking I/O Operation, then the UEFI Driver can create a
>> timer event to periodically check the completion status.
>>
>> Non-blocking APIs may also use an event to know when the I/O operation is
>> completed and this can be used with the CheckEvent() service to poll for
>> event completion.
>>
>> These concepts are discussed in the UEFI Driver Writer's Guide.
>>
>> https://tianocore-docs.github.io/edk2-UefiDriverWritersGuide/draft/edk2-UefiDriverWritersGuide-draft.pdf
>> <https://tianocore-docs.github.io/edk2-UefiDriverWritersGuide/draft/edk2-UefiDriverWritersGuide-draft.pdf>
>>
>> Specifically for audio.  If there is an audio playback buffer that will
>> take some time to send,
>> the Audio Protocol would likely define a non-blocking interface to start
>> playback.  You may need
>> an event that is signaled when more audio data is needed or when the
>> playback is complete.  You
>> will need to think about the consumer of the Audio Protocol and how it
>> will interact with the
>> Audio Protocol and if the consumer also needs to do other activities while
>> audio is playing or
>> if it is ok for the consumer to wait until the audio playback is
>> completed.
>>
>
> Mike,
>
> It is likely we want async and synchronous playback. If you are playing a
> boot bong you don’t want to block on its completion. If you are doing a GUI
> UI you don’t want to block on playback and then do a bunch of GUI math etc.
>
>
> Ethin,
>
> I’d take a look at some example drivers like VirtioBlkDxe[1]. It also looks
> like there is already a VirtioLib[2] to help with house keeping. I did a
> quick skim and I don’t see a VirtIo device with an Event driven API.  It
> looks like VirtioNetDxe[3] does have the concept of a callback to poll [4],
> so you might be able to leverage that concept into a timer event to check
> for completion.
>
> I’d not get hung up on the asynchronous part of the API. It might make sense
> to implement the synchronous version of the API in the driver 1st and fake
> the async for your 1st pass.
>
> If you look at other UEFI Async APIs they generally pass around a Token
> (usually an Event to signal on completion, and an EFI_STATUS)[5]. Thus
> faking the Async means making it look like the event fired before your API
> returned. Assuming that *Token is an argument to the protocol you do this to
> fake the Async transaction….
>
> If (Token != NULL) {
>   Token->TransactionStatus = Status;
>   gBS->SignalEvent (Token->Event);
> }
>
> This just make it look to the caller like the transaction completed by the
> time you returned to the caller. So from a caller perspective that is a
> valid way the API could work. The other upside to this is you can make a
> UEFI Shell App to test the protocol and also add a path to test the async
> API, even if for the 1st pass implementation that is faked out.
>
> [1] https://github.com/tianocore/edk2/tree/master/OvmfPkg/VirtioBlkDxe
> [2]
> https://github.com/tianocore/edk2/blob/master/OvmfPkg/Library/VirtioLib/VirtioLib.c
> [3] https://github.com/tianocore/edk2/tree/master/OvmfPkg/VirtioNetDxe
> [4]
> https://github.com/tianocore/edk2/blob/master/OvmfPkg/VirtioNetDxe/Events.c#L32
> [5]
> https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/BlockIo2.h#L41
>
> Thanks,
>
> Andrew Fish
>
>> Mike
>>
>>> -----Original Message-----
>>> From: devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>> <devel@edk2.groups.io <mailto:devel@edk2.groups.io>> On Behalf Of Ethin
>>> Probst
>>> Sent: Wednesday, April 14, 2021 1:48 PM
>>> To: Andrew Fish <afish@apple.com <mailto:afish@apple.com>>
>>> Cc: edk2-devel-groups-io <devel@edk2.groups.io
>>> <mailto:devel@edk2.groups.io>>; Leif Lindholm <leif@nuviainc.com
>>> <mailto:leif@nuviainc.com>>; Laszlo Ersek <lersek@redhat.com
>>> <mailto:lersek@redhat.com>>;
>>> Desimone, Nathaniel L <nathaniel.l.desimone@intel.com
>>> <mailto:nathaniel.l.desimone@intel.com>>; Rafael Rodrigues Machado
>>> <rafaelrodrigues.machado@gmail.com
>>> <mailto:rafaelrodrigues.machado@gmail.com>>; Gerd
>>> Hoffmann <kraxel@redhat.com <mailto:kraxel@redhat.com>>
>>> Subject: Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)
>>>
>>> These are some pretty good suggestions; however, while reading through
>>> the VirtIO specification again yesterday, I (re)-discovered that
>>> VirtIO devices are usually interrupt based. In particular, a VirtIO
>>> PCI/PCIe device defines the common, notifications, ISR status,
>>> device-specific configuration, PCI configuration access, shared memory
>>> region, and vendor-specific data capability structures in PCI
>>> configuration space. It doesn't look like the EFI_CREATE_EVENT or
>>> EFI_CREATE_EVENT_EX function works via interrupts, from what I can
>>> tell. I'm not sure but it doesn't seem like there's a way I can poll
>>> the device, though I might be missing something.
>>> The idea for the generic protocol is good. The interrupt issue might
>>> be a problem though and I'm not sure how to actually solve that.
>>>
>>> On 4/13/21, Andrew Fish <afish@apple.com> wrote:
>>>> Ethin,
>>>>
>>>> In terms of defining the protocol stack it is good to start with the
>>>> producers and consumers and think about the problem from both
>>>> perspectives.
>>>> It is easy enough to think about the producer part of it as you are
>>>> thinking
>>>> about writing the driver. The driver is going to consume things like the
>>>> PCI
>>>> I/O Protocol.
>>>>
>>>> The consumer of the sound Protocol is going to most likely be generic
>>>> EFI
>>>> platform code, and possibly an OS loader. In the boot process Audio has
>>>> traditionally be used for error codes, sign of life (for example the
>>>> famous
>>>> Mac startup sound). We are also would like to have the option of
>>>> enabling
>>>> better accessibility features, especially for people how are visually
>>>> impaired. These days a lot of software engineers think of disk space as
>>>> free
>>>> and really don’t consider the size of software, but this is not true
>>>> for
>>>> firmware. Firmware generally lives in NOR FLASH that is considered
>>>> expensive
>>>> (it is more expensive than NAND, but at the same time more reliable) so
>>>> firmware implementations are constrained by the size of the code that
>>>> can be
>>>> carried, and the size of assets/resources that can be used for user
>>>> interfaces. The OS loader is some what less constrained, but it still
>>>> has to
>>>> share the EFI System Partition on the disk with potentially other OS
>>>> loaders.
>>>>
>>>> So the consumer wants a protocol that is unleveled and focused on the
>>>> task
>>>> at hand. I’m not too caught up on the names but in general I think
>>>> things
>>>> you want are (How many knobs we need is probably better answered by an
>>>> audiophile, and that is not me):
>>>> 1) CompatibleBuffer() - Does driver support this buffer format.
>>>> 2) PlayBuffer() - Play the sound
>>>> 	a) We probably want a synchronous and asynchronous version of this API.
>>>> For
>>>> example you don’t want to slow down the boot to wait for a boot beep to
>>>> complete, and you may chose to implement an API that waits for the sound
>>>> to
>>>> complete (and do some GUI work in parallel) vs. blocking on the sound.
>>>> 	b) async in EFI usually means you return a pointer to an EFI_EVENT
>>>> that
>>>> gets signaled on completion.
>>>> 3) StopBuffer() - In case the asynchronous PlayBuffer() needs to be
>>>> stopped.
>>>> Think error exit.
>>>> 3) SetVolume()/GetVolume() - Set/Get Volume in units of 0 - 100 (trying
>>>> to
>>>> avoid db as that gets into capability and math that is likely best
>>>> abstracted by the driver)?
>>>> 4) Mute()/UnMute() - Mute and volume are often independent features in a
>>>> UI
>>>> keeping them separate in API makes it easier to implement things.
>>>> 5) PlayTone() - Maybe for error sounds that don’t require canned sound
>>>> files. Maybe TimeOn, TimeOff, Frequency, and how many times to repeat.
>>>> 6) Do we need tuning values or Tone settings?
>>>>
>>>> At some point we might consider defining nvram variable for the default
>>>> state of some of the tunable, especially mute and volume. For example
>>>> the
>>>> user may want to turn off all volume on the system so it would be nice
>>>> if
>>>> the OS can set the EFI volume and mute. In the short run we can probably
>>>> use
>>>> PCD values to set the default values.
>>>>
>>>> So I think we have a generic AUDIO API on top and likely a PCI I/O on
>>>> the
>>>> bottom. If we need more protocols to manage hardware devices then those
>>>> protocols can be defined in the context of that hardware. So for example
>>>> we
>>>> would probably end up with an HDA_CODEC protocol. I think the best way
>>>> to
>>>> think about this is a disk. A lot of disk adapters just produce a raw
>>>> Block
>>>> I/O  protocol, but for a more common bus like ATA or SCSI you might have
>>>> an
>>>> extra driver in place to make the common bits common code. I think some
>>>> of
>>>> the same layers may be in place here. So likely VirtIo is simple and
>>>> just
>>>> produces the generic AUDIO API, while an HDA audio driver also has to
>>>> abstract some of the complexity of its hardware implementation and
>>>> standard.
>>>>
>>>>
>>>> In terms of picking the set of APIs and tunables it is probably good to
>>>> start with VirtIo and USB and see what set make sense and what you could
>>>> and
>>>> could not implement. HDA Audio is so complex you might want to look at
>>>> it in
>>>> terms of the minute you have to implement to make it function. Think
>>>> what
>>>> assumptions are you forced to make to implement.
>>>>
>>>> This is a vey 10,000 foot view to start with. I think you will need to
>>>> mix
>>>> this in the the reality of how it works in the real world to figure out
>>>> the
>>>> right abstraction, but then again that is the beauty of having an
>>>> implementation. Likely also get some feedback from audiophiles.
>>>>
>>>> Oh and make sure you don’t go off an implement a lot of code just
>>>> because we
>>>> chose the wrong complexity or abstraction point. This is the one time we
>>>> get
>>>> to change the public APIs so lets feel free to adjust them to make the
>>>> most
>>>> sense for the job at hand.
>>>>
>>>> Thanks,
>>>>
>>>> Andrew Fish
>>>>
>>>>> On Apr 13, 2021, at 6:20 PM, Ethin Probst <harlydavidsen@gmail.com>
>>>>> wrote:
>>>>>
>>>>> Okay, so looking at the EDK2 driver developers guide, here are my
>>>>> thoughts:
>>>>>
>>>>> - Each audio driver will be a bus driver, even if it doesn't control
>>>>> buses in the traditional sense.
>>>>> - I think the initialization sequence should be different: there
>>>>> should be an AudioDxe, but it should contain three separate bus
>>>>> drivers for each kind of audio device supported.
>>>>> - For the VirtIO audio device driver, it'll most likely consume the
>>>>> PCI I/O protocol and produce the EFI_VIRTIO_AUDIO_OUTPUT_PROTOCOL and
>>>>> EFI_VIRTIO_AUDIO_INPUT_PROTOCOL protocols. This will just be an
>>>>> ordinary UEFI device driver.
>>>>> - The HDA audio device driver will consume the PCI I/O protocol and
>>>>> will produce different device handles per HDA controller found. I'd
>>>>> produce a handle per codec, but that seems overkill. Each handle will
>>>>> be attached to both an audio stream protocol and a controller
>>>>> management protocol. The audio stream protocol will manage the
>>>>> creation, control, and deletion of audio streams as well as the
>>>>> processing of audio data. The controller management protocol is
>>>>> responsible for allowing applications or other drivers to manage the
>>>>> HDA controller itself.
>>>>>
>>>>> I haven't planned for the USB audio device driver yet, but these are
>>>>> my thoughts so far. What do you guys think? Am I over-complicating
>>>>> this setup? How can it be improved upon?
>>>>>
>>>>> On 4/13/21, Ethin Probst via groups.io <http://groups.io/>
>>>>> <harlydavidsen=gmail.com@groups.io
>>>>> <mailto:harlydavidsen=gmail.com@groups.io>> wrote:
>>>>>> Hi Andrew,
>>>>>>
>>>>>> The developer guide for EDK2 drivers is a godsend. Thank you very
>>>>>> much, and thank you, Mike, for your excellent work on the guide! I
>>>>>> may
>>>>>> just ahve to do my building on Linux and not Windows -- unless the
>>>>>> Bug
>>>>>> -- bug 3302 -- has been fixed. I'll have to do testing on Linux, at
>>>>>> any rate, since Windows hosts do not support VirtIO emulation and I
>>>>>> can't seem to find any way of emulating them in a guest machine with
>>>>>> Windows as a host.
>>>>>>
>>>>>> On 4/13/21, Andrew Fish <afish@apple.com <mailto:afish@apple.com>>
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>> On Apr 13, 2021, at 9:53 AM, Ethin Probst <harlydavidsen@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Would it be possible for us to conduct discussion on the UEFI
>>>>>>>> talkbox?
>>>>>>>> I don't mind using email, but things could definitely get moving
>>>>>>>> quicker over there (though its not a requirement obviously).
>>>>>>>>
>>>>>>>
>>>>>>> Sure, don’t think I’ve really used that but as long as I get pointed
>>>>>>> int
>>>>>>> he
>>>>>>> right direction I can make it work.
>>>>>>>
>>>>>>> For a device driver the general UEFI model is for the Entry point of
>>>>>>> the
>>>>>>> driver to publish a EFI_DRIVER_BINDING_PROTOCOL[1]. The Supported()
>>>>>>> function
>>>>>>> matches on the PCI devices. The Start() function installs the
>>>>>>> Protocols
>>>>>>> to
>>>>>>> do work, and the Stop() undoes the Start().
>>>>>>>
>>>>>>> Mike Kinney started this back in the day and it describes how to
>>>>>>> write
>>>>>>> UEFI
>>>>>>> drivers:
>>>>>>> https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Driver-Writer%27s-Guide
>>>>>>>
>>>>>>> [1]https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/DriverBinding.h#L157
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Andrew Fish
>>>>>>>
>>>>>>>> Here's how I generally envision the driver functioning:
>>>>>>>>
>>>>>>>> 1. Firmware/platform code calls InitaudioOutput() or something like
>>>>>>>> it. This function scans the PCIe bus and scans for one of the
>>>>>>>> following:
>>>>>>>> - Vendor ID 0x1AF4, device ID 0x1059: VirtIO sound device
>>>>>>>> - PCI class 0x0C, subclass 0x03, program interface 0x30 or 0x40:
>>>>>>>> for
>>>>>>>> USB audio interface (I'm only thinking of targeting XHCI and USB 4,
>>>>>>>> and not UHCI, OHCI or EHCI). But maybe EDK2 will take that out of
>>>>>>>> my
>>>>>>>> hands. If so, it will make things easier.
>>>>>>>> - For USB audio devices I'm not quite sure what to look for; I'm
>>>>>>>> definitely unused to USB.
>>>>>>>> 2. If any of the above cases are found, appropriate driver
>>>>>>>> initialization occurs. Since for the time being I am solely
>>>>>>>> focusing
>>>>>>>> on VirtIO sound devices, the VirtIO general initialization sequence
>>>>>>>> will occur as outlined in sec. 3 of the VirtIO specification
>>>>>>>> available
>>>>>>>> at https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html
>>>>>>>> <https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html
>>>>>>>> <https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html>>.
>>>>>>>> As for actual protocol exposure that would be spec-worthy, for
>>>>>>>> EFI_AUDIO_OUTPUT_PROTOCOL, I'm not quite sure what to expose.
>>>>>>>> VirtIO
>>>>>>>> is rather simple: there's a buffer for sending and receiving audio
>>>>>>>> data in PCM streams. So for that we could expose a Reset(),
>>>>>>>> RemapJack(), GetJackConfig(), GetPcmConfig(), SetPcmParams(),
>>>>>>>> Prepare(), Release(), Start(), and Stop() function for the
>>>>>>>> corresponding request types VIRTIO_SND_R_JACK_GET_CONFIG,
>>>>>>>> VIRTIO_SND_R_JACK_REMAP, VIRTIO_SND_R_PCM_GET_CONFIG,
>>>>>>>> VIRTIO_SND_R_PCM_SET_PARAMS, VIRTIO_SND_R_PCM_PREPARE,
>>>>>>>> VIRTIO_SND_R_PCM_RELEASE, VIRTIO_SND_R_PCM_START, and
>>>>>>>> VIRTIO_SND_R_PCM_STOP control requests. However, for HDA things are
>>>>>>>> a
>>>>>>>> lot more complex, so I'm not sure how that should work.
>>>>>>>> For VirtIO -- which is what I'll focus on for now -- everything is
>>>>>>>> described, in excellent detail, in sec. 5.14 of the above-linked
>>>>>>>> document. What are your guys's thoughts thus far and how should
>>>>>>>> everything be mapped to UEFI interfaces?
>>>>>>>>
>>>>>>>> On 4/13/21, Andrew Fish <afish@apple.com <mailto:afish@apple.com>
>>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>>>
>>>>>>>> wrote:
>>>>>>>>> Leif,
>>>>>>>>>
>>>>>>>>> Since I have put some brain cells around this area in the past I
>>>>>>>>> can
>>>>>>>>> be
>>>>>>>>> the
>>>>>>>>> backup and help out too.
>>>>>>>>>
>>>>>>>>> I’d also point out if you are having issues building or have
>>>>>>>>> general
>>>>>>>>> questions on how things work it is fine to use the mailing list.
>>>>>>>>> I’ve
>>>>>>>>> got
>>>>>>>>> a
>>>>>>>>> lot of feedback that folks read or search the mailing list looking
>>>>>>>>> for
>>>>>>>>> answer to their questions so one person asking can help out a lot
>>>>>>>>> of
>>>>>>>>> other
>>>>>>>>> people.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Andrew Fish
>>>>>>>>>
>>>>>>>>>> On Apr 13, 2021, at 5:28 AM, Leif Lindholm <leif@nuviainc.com
>>>>>>>>>> <mailto:leif@nuviainc.com>> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi all, especially Ethin.
>>>>>>>>>>
>>>>>>>>>> Apologies for radio silence - last week I was off on holiday, and
>>>>>>>>>> before
>>>>>>>>>> that ... let's just say corporate acquisitions generate some
>>>>>>>>>> distractions.
>>>>>>>>>> Anyway, I'm back, and since I'm down as the mentor for this task,
>>>>>>>>>> feel
>>>>>>>>>> free to spam me with any remaining/new questions.
>>>>>>>>>>
>>>>>>>>>> /
>>>>>>>>>>  Leif
>>>>>>>>>>
>>>>>>>>>> On Tue, Apr 6, 2021 at 4:17 PM Ethin Probst
>>>>>>>>>> <harlydavidsen@gmail.com
>>>>>>>>>> <mailto:harlydavidsen@gmail.com>
>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>> <mailto:harlydavidsen@gmail.com>>>>
>>>>>>>>>> wrote:
>>>>>>>>>> I'll attach the bug for the build tools to the BZ shortly.
>>>>>>>>>> Laszlo, thanks for that. I don't know their email addresses
>>>>>>>>>> though.
>>>>>>>>>> And yes, I was going to make it device independent, as the
>>>>>>>>>> majority
>>>>>>>>>> (if not all) of UEFI protocols are.
>>>>>>>>>>
>>>>>>>>>> On 4/6/21, Laszlo Ersek <lersek@redhat.com
>>>>>>>>>> <mailto:lersek@redhat.com>
>>>>>>>>>> <mailto:lersek@redhat.com <mailto:lersek@redhat.com>>
>>>>>>>>>> <mailto:lersek@redhat.com <mailto:lersek@redhat.com>
>>>>>>>>>> <mailto:lersek@redhat.com <mailto:lersek@redhat.com>>>>
>>>>>>>>>> wrote:
>>>>>>>>>>> On 03/31/21 08:41, Nate DeSimone wrote:
>>>>>>>>>>>> Another option is to put the protocol definition in
>>>>>>>>>>>> MdeModulePkg
>>>>>>>>>>>> and
>>>>>>>>>>>> mark it with the EDKII_ prefix. For my last “code first” UEFI
>>>>>>>>>>>> spec
>>>>>>>>>>>> contribution I did this with the PPI that added up getting
>>>>>>>>>>>> added.
>>>>>>>>>>>
>>>>>>>>>>> The new audio protocol should be generic, only its
>>>>>>>>>>> implementation
>>>>>>>>>>> in
>>>>>>>>>>> question should be virtio specific.
>>>>>>>>>>>
>>>>>>>>>>> Please include Gerd Hoffmann (CC'd) in the protocol design, as
>>>>>>>>>>> well
>>>>>>>>>>> as
>>>>>>>>>>> the developers of the virtio-sound device model in QEMU.
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>> Laszlo
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>
>>>>>>>>>>>> Nate
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> *From: *<devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>>>
>>>>>>>>>>>> on
>>>>>>>>>>>> behalf
>>>>>>>>>>>> of "Andrew Fish via groups.io <http://groups.io/>
>>>>>>>>>>>> <http://groups.io/ <http://groups.io/>> <http://groups.io/
>>>>>>>>>>>> <http://groups.io/>
>>>>>>>>>>>> <http://groups.io/ <http://groups.io/>>>"
>>>>>>>>>>>> <afish=apple.com@groups.io <mailto:afish=apple.com@groups.io>
>>>>>>>>>>>> <mailto:afish=apple.com@groups.io
>>>>>>>>>>>> <mailto:afish=apple.com@groups.io>>
>>>>>>>>>>>> <mailto:apple.com@groups.io <mailto:apple.com@groups.io>
>>>>>>>>>>>> <mailto:apple.com@groups.io <mailto:apple.com@groups.io>>>>
>>>>>>>>>>>> *Reply-To: *"devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>>"
>>>>>>>>>>>> <devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>>>,
>>>>>>>>>>>> "afish@apple.com <mailto:afish@apple.com>
>>>>>>>>>>>> <mailto:afish@apple.com
>>>>>>>>>>>> <mailto:afish@apple.com>> <mailto:afish@apple.com
>>>>>>>>>>>> <mailto:afish@apple.com>
>>>>>>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>>>"
>>>>>>>>>>>> <afish@apple.com <mailto:afish@apple.com>
>>>>>>>>>>>> <mailto:afish@apple.com
>>>>>>>>>>>> <mailto:afish@apple.com>>
>>>>>>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>
>>>>>>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>>>>
>>>>>>>>>>>> *Date: *Tuesday, March 30, 2021 at 10:54 PM
>>>>>>>>>>>> *To: *edk2-devel-groups-io <devel@edk2.groups.io
>>>>>>>>>>>> <mailto:devel@edk2.groups.io>
>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>>>,
>>>>>>>>>>>> "harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>>
>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>>>"
>>>>>>>>>>>> <harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>>
>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>>>>
>>>>>>>>>>>> *Cc: *Rafael Rodrigues Machado
>>>>>>>>>>>> <rafaelrodrigues.machado@gmail.com
>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>
>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>>>
>>>>>>>>>>>> *Subject: *Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>  On Mar 30, 2021, at 5:01 PM, Ethin Probst
>>>>>>>>>>>> <harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>>
>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>>>
>>>>>>>>>>>>  <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>>
>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>>>>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>  I'm wondering where exactly I should add the VirtIO sound
>>>>>>>>>>>> protocol.
>>>>>>>>>>>> I
>>>>>>>>>>>>  just familiarized myself with the build system and am about to
>>>>>>>>>>>> test
>>>>>>>>>>>> it
>>>>>>>>>>>>  by building OVMF if possible, but I'm wondering where I should
>>>>>>>>>>>>  actually put the protocol and all that stuff. Maybe there's
>>>>>>>>>>>>  documentation I've missed as well.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Ethin,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> For the driver I’d match the patter of OVMF [1] and use
>>>>>>>>>>>> OvmfPkg/VirtioSoundDxe/. Maybe even use one of the other
>>>>>>>>>>>> drivers
>>>>>>>>>>>> as
>>>>>>>>>>>> a
>>>>>>>>>>>> template.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The protocol is more of a public thing. I think eventually we
>>>>>>>>>>>> would
>>>>>>>>>>>> like
>>>>>>>>>>>> to publish the protocol in the UEFI Spec (I can help with that
>>>>>>>>>>>> part)
>>>>>>>>>>>> and
>>>>>>>>>>>> that would mean we put the Protocol definition in
>>>>>>>>>>>> MdePkg/Include/Protocol, but we don’t want to do that before it
>>>>>>>>>>>> is
>>>>>>>>>>>> standardized as that causes compatibility issues. So this is a
>>>>>>>>>>>> “code
>>>>>>>>>>>> first project” (code prototype and then contribute to the UEFI
>>>>>>>>>>>> Forum
>>>>>>>>>>>> for
>>>>>>>>>>>> inclusion in the specification) so we need to follow some code
>>>>>>>>>>>> first
>>>>>>>>>>>> rules that I don’t remember of the top of my head? So why not
>>>>>>>>>>>> start
>>>>>>>>>>>> out
>>>>>>>>>>>> the protocol definition OvmfPkg/Include/Protocol. You can also
>>>>>>>>>>>> add
>>>>>>>>>>>> a
>>>>>>>>>>>> test application looks like you can just use the root [2] of
>>>>>>>>>>>> OVMF
>>>>>>>>>>>> for
>>>>>>>>>>>> that. That way the project is not blocked.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> We can have a conversation on the mailing list about better
>>>>>>>>>>>> places
>>>>>>>>>>>> to
>>>>>>>>>>>> put stuff, and it should be easy enough to move stuff around if
>>>>>>>>>>>> everything else is working.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> [1] find OvmfPkg  -iname '*Virtio*.inf'
>>>>>>>>>>>>
>>>>>>>>>>>> OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
>>>>>>>>>>>>
>>>>>>>>>>>> OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
>>>>>>>>>>>>
>>>>>>>>>>>> OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf
>>>>>>>>>>>>
>>>>>>>>>>>> OvmfPkg/Library/VirtioLib/VirtioLib.inf
>>>>>>>>>>>>
>>>>>>>>>>>> OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
>>>>>>>>>>>>
>>>>>>>>>>>> OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
>>>>>>>>>>>>
>>>>>>>>>>>> OvmfPkg/Virtio10Dxe/Virtio10.inf
>>>>>>>>>>>>
>>>>>>>>>>>> OvmfPkg/VirtioNetDxe/VirtioNet.inf
>>>>>>>>>>>>
>>>>>>>>>>>> OvmfPkg/VirtioRngDxe/VirtioRng.inf
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> [2] /Volumes/Case/edk2-github/OvmfPkg>git grep APPLICATION --
>>>>>>>>>>>> *.inf
>>>>>>>>>>>> |
>>>>>>>>>>>> grep MODULE_TYPE
>>>>>>>>>>>>
>>>>>>>>>>>> EnrollDefaultKeys/EnrollDefaultKeys.inf:13:  MODULE_TYPE
>>>>>>>>>>>>  = UEFI_APPLICATION
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Andrew Fish
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>  On 3/30/21, Ethin Probst via groups.io <http://groups.io/>
>>>>>>>>>>>> <http://groups.io/ <http://groups.io/>>
>>>>>>>>>>>> <http://groups.io/ <http://groups.io/> <http://groups.io/
>>>>>>>>>>>> <http://groups.io/>>>
>>>>>>>>>>>> <http://groups.io/ <http://groups.io/> <http://groups.io/
>>>>>>>>>>>> <http://groups.io/>> <http://groups.io/ <http://groups.io/>
>>>>>>>>>>>> <http://groups.io/ <http://groups.io/>>>>
>>>>>>>>>>>>  <harlydavidsen=gmail.com@groups.io
>>>>>>>>>>>> <mailto:harlydavidsen=gmail.com@groups.io>
>>>>>>>>>>>> <mailto:harlydavidsen=gmail.com@groups.io
>>>>>>>>>>>> <mailto:harlydavidsen=gmail.com@groups.io>>
>>>>>>>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>
>>>>>>>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>>>
>>>>>>>>>>>>  <mailto:harlydavidsen
>>>>>>>>>>>> <mailto:harlydavidsen>=gmail.com@groups.io
>>>>>>>>>>>> <mailto:gmail.com@groups.io>
>>>>>>>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>>
>>>>>>>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>
>>>>>>>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>>>>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>      I agree. Plus, it gives me a chance to finally learn the
>>>>>>>>>>>> EDK2
>>>>>>>>>>>> build
>>>>>>>>>>>>      system and how it works! I've been working on a hobby OS
>>>>>>>>>>>> as
>>>>>>>>>>>> a
>>>>>>>>>>>> side
>>>>>>>>>>>>      project and, though learning from other code examples from
>>>>>>>>>>>> OSes
>>>>>>>>>>>> is
>>>>>>>>>>>>      fun, I have to say that learning from the firmware code
>>>>>>>>>>>> like
>>>>>>>>>>>> from
>>>>>>>>>>>>      SeaBIOS has been some of the most enlightening and
>>>>>>>>>>>> interesting
>>>>>>>>>>>> times
>>>>>>>>>>>>      thus far.
>>>>>>>>>>>>      Thanks for the link to your code, Rafael; once I get
>>>>>>>>>>>> virtIO
>>>>>>>>>>>> support
>>>>>>>>>>>>      in, I can work on HDA support, though I might tackle USB
>>>>>>>>>>>> support
>>>>>>>>>>>>      second and HDA third. We'll see, but VirtIO definitely is
>>>>>>>>>>>> coming
>>>>>>>>>>>>      first.
>>>>>>>>>>>>
>>>>>>>>>>>>      As I said before, I look forward to working with all of
>>>>>>>>>>>> you
>>>>>>>>>>>>      wonderful
>>>>>>>>>>>>      people!
>>>>>>>>>>>>
>>>>>>>>>>>>      On 3/30/21, Rafael Rodrigues Machado
>>>>>>>>>>>>      <rafaelrodrigues.machado@gmail.com
>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>
>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>>
>>>>>>>>>>>>      <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>
>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>>>>
>>>>>>>>>>>>      wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>          This would be amazing so people can continue my work
>>>>>>>>>>>> related
>>>>>>>>>>>> to
>>>>>>>>>>>>          accessibility at BIOS. Something desired by the blind
>>>>>>>>>>>> people
>>>>>>>>>>>>          since the
>>>>>>>>>>>>          90's
>>>>>>>>>>>>          Just for reference, this is what I have done:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
>>>>>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>
>>>>>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
>>>>>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>>
>>>>>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
>>>>>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>
>>>>>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
>>>>>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>>>
>>>>>>>>>>>>
>>>>>>>>>>>>          Thanks
>>>>>>>>>>>>          Rafael
>>>>>>>>>>>>
>>>>>>>>>>>>          Em seg, 29 de mar de 2021 20:24, Ethin Probst
>>>>>>>>>>>>          <harlydavidsen@gmail.com
>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>>
>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>>>>
>>>>>>>>>>>>          escreveu:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>              Hello everyone,
>>>>>>>>>>>>
>>>>>>>>>>>>              This is the first time I've ever contributed to
>>>>>>>>>>>> EDK2.
>>>>>>>>>>>> As
>>>>>>>>>>>>              part of GSoC
>>>>>>>>>>>>              2021, I have submitted a proposal to implement a
>>>>>>>>>>>> UEFI
>>>>>>>>>>>>              audio output
>>>>>>>>>>>>              protocol that will utilize the VirtIO sound
>>>>>>>>>>>> driver.
>>>>>>>>>>>> I've
>>>>>>>>>>>>              already
>>>>>>>>>>>>              submitted a draft proposal, and apologize if I've
>>>>>>>>>>>> done
>>>>>>>>>>>>              things out of
>>>>>>>>>>>>              order. This is my first time doing GSoC 2021, and
>>>>>>>>>>>>              contributing to EDK2
>>>>>>>>>>>>              felt like a really fun thing to do!
>>>>>>>>>>>>
>>>>>>>>>>>>              I look forward to working with you guys on this
>>>>>>>>>>>> and
>>>>>>>>>>>> any
>>>>>>>>>>>>              future projects!
>>>>>>>>>>>>              :-)
>>>>>>>>>>>>
>>>>>>>>>>>>              --
>>>>>>>>>>>>              Signed,
>>>>>>>>>>>>              Ethin D. Probst
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>      --
>>>>>>>>>>>>      Signed,
>>>>>>>>>>>>      Ethin D. Probst
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>  --
>>>>>>>>>>>>  Signed,
>>>>>>>>>>>>  Ethin D. Probst
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Signed,
>>>>>>>>>> Ethin D. Probst
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Signed,
>>>>>>>> Ethin D. Probst
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Signed,
>>>>>> Ethin D. Probst
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Signed,
>>>>> Ethin D. Probst
>>>>
>>>>
>>>
>>>
>>> --
>>> Signed,
>>> Ethin D. Probst
>>>
>>>
>>> 
>
>


-- 
Signed,
Ethin D. Probst

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Andrew Fish]

[-- Attachment #1: Type: text/plain, Size: 56500 bytes --]



> On Apr 14, 2021, at 9:01 PM, Ethin Probst <harlydavidsen@gmail.com> wrote:
> 
> Hi Mike and Andrew,
> 
> Thanks for your responses. I'm looking at the VirtIO block device now
> but will certainly have a look at the others as well. We'll also need
> to define a completely new protocol for audio, as well, as no existing
> protocol will fit the bill. The generic protocol proposed by Andrew
> might work, though I was thinking of a couple modifications: primarily
> that the audio interface will most likely be asynchronous in nature.
> Every audio library I've looked at out there that's open-source is
> fully asynchronous, as are operating-system level APIs. For example,
> the Microsoft Windows WASAPI audio API requires the application that
> uses the audio engine to poll a particular variable that's updated as
> the audio stream progresses, as demonstrated here
> (https://docs.microsoft.com/en-us/windows/win32/coreaudio/rendering-a-stream <https://docs.microsoft.com/en-us/windows/win32/coreaudio/rendering-a-stream>).
> Obviously, I'm not going to make the code as complicated as the code
> shown in the aforementioned example, since this is UEFI and not an
> operating system, and making it too complicated would make it
> difficult to use and understand, something that I'd like to avoid.
> Therefore, for protocol design, would this be satisfactory? Not all of
> it needs to be finished for GSoC; I can implement stubs for those that
> I don't have time to implement, but I'd like to discuss the protocol
> before I start working on a driver for it. I have a (incomplete)
> outline of a (hopefully) good protocol at
> https://gist.github.com/ethindp/56066e0561b901c1e276e82ff469436d <https://gist.github.com/ethindp/56066e0561b901c1e276e82ff469436d>. I'd
> appreciate your thoughts on it.
> 

I’d drop the Audio Input part of it. I don’t see a lot of use recording audio when you boot the system, and it is going to be a mess dealing with built in microphones etc. vs. input jacks etc. If we wanted to do input we could define a 2nd protocol that lives on the same handle for that. 

The EFI APIs don’t generally have enumeration members so I’d drop that part too. The driver is going to get started on a PCI device and that is how the device is going to be selection. So we should have a VirtIO Audio driver, a USB Audio driver, and an HDA Audio driver, not one driver that does everything. If there are common operations then 

I really think we need the volume and mute members. I did a prototype for the emulator a few years back and it looked like [1] as a simple abstract for HDA Audo to the system. I assume we could make this generic. 

The firmware really just wants to play the sound for the canned resource. The calling code is not some GUI app the user can configure. So I’m not sure of the value of having to pass in sampleRate, sampleCout, and sampleFormat. I think my proposal basically assumed PCM 16 via a WAVE file or some such. So basically the calling code just has to grab a source and pass it to the Audio protocol. That is how our GUIs work the artwork is in some encoding we can decode and that gets converted to something we can draw to the raw frame buffer. 


 [1] My prototype from a while while back. 

/** @file
  Abstraction for audio modeled on the High Definition Audio Specification. 

  This API is targeted at "Code First" with the UEFI Forum. Thus the plan is 
  to potential make this a standard in the future and definition will then move
  to the MdePkg, and EFI_GUID will likely change. 

  Copyright (c) 2018-2019 Rafael Machado <rafaelrodrigues.machado@gmail.com>
  Copyright (c) 2019, Apple Inc. All rights reserved.<BR>
  SPDX-License-Identifier: BSD-2-Clause-Patent

**/

#ifndef __HDA_AUDIO_H__
#define __HDA_AUDIO_H__

///
/// Global ID for the HDA Audio Protocol
///

// 61EE0891-E13E-11E9-A1C7-823F7D860801
#define CODE_FIRST_HDA_AUDIO_PROTOCOL_GUID \
  { \
    0x61EE0891, 0xE13E, 0x11E9, { 0xA1, 0xC7, 0x82, 0x3F, 0x7D, 0x86, 0x08, 0x01 } \
  }

typedef struct _CODE_FIRST_HDA_AUDIO_PROTOCOL  CODE_FIRST_HDA_AUDIO_PROTOCOL;


typedef INT32   HDA_GAIN;


/**
  The struct of Audio Token.
**/
typedef struct {

  ///
  /// Event will be signaled when the read audo has been played.
  /// If only synchronous playback is supported the Event must still get signaled. 
  ///
  EFI_EVENT               Event;

  ///
  /// Defines whether or not the signaled event encountered an error.
  ///
  EFI_STATUS              TransactionStatus;
} CODE_FIRST_HDA_AUDIO_TOKEN;



/**
  Play synchronous or asynchronous audio. If Token is passed in the audio is played
  asynchronously, if Token is NULL then this call blocks until the Audio is complete. 

  @param[in]      This         A pointer to the CODE_FIRST_HDA_AUDIO_PROTOCOL instance.
  @param[in, out] Token        A pointer to the token associated with the transaction.
                               If NULL this functions blocks until audio play back is complete.
  @param[in]      Buffer       PCM encoded buffer of the audio to play. 
  @param[in ]     BufferSize   The size of Buffer in bytes.

  @retval EFI_SUCCESS           The audio started playing. 
  @retval EFI_UNSUPPORTED       Buffer is not a supported format.
  @retval EFI_OUT_OF_RESOURCES  The request could not be completed due to a lack of resources.
  @retval EFI_INVALID_PARAMETER One or more parameters are invalid.

**/
typedef
EFI_STATUS
(EFIAPI *CODE_FIRST_HDA_AUDIO_PROTOCOL_PLAY_STREAM)(
  IN     CODE_FIRST_HDA_AUDIO_PROTOCOL   *This,
  IN OUT CODE_FIRST_HDA_AUDIO_TOKEN      *Token,     OPTIONAL
  IN     UINT8                           *Buffer,
  IN     UINT64                          BufferSize
  );


/**
  Stop playing asynchronous audio. 

  @param[in]      This         A pointer to the CODE_FIRST_HDA_AUDIO_PROTOCOL instance.
  @param[in, out] Token        A pointer to the token associated with the transaction.

  @retval EFI_SUCCESS           Audio stopped playing. 
  @retval EFI_OUT_OF_RESOURCES  The request could not be completed due to a lack of resources.
  @retval EFI_INVALID_PARAMETER One or more parameters are invalid.

**/
typedef
EFI_STATUS
(EFIAPI *CODE_FIRST_HDA_AUDIO_PROTOCOL_STOP_STREAM)(
  IN     CODE_FIRST_HDA_AUDIO_PROTOCOL   *This,
  IN     CODE_FIRST_HDA_AUDIO_TOKEN      *Token
  );


/**
  Return the current volume for audio played by this protocol. 

  @param[in]      This         A pointer to the CODE_FIRST_HDA_AUDIO_PROTOCOL instance.
  @param[out]     Gain         A pointer to the value returned between 0 and 100. 

  @retval EFI_SUCCESS           Gain was returned. 
  @retval EFI_OUT_OF_RESOURCES  The request could not be completed due to a lack of resources.
  @retval EFI_INVALID_PARAMETER One or more parameters are invalid.

**/
typedef
EFI_STATUS
(EFIAPI *CODE_FIRST_HDA_AUDIO_PROTOCOL_GET_VOLUME)(
  IN     CODE_FIRST_HDA_AUDIO_PROTOCOL  *This,
  IN OUT HDA_GAIN                       *Gain
  );


/**
  Set the current volume for audio played by this protocol.

  The result of calling this function while audio is playing asynchronously is undefined. 

  @param[in]      This         A pointer to the CODE_FIRST_HDA_AUDIO_PROTOCOL instance.
  @param[in]      Gain         A value between 0 and 100 to set the volume. 

  @retval EFI_SUCCESS           Gain was updated. 
  @retval EFI_OUT_OF_RESOURCES  The request could not be completed due to a lack of resources.
  @retval EFI_INVALID_PARAMETER One or more parameters are invalid.

**/
typedef
EFI_STATUS
(EFIAPI *CODE_FIRST_HDA_AUDIO_PROTOCOL_SET_VOLUME)(
  IN     CODE_FIRST_HDA_AUDIO_PROTOCOL    *This,
  IN OUT HDA_GAIN                         Gain
  );


/**
  Increment the volume in an implementation defined quanta. The value of the Gain can never
  be over 100. The final successful call will round the volume increase to 100. If this
  function is called an the Gain is already set to 100 EFI_NO_MAPPING must be returned. 

  The result of calling this function while audio is playing asynchronously is undefined. 

  @param[in]      This         A pointer to the CODE_FIRST_HDA_AUDIO_PROTOCOL instance.

  @retval EFI_SUCCESS           Gain was incremented. 
  @retval EFI_NO_MAPPING        Gasin was not updated since it was already set to 100.
  @retval EFI_OUT_OF_RESOURCES  The request could not be completed due to a lack of resources.
  @retval EFI_INVALID_PARAMETER One or more parameters are invalid.

**/
typedef
EFI_STATUS
(EFIAPI *CODE_FIRST_HDA_AUDIO_PROTOCOL_VOLUME_UP)(
  IN     CODE_FIRST_HDA_AUDIO_PROTOCOL   *This
  );


/**
  Decrement the volume in an implementation defined quanta. The value of the Gain can never
  be under 0. The final successful call will round the volume decrease to 0. If this
  function is called an the Gain is already set to 0 EFI_NO_MAPPING must be returned. 

  The result of calling this function while audio is playing asynchronously is undefined. 

  @param[in]      This         A pointer to the CODE_FIRST_HDA_AUDIO_PROTOCOL instance.

  @retval EFI_SUCCESS           Gain was decremented. 
  @retval EFI_NO_MAPPING        Gain was not updated since it was already set to 0.
  @retval EFI_OUT_OF_RESOURCES  The request could not be completed due to a lack of resources.
  @retval EFI_INVALID_PARAMETER One or more parameters are invalid.

**/
typedef
EFI_STATUS
(EFIAPI *CODE_FIRST_HDA_AUDIO_PROTOCOL_VOLUME_DOWN)(
  IN     CODE_FIRST_HDA_AUDIO_PROTOCOL   *This
  );


/**
  Mute audio output, but retain the current Gain (volume Level).

  The result of calling this function while audio is playing asynchronously is undefined. 

  @param[in]      This         A pointer to the CODE_FIRST_HDA_AUDIO_PROTOCOL instance.

  @retval EFI_SUCCESS           Audio was muted. 
  @retval EFI_ALREADY_STARTED   Audio is already muted. 
  @retval EFI_OUT_OF_RESOURCES  The request could not be completed due to a lack of resources.
  @retval EFI_INVALID_PARAMETER One or more parameters are invalid.

**/
typedef
EFI_STATUS
(EFIAPI *CODE_FIRST_HDA_AUDIO_PROTOCOL_MUTE)(
  IN     CODE_FIRST_HDA_AUDIO_PROTOCOL   *This
  );

/**
  Unmute audio output, but retain the current Gain (volume Level).

  The result of calling this function while audio is playing asynchronously is undefined. 

  @param[in]      This         A pointer to the CODE_FIRST_HDA_AUDIO_PROTOCOL instance.

  @retval EFI_SUCCESS           Audio was muted. 
  @retval EFI_ALREADY_STARTED   Audio is already unmuted. 
  @retval EFI_OUT_OF_RESOURCES  The request could not be completed due to a lack of resources.
  @retval EFI_INVALID_PARAMETER One or more parameters are invalid.

**/
typedef
EFI_STATUS
(EFIAPI *CODE_FIRST_HDA_AUDIO_PROTOCOL_UNMUTE)(
  IN     CODE_FIRST_HDA_AUDIO_PROTOCOL   *This
  );


/**
  Reset the audio hardware. 

  The result of calling this function while audio is playing asynchronously is undefined. 

  @param[in]      This         A pointer to the CODE_FIRST_HDA_AUDIO_PROTOCOL instance.

  @retval EFI_SUCCESS           Audio was muted. 
  @retval EFI_OUT_OF_RESOURCES  The request could not be completed due to a lack of resources.
  @retval EFI_INVALID_PARAMETER One or more parameters are invalid.

**/
typedef
EFI_STATUS
(EFIAPI *CODE_FIRST_HDA_AUDIO_PROTOCOL_RESET)(
  IN     CODE_FIRST_HDA_AUDIO_PROTOCOL   *This
  );


#define HDA_AUDIO_VERSION 0x00010000

///
/// The CODE_FIRST_HDA_AUDIO_PROTOCOL provides an abstraction for an Audio device that
/// can play PCM files. 
/// There is one CODE_FIRST_HDA_AUDIO_PROTOCOL instance for each Audio Hardware device.
///
struct _CODE_FIRST_HDA_AUDIO_PROTOCOL {
  UINT64                                      Version;
  CODE_FIRST_HDA_AUDIO_PROTOCOL_PLAY_STREAM   PlayStream;
  CODE_FIRST_HDA_AUDIO_PROTOCOL_STOP_STREAM   StopStream;
  CODE_FIRST_HDA_AUDIO_PROTOCOL_GET_VOLUME    GetVolume;
  CODE_FIRST_HDA_AUDIO_PROTOCOL_SET_VOLUME    SetVolume;
  CODE_FIRST_HDA_AUDIO_PROTOCOL_VOLUME_UP     VolumeUp;
  CODE_FIRST_HDA_AUDIO_PROTOCOL_VOLUME_DOWN   VolumeDown; 
  CODE_FIRST_HDA_AUDIO_PROTOCOL_MUTE          Mute;
  CODE_FIRST_HDA_AUDIO_PROTOCOL_UNMUTE        UnMute;
  CODE_FIRST_HDA_AUDIO_PROTOCOL_RESET         Reset;
};

extern EFI_GUID gBz2387HdaAudioProtocolGuid;

#endif


Thanks,

Andrew Fish

> On 4/14/21, Andrew Fish <afish@apple.com <mailto:afish@apple.com>> wrote:
>> 
>> 
>>> On Apr 14, 2021, at 3:30 PM, Kinney, Michael D
>>> <michael.d.kinney@intel.com> wrote:
>>> 
>>> Hi Ethin,
>>> 
>>> Most UEFI Drivers do use polling.
>>> 
>>> If it is a blocking I/O operation the UEFI Driver waits for completion.
>>> Typically by polling a status register until the I/O is complete and then
>>> return status.
>>> 
>>> If it is a non-blocking I/O Operation, then the UEFI Driver can create a
>>> timer event to periodically check the completion status.
>>> 
>>> Non-blocking APIs may also use an event to know when the I/O operation is
>>> completed and this can be used with the CheckEvent() service to poll for
>>> event completion.
>>> 
>>> These concepts are discussed in the UEFI Driver Writer's Guide.
>>> 
>>> https://tianocore-docs.github.io/edk2-UefiDriverWritersGuide/draft/edk2-UefiDriverWritersGuide-draft.pdf
>>> <https://tianocore-docs.github.io/edk2-UefiDriverWritersGuide/draft/edk2-UefiDriverWritersGuide-draft.pdf <https://tianocore-docs.github.io/edk2-UefiDriverWritersGuide/draft/edk2-UefiDriverWritersGuide-draft.pdf>>
>>> 
>>> Specifically for audio.  If there is an audio playback buffer that will
>>> take some time to send,
>>> the Audio Protocol would likely define a non-blocking interface to start
>>> playback.  You may need
>>> an event that is signaled when more audio data is needed or when the
>>> playback is complete.  You
>>> will need to think about the consumer of the Audio Protocol and how it
>>> will interact with the
>>> Audio Protocol and if the consumer also needs to do other activities while
>>> audio is playing or
>>> if it is ok for the consumer to wait until the audio playback is
>>> completed.
>>> 
>> 
>> Mike,
>> 
>> It is likely we want async and synchronous playback. If you are playing a
>> boot bong you don’t want to block on its completion. If you are doing a GUI
>> UI you don’t want to block on playback and then do a bunch of GUI math etc.
>> 
>> 
>> Ethin,
>> 
>> I’d take a look at some example drivers like VirtioBlkDxe[1]. It also looks
>> like there is already a VirtioLib[2] to help with house keeping. I did a
>> quick skim and I don’t see a VirtIo device with an Event driven API.  It
>> looks like VirtioNetDxe[3] does have the concept of a callback to poll [4],
>> so you might be able to leverage that concept into a timer event to check
>> for completion.
>> 
>> I’d not get hung up on the asynchronous part of the API. It might make sense
>> to implement the synchronous version of the API in the driver 1st and fake
>> the async for your 1st pass.
>> 
>> If you look at other UEFI Async APIs they generally pass around a Token
>> (usually an Event to signal on completion, and an EFI_STATUS)[5]. Thus
>> faking the Async means making it look like the event fired before your API
>> returned. Assuming that *Token is an argument to the protocol you do this to
>> fake the Async transaction….
>> 
>> If (Token != NULL) {
>>  Token->TransactionStatus = Status;
>>  gBS->SignalEvent (Token->Event);
>> }
>> 
>> This just make it look to the caller like the transaction completed by the
>> time you returned to the caller. So from a caller perspective that is a
>> valid way the API could work. The other upside to this is you can make a
>> UEFI Shell App to test the protocol and also add a path to test the async
>> API, even if for the 1st pass implementation that is faked out.
>> 
>> [1] https://github.com/tianocore/edk2/tree/master/OvmfPkg/VirtioBlkDxe
>> [2]
>> https://github.com/tianocore/edk2/blob/master/OvmfPkg/Library/VirtioLib/VirtioLib.c
>> [3] https://github.com/tianocore/edk2/tree/master/OvmfPkg/VirtioNetDxe
>> [4]
>> https://github.com/tianocore/edk2/blob/master/OvmfPkg/VirtioNetDxe/Events.c#L32
>> [5]
>> https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/BlockIo2.h#L41
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
>>> Mike
>>> 
>>>> -----Original Message-----
>>>> From: devel@edk2.groups.io <mailto:devel@edk2.groups.io> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
>>>> <devel@edk2.groups.io <mailto:devel@edk2.groups.io> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>> On Behalf Of Ethin
>>>> Probst
>>>> Sent: Wednesday, April 14, 2021 1:48 PM
>>>> To: Andrew Fish <afish@apple.com <mailto:afish@apple.com> <mailto:afish@apple.com <mailto:afish@apple.com>>>
>>>> Cc: edk2-devel-groups-io <devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>>; Leif Lindholm <leif@nuviainc.com <mailto:leif@nuviainc.com>
>>>> <mailto:leif@nuviainc.com <mailto:leif@nuviainc.com>>>; Laszlo Ersek <lersek@redhat.com <mailto:lersek@redhat.com>
>>>> <mailto:lersek@redhat.com <mailto:lersek@redhat.com>>>;
>>>> Desimone, Nathaniel L <nathaniel.l.desimone@intel.com <mailto:nathaniel.l.desimone@intel.com>
>>>> <mailto:nathaniel.l.desimone@intel.com <mailto:nathaniel.l.desimone@intel.com>>>; Rafael Rodrigues Machado
>>>> <rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>
>>>> <mailto:rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>>>; Gerd
>>>> Hoffmann <kraxel@redhat.com <mailto:kraxel@redhat.com> <mailto:kraxel@redhat.com <mailto:kraxel@redhat.com>>>
>>>> Subject: Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)
>>>> 
>>>> These are some pretty good suggestions; however, while reading through
>>>> the VirtIO specification again yesterday, I (re)-discovered that
>>>> VirtIO devices are usually interrupt based. In particular, a VirtIO
>>>> PCI/PCIe device defines the common, notifications, ISR status,
>>>> device-specific configuration, PCI configuration access, shared memory
>>>> region, and vendor-specific data capability structures in PCI
>>>> configuration space. It doesn't look like the EFI_CREATE_EVENT or
>>>> EFI_CREATE_EVENT_EX function works via interrupts, from what I can
>>>> tell. I'm not sure but it doesn't seem like there's a way I can poll
>>>> the device, though I might be missing something.
>>>> The idea for the generic protocol is good. The interrupt issue might
>>>> be a problem though and I'm not sure how to actually solve that.
>>>> 
>>>> On 4/13/21, Andrew Fish <afish@apple.com <mailto:afish@apple.com>> wrote:
>>>>> Ethin,
>>>>> 
>>>>> In terms of defining the protocol stack it is good to start with the
>>>>> producers and consumers and think about the problem from both
>>>>> perspectives.
>>>>> It is easy enough to think about the producer part of it as you are
>>>>> thinking
>>>>> about writing the driver. The driver is going to consume things like the
>>>>> PCI
>>>>> I/O Protocol.
>>>>> 
>>>>> The consumer of the sound Protocol is going to most likely be generic
>>>>> EFI
>>>>> platform code, and possibly an OS loader. In the boot process Audio has
>>>>> traditionally be used for error codes, sign of life (for example the
>>>>> famous
>>>>> Mac startup sound). We are also would like to have the option of
>>>>> enabling
>>>>> better accessibility features, especially for people how are visually
>>>>> impaired. These days a lot of software engineers think of disk space as
>>>>> free
>>>>> and really don’t consider the size of software, but this is not true
>>>>> for
>>>>> firmware. Firmware generally lives in NOR FLASH that is considered
>>>>> expensive
>>>>> (it is more expensive than NAND, but at the same time more reliable) so
>>>>> firmware implementations are constrained by the size of the code that
>>>>> can be
>>>>> carried, and the size of assets/resources that can be used for user
>>>>> interfaces. The OS loader is some what less constrained, but it still
>>>>> has to
>>>>> share the EFI System Partition on the disk with potentially other OS
>>>>> loaders.
>>>>> 
>>>>> So the consumer wants a protocol that is unleveled and focused on the
>>>>> task
>>>>> at hand. I’m not too caught up on the names but in general I think
>>>>> things
>>>>> you want are (How many knobs we need is probably better answered by an
>>>>> audiophile, and that is not me):
>>>>> 1) CompatibleBuffer() - Does driver support this buffer format.
>>>>> 2) PlayBuffer() - Play the sound
>>>>> 	a) We probably want a synchronous and asynchronous version of this API.
>>>>> For
>>>>> example you don’t want to slow down the boot to wait for a boot beep to
>>>>> complete, and you may chose to implement an API that waits for the sound
>>>>> to
>>>>> complete (and do some GUI work in parallel) vs. blocking on the sound.
>>>>> 	b) async in EFI usually means you return a pointer to an EFI_EVENT
>>>>> that
>>>>> gets signaled on completion.
>>>>> 3) StopBuffer() - In case the asynchronous PlayBuffer() needs to be
>>>>> stopped.
>>>>> Think error exit.
>>>>> 3) SetVolume()/GetVolume() - Set/Get Volume in units of 0 - 100 (trying
>>>>> to
>>>>> avoid db as that gets into capability and math that is likely best
>>>>> abstracted by the driver)?
>>>>> 4) Mute()/UnMute() - Mute and volume are often independent features in a
>>>>> UI
>>>>> keeping them separate in API makes it easier to implement things.
>>>>> 5) PlayTone() - Maybe for error sounds that don’t require canned sound
>>>>> files. Maybe TimeOn, TimeOff, Frequency, and how many times to repeat.
>>>>> 6) Do we need tuning values or Tone settings?
>>>>> 
>>>>> At some point we might consider defining nvram variable for the default
>>>>> state of some of the tunable, especially mute and volume. For example
>>>>> the
>>>>> user may want to turn off all volume on the system so it would be nice
>>>>> if
>>>>> the OS can set the EFI volume and mute. In the short run we can probably
>>>>> use
>>>>> PCD values to set the default values.
>>>>> 
>>>>> So I think we have a generic AUDIO API on top and likely a PCI I/O on
>>>>> the
>>>>> bottom. If we need more protocols to manage hardware devices then those
>>>>> protocols can be defined in the context of that hardware. So for example
>>>>> we
>>>>> would probably end up with an HDA_CODEC protocol. I think the best way
>>>>> to
>>>>> think about this is a disk. A lot of disk adapters just produce a raw
>>>>> Block
>>>>> I/O  protocol, but for a more common bus like ATA or SCSI you might have
>>>>> an
>>>>> extra driver in place to make the common bits common code. I think some
>>>>> of
>>>>> the same layers may be in place here. So likely VirtIo is simple and
>>>>> just
>>>>> produces the generic AUDIO API, while an HDA audio driver also has to
>>>>> abstract some of the complexity of its hardware implementation and
>>>>> standard.
>>>>> 
>>>>> 
>>>>> In terms of picking the set of APIs and tunables it is probably good to
>>>>> start with VirtIo and USB and see what set make sense and what you could
>>>>> and
>>>>> could not implement. HDA Audio is so complex you might want to look at
>>>>> it in
>>>>> terms of the minute you have to implement to make it function. Think
>>>>> what
>>>>> assumptions are you forced to make to implement.
>>>>> 
>>>>> This is a vey 10,000 foot view to start with. I think you will need to
>>>>> mix
>>>>> this in the the reality of how it works in the real world to figure out
>>>>> the
>>>>> right abstraction, but then again that is the beauty of having an
>>>>> implementation. Likely also get some feedback from audiophiles.
>>>>> 
>>>>> Oh and make sure you don’t go off an implement a lot of code just
>>>>> because we
>>>>> chose the wrong complexity or abstraction point. This is the one time we
>>>>> get
>>>>> to change the public APIs so lets feel free to adjust them to make the
>>>>> most
>>>>> sense for the job at hand.
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> Andrew Fish
>>>>> 
>>>>>> On Apr 13, 2021, at 6:20 PM, Ethin Probst <harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
>>>>>> wrote:
>>>>>> 
>>>>>> Okay, so looking at the EDK2 driver developers guide, here are my
>>>>>> thoughts:
>>>>>> 
>>>>>> - Each audio driver will be a bus driver, even if it doesn't control
>>>>>> buses in the traditional sense.
>>>>>> - I think the initialization sequence should be different: there
>>>>>> should be an AudioDxe, but it should contain three separate bus
>>>>>> drivers for each kind of audio device supported.
>>>>>> - For the VirtIO audio device driver, it'll most likely consume the
>>>>>> PCI I/O protocol and produce the EFI_VIRTIO_AUDIO_OUTPUT_PROTOCOL and
>>>>>> EFI_VIRTIO_AUDIO_INPUT_PROTOCOL protocols. This will just be an
>>>>>> ordinary UEFI device driver.
>>>>>> - The HDA audio device driver will consume the PCI I/O protocol and
>>>>>> will produce different device handles per HDA controller found. I'd
>>>>>> produce a handle per codec, but that seems overkill. Each handle will
>>>>>> be attached to both an audio stream protocol and a controller
>>>>>> management protocol. The audio stream protocol will manage the
>>>>>> creation, control, and deletion of audio streams as well as the
>>>>>> processing of audio data. The controller management protocol is
>>>>>> responsible for allowing applications or other drivers to manage the
>>>>>> HDA controller itself.
>>>>>> 
>>>>>> I haven't planned for the USB audio device driver yet, but these are
>>>>>> my thoughts so far. What do you guys think? Am I over-complicating
>>>>>> this setup? How can it be improved upon?
>>>>>> 
>>>>>> On 4/13/21, Ethin Probst via groups.io <http://groups.io/> <http://groups.io/ <http://groups.io/>>
>>>>>> <harlydavidsen=gmail.com@groups.io <mailto:harlydavidsen=gmail.com@groups.io>
>>>>>> <mailto:harlydavidsen=gmail.com@groups.io <mailto:harlydavidsen=gmail.com@groups.io>>> wrote:
>>>>>>> Hi Andrew,
>>>>>>> 
>>>>>>> The developer guide for EDK2 drivers is a godsend. Thank you very
>>>>>>> much, and thank you, Mike, for your excellent work on the guide! I
>>>>>>> may
>>>>>>> just ahve to do my building on Linux and not Windows -- unless the
>>>>>>> Bug
>>>>>>> -- bug 3302 -- has been fixed. I'll have to do testing on Linux, at
>>>>>>> any rate, since Windows hosts do not support VirtIO emulation and I
>>>>>>> can't seem to find any way of emulating them in a guest machine with
>>>>>>> Windows as a host.
>>>>>>> 
>>>>>>> On 4/13/21, Andrew Fish <afish@apple.com <mailto:afish@apple.com> <mailto:afish@apple.com <mailto:afish@apple.com>>>
>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On Apr 13, 2021, at 9:53 AM, Ethin Probst <harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> Would it be possible for us to conduct discussion on the UEFI
>>>>>>>>> talkbox?
>>>>>>>>> I don't mind using email, but things could definitely get moving
>>>>>>>>> quicker over there (though its not a requirement obviously).
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> Sure, don’t think I’ve really used that but as long as I get pointed
>>>>>>>> int
>>>>>>>> he
>>>>>>>> right direction I can make it work.
>>>>>>>> 
>>>>>>>> For a device driver the general UEFI model is for the Entry point of
>>>>>>>> the
>>>>>>>> driver to publish a EFI_DRIVER_BINDING_PROTOCOL[1]. The Supported()
>>>>>>>> function
>>>>>>>> matches on the PCI devices. The Start() function installs the
>>>>>>>> Protocols
>>>>>>>> to
>>>>>>>> do work, and the Stop() undoes the Start().
>>>>>>>> 
>>>>>>>> Mike Kinney started this back in the day and it describes how to
>>>>>>>> write
>>>>>>>> UEFI
>>>>>>>> drivers:
>>>>>>>> https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Driver-Writer%27s-Guide <https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Driver-Writer%27s-Guide>
>>>>>>>> 
>>>>>>>> [1]https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/DriverBinding.h#L157 <https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/DriverBinding.h#L157>
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> 
>>>>>>>> Andrew Fish
>>>>>>>> 
>>>>>>>>> Here's how I generally envision the driver functioning:
>>>>>>>>> 
>>>>>>>>> 1. Firmware/platform code calls InitaudioOutput() or something like
>>>>>>>>> it. This function scans the PCIe bus and scans for one of the
>>>>>>>>> following:
>>>>>>>>> - Vendor ID 0x1AF4, device ID 0x1059: VirtIO sound device
>>>>>>>>> - PCI class 0x0C, subclass 0x03, program interface 0x30 or 0x40:
>>>>>>>>> for
>>>>>>>>> USB audio interface (I'm only thinking of targeting XHCI and USB 4,
>>>>>>>>> and not UHCI, OHCI or EHCI). But maybe EDK2 will take that out of
>>>>>>>>> my
>>>>>>>>> hands. If so, it will make things easier.
>>>>>>>>> - For USB audio devices I'm not quite sure what to look for; I'm
>>>>>>>>> definitely unused to USB.
>>>>>>>>> 2. If any of the above cases are found, appropriate driver
>>>>>>>>> initialization occurs. Since for the time being I am solely
>>>>>>>>> focusing
>>>>>>>>> on VirtIO sound devices, the VirtIO general initialization sequence
>>>>>>>>> will occur as outlined in sec. 3 of the VirtIO specification
>>>>>>>>> available
>>>>>>>>> at https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html <https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html>
>>>>>>>>> <https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html <https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html>
>>>>>>>>> <https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html <https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html>>>.
>>>>>>>>> As for actual protocol exposure that would be spec-worthy, for
>>>>>>>>> EFI_AUDIO_OUTPUT_PROTOCOL, I'm not quite sure what to expose.
>>>>>>>>> VirtIO
>>>>>>>>> is rather simple: there's a buffer for sending and receiving audio
>>>>>>>>> data in PCM streams. So for that we could expose a Reset(),
>>>>>>>>> RemapJack(), GetJackConfig(), GetPcmConfig(), SetPcmParams(),
>>>>>>>>> Prepare(), Release(), Start(), and Stop() function for the
>>>>>>>>> corresponding request types VIRTIO_SND_R_JACK_GET_CONFIG,
>>>>>>>>> VIRTIO_SND_R_JACK_REMAP, VIRTIO_SND_R_PCM_GET_CONFIG,
>>>>>>>>> VIRTIO_SND_R_PCM_SET_PARAMS, VIRTIO_SND_R_PCM_PREPARE,
>>>>>>>>> VIRTIO_SND_R_PCM_RELEASE, VIRTIO_SND_R_PCM_START, and
>>>>>>>>> VIRTIO_SND_R_PCM_STOP control requests. However, for HDA things are
>>>>>>>>> a
>>>>>>>>> lot more complex, so I'm not sure how that should work.
>>>>>>>>> For VirtIO -- which is what I'll focus on for now -- everything is
>>>>>>>>> described, in excellent detail, in sec. 5.14 of the above-linked
>>>>>>>>> document. What are your guys's thoughts thus far and how should
>>>>>>>>> everything be mapped to UEFI interfaces?
>>>>>>>>> 
>>>>>>>>> On 4/13/21, Andrew Fish <afish@apple.com <mailto:afish@apple.com> <mailto:afish@apple.com <mailto:afish@apple.com>>
>>>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com> <mailto:afish@apple.com <mailto:afish@apple.com>>>>
>>>>>>>>> wrote:
>>>>>>>>>> Leif,
>>>>>>>>>> 
>>>>>>>>>> Since I have put some brain cells around this area in the past I
>>>>>>>>>> can
>>>>>>>>>> be
>>>>>>>>>> the
>>>>>>>>>> backup and help out too.
>>>>>>>>>> 
>>>>>>>>>> I’d also point out if you are having issues building or have
>>>>>>>>>> general
>>>>>>>>>> questions on how things work it is fine to use the mailing list.
>>>>>>>>>> I’ve
>>>>>>>>>> got
>>>>>>>>>> a
>>>>>>>>>> lot of feedback that folks read or search the mailing list looking
>>>>>>>>>> for
>>>>>>>>>> answer to their questions so one person asking can help out a lot
>>>>>>>>>> of
>>>>>>>>>> other
>>>>>>>>>> people.
>>>>>>>>>> 
>>>>>>>>>> Thanks,
>>>>>>>>>> 
>>>>>>>>>> Andrew Fish
>>>>>>>>>> 
>>>>>>>>>>> On Apr 13, 2021, at 5:28 AM, Leif Lindholm <leif@nuviainc.com <mailto:leif@nuviainc.com>
>>>>>>>>>>> <mailto:leif@nuviainc.com <mailto:leif@nuviainc.com>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Hi all, especially Ethin.
>>>>>>>>>>> 
>>>>>>>>>>> Apologies for radio silence - last week I was off on holiday, and
>>>>>>>>>>> before
>>>>>>>>>>> that ... let's just say corporate acquisitions generate some
>>>>>>>>>>> distractions.
>>>>>>>>>>> Anyway, I'm back, and since I'm down as the mentor for this task,
>>>>>>>>>>> feel
>>>>>>>>>>> free to spam me with any remaining/new questions.
>>>>>>>>>>> 
>>>>>>>>>>> /
>>>>>>>>>>> Leif
>>>>>>>>>>> 
>>>>>>>>>>> On Tue, Apr 6, 2021 at 4:17 PM Ethin Probst
>>>>>>>>>>> <harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>> I'll attach the bug for the build tools to the BZ shortly.
>>>>>>>>>>> Laszlo, thanks for that. I don't know their email addresses
>>>>>>>>>>> though.
>>>>>>>>>>> And yes, I was going to make it device independent, as the
>>>>>>>>>>> majority
>>>>>>>>>>> (if not all) of UEFI protocols are.
>>>>>>>>>>> 
>>>>>>>>>>> On 4/6/21, Laszlo Ersek <lersek@redhat.com <mailto:lersek@redhat.com>
>>>>>>>>>>> <mailto:lersek@redhat.com <mailto:lersek@redhat.com>>
>>>>>>>>>>> <mailto:lersek@redhat.com <mailto:lersek@redhat.com> <mailto:lersek@redhat.com <mailto:lersek@redhat.com>>>
>>>>>>>>>>> <mailto:lersek@redhat.com <mailto:lersek@redhat.com> <mailto:lersek@redhat.com <mailto:lersek@redhat.com>>
>>>>>>>>>>> <mailto:lersek@redhat.com <mailto:lersek@redhat.com> <mailto:lersek@redhat.com <mailto:lersek@redhat.com>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>> On 03/31/21 08:41, Nate DeSimone wrote:
>>>>>>>>>>>>> Another option is to put the protocol definition in
>>>>>>>>>>>>> MdeModulePkg
>>>>>>>>>>>>> and
>>>>>>>>>>>>> mark it with the EDKII_ prefix. For my last “code first” UEFI
>>>>>>>>>>>>> spec
>>>>>>>>>>>>> contribution I did this with the PPI that added up getting
>>>>>>>>>>>>> added.
>>>>>>>>>>>> 
>>>>>>>>>>>> The new audio protocol should be generic, only its
>>>>>>>>>>>> implementation
>>>>>>>>>>>> in
>>>>>>>>>>>> question should be virtio specific.
>>>>>>>>>>>> 
>>>>>>>>>>>> Please include Gerd Hoffmann (CC'd) in the protocol design, as
>>>>>>>>>>>> well
>>>>>>>>>>>> as
>>>>>>>>>>>> the developers of the virtio-sound device model in QEMU.
>>>>>>>>>>>> 
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Laszlo
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Nate
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> *From: *<devel@edk2.groups.io <mailto:devel@edk2.groups.io> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
>>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>>
>>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
>>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>>>>
>>>>>>>>>>>>> on
>>>>>>>>>>>>> behalf
>>>>>>>>>>>>> of "Andrew Fish via groups.io <http://groups.io/> <http://groups.io/ <http://groups.io/>>
>>>>>>>>>>>>> <http://groups.io/ <http://groups.io/> <http://groups.io/ <http://groups.io/>>> <http://groups.io/ <http://groups.io/>
>>>>>>>>>>>>> <http://groups.io/ <http://groups.io/>>
>>>>>>>>>>>>> <http://groups.io/ <http://groups.io/> <http://groups.io/ <http://groups.io/>>>>"
>>>>>>>>>>>>> <afish=apple.com@groups.io <mailto:afish=apple.com@groups.io> <mailto:afish=apple.com@groups.io <mailto:afish=apple.com@groups.io>>
>>>>>>>>>>>>> <mailto:afish=apple.com@groups.io <mailto:afish=apple.com@groups.io>
>>>>>>>>>>>>> <mailto:afish=apple.com@groups.io <mailto:afish=apple.com@groups.io>>>
>>>>>>>>>>>>> <mailto:apple.com@groups.io <mailto:apple.com@groups.io> <mailto:apple.com@groups.io <mailto:apple.com@groups.io>>
>>>>>>>>>>>>> <mailto:apple.com@groups.io <mailto:apple.com@groups.io> <mailto:apple.com@groups.io <mailto:apple.com@groups.io>>>>>
>>>>>>>>>>>>> *Reply-To: *"devel@edk2.groups.io <mailto:devel@edk2.groups.io> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
>>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>>
>>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
>>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>>>"
>>>>>>>>>>>>> <devel@edk2.groups.io <mailto:devel@edk2.groups.io> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
>>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>>
>>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
>>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>>>>,
>>>>>>>>>>>>> "afish@apple.com <mailto:afish@apple.com> <mailto:afish@apple.com <mailto:afish@apple.com>>
>>>>>>>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>
>>>>>>>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>>> <mailto:afish@apple.com <mailto:afish@apple.com>
>>>>>>>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>>
>>>>>>>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com> <mailto:afish@apple.com <mailto:afish@apple.com>>>>"
>>>>>>>>>>>>> <afish@apple.com <mailto:afish@apple.com> <mailto:afish@apple.com <mailto:afish@apple.com>>
>>>>>>>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>
>>>>>>>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>>>
>>>>>>>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com> <mailto:afish@apple.com <mailto:afish@apple.com>>
>>>>>>>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com> <mailto:afish@apple.com <mailto:afish@apple.com>>>>>
>>>>>>>>>>>>> *Date: *Tuesday, March 30, 2021 at 10:54 PM
>>>>>>>>>>>>> *To: *edk2-devel-groups-io <devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
>>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>>
>>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
>>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>>>>,
>>>>>>>>>>>>> "harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>
>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>>"
>>>>>>>>>>>>> <harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>
>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>>>
>>>>>>>>>>>>> *Cc: *Rafael Rodrigues Machado
>>>>>>>>>>>>> <rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>>
>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>>>
>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>>
>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>>>>>
>>>>>>>>>>>>> *Subject: *Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On Mar 30, 2021, at 5:01 PM, Ethin Probst
>>>>>>>>>>>>> <harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>
>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>>
>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>
>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>>>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I'm wondering where exactly I should add the VirtIO sound
>>>>>>>>>>>>> protocol.
>>>>>>>>>>>>> I
>>>>>>>>>>>>> just familiarized myself with the build system and am about to
>>>>>>>>>>>>> test
>>>>>>>>>>>>> it
>>>>>>>>>>>>> by building OVMF if possible, but I'm wondering where I should
>>>>>>>>>>>>> actually put the protocol and all that stuff. Maybe there's
>>>>>>>>>>>>> documentation I've missed as well.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Ethin,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> For the driver I’d match the patter of OVMF [1] and use
>>>>>>>>>>>>> OvmfPkg/VirtioSoundDxe/. Maybe even use one of the other
>>>>>>>>>>>>> drivers
>>>>>>>>>>>>> as
>>>>>>>>>>>>> a
>>>>>>>>>>>>> template.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> The protocol is more of a public thing. I think eventually we
>>>>>>>>>>>>> would
>>>>>>>>>>>>> like
>>>>>>>>>>>>> to publish the protocol in the UEFI Spec (I can help with that
>>>>>>>>>>>>> part)
>>>>>>>>>>>>> and
>>>>>>>>>>>>> that would mean we put the Protocol definition in
>>>>>>>>>>>>> MdePkg/Include/Protocol, but we don’t want to do that before it
>>>>>>>>>>>>> is
>>>>>>>>>>>>> standardized as that causes compatibility issues. So this is a
>>>>>>>>>>>>> “code
>>>>>>>>>>>>> first project” (code prototype and then contribute to the UEFI
>>>>>>>>>>>>> Forum
>>>>>>>>>>>>> for
>>>>>>>>>>>>> inclusion in the specification) so we need to follow some code
>>>>>>>>>>>>> first
>>>>>>>>>>>>> rules that I don’t remember of the top of my head? So why not
>>>>>>>>>>>>> start
>>>>>>>>>>>>> out
>>>>>>>>>>>>> the protocol definition OvmfPkg/Include/Protocol. You can also
>>>>>>>>>>>>> add
>>>>>>>>>>>>> a
>>>>>>>>>>>>> test application looks like you can just use the root [2] of
>>>>>>>>>>>>> OVMF
>>>>>>>>>>>>> for
>>>>>>>>>>>>> that. That way the project is not blocked.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> We can have a conversation on the mailing list about better
>>>>>>>>>>>>> places
>>>>>>>>>>>>> to
>>>>>>>>>>>>> put stuff, and it should be easy enough to move stuff around if
>>>>>>>>>>>>> everything else is working.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> [1] find OvmfPkg  -iname '*Virtio*.inf'
>>>>>>>>>>>>> 
>>>>>>>>>>>>> OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
>>>>>>>>>>>>> 
>>>>>>>>>>>>> OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
>>>>>>>>>>>>> 
>>>>>>>>>>>>> OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf
>>>>>>>>>>>>> 
>>>>>>>>>>>>> OvmfPkg/Library/VirtioLib/VirtioLib.inf
>>>>>>>>>>>>> 
>>>>>>>>>>>>> OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
>>>>>>>>>>>>> 
>>>>>>>>>>>>> OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
>>>>>>>>>>>>> 
>>>>>>>>>>>>> OvmfPkg/Virtio10Dxe/Virtio10.inf
>>>>>>>>>>>>> 
>>>>>>>>>>>>> OvmfPkg/VirtioNetDxe/VirtioNet.inf
>>>>>>>>>>>>> 
>>>>>>>>>>>>> OvmfPkg/VirtioRngDxe/VirtioRng.inf
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> [2] /Volumes/Case/edk2-github/OvmfPkg>git grep APPLICATION --
>>>>>>>>>>>>> *.inf
>>>>>>>>>>>>> |
>>>>>>>>>>>>> grep MODULE_TYPE
>>>>>>>>>>>>> 
>>>>>>>>>>>>> EnrollDefaultKeys/EnrollDefaultKeys.inf:13:  MODULE_TYPE
>>>>>>>>>>>>> = UEFI_APPLICATION
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Andrew Fish
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On 3/30/21, Ethin Probst via groups.io <http://groups.io/> <http://groups.io/ <http://groups.io/>>
>>>>>>>>>>>>> <http://groups.io/ <http://groups.io/> <http://groups.io/ <http://groups.io/>>>
>>>>>>>>>>>>> <http://groups.io/ <http://groups.io/> <http://groups.io/ <http://groups.io/>> <http://groups.io/ <http://groups.io/>
>>>>>>>>>>>>> <http://groups.io/ <http://groups.io/>>>>
>>>>>>>>>>>>> <http://groups.io/ <http://groups.io/> <http://groups.io/ <http://groups.io/>> <http://groups.io/ <http://groups.io/>
>>>>>>>>>>>>> <http://groups.io/ <http://groups.io/>>> <http://groups.io/ <http://groups.io/> <http://groups.io/ <http://groups.io/>>
>>>>>>>>>>>>> <http://groups.io/ <http://groups.io/> <http://groups.io/ <http://groups.io/>>>>>
>>>>>>>>>>>>> <harlydavidsen=gmail.com@groups.io <mailto:harlydavidsen=gmail.com@groups.io>
>>>>>>>>>>>>> <mailto:harlydavidsen=gmail.com@groups.io <mailto:harlydavidsen=gmail.com@groups.io>>
>>>>>>>>>>>>> <mailto:harlydavidsen=gmail.com@groups.io <mailto:harlydavidsen=gmail.com@groups.io>
>>>>>>>>>>>>> <mailto:harlydavidsen=gmail.com@groups.io <mailto:harlydavidsen=gmail.com@groups.io>>>
>>>>>>>>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>>
>>>>>>>>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>>>>
>>>>>>>>>>>>> <mailto:harlydavidsen
>>>>>>>>>>>>> <mailto:harlydavidsen>=gmail.com@groups.io <mailto:gmail.com@groups.io>
>>>>>>>>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>>
>>>>>>>>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>>>
>>>>>>>>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>>
>>>>>>>>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>>>>>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>     I agree. Plus, it gives me a chance to finally learn the
>>>>>>>>>>>>> EDK2
>>>>>>>>>>>>> build
>>>>>>>>>>>>>     system and how it works! I've been working on a hobby OS
>>>>>>>>>>>>> as
>>>>>>>>>>>>> a
>>>>>>>>>>>>> side
>>>>>>>>>>>>>     project and, though learning from other code examples from
>>>>>>>>>>>>> OSes
>>>>>>>>>>>>> is
>>>>>>>>>>>>>     fun, I have to say that learning from the firmware code
>>>>>>>>>>>>> like
>>>>>>>>>>>>> from
>>>>>>>>>>>>>     SeaBIOS has been some of the most enlightening and
>>>>>>>>>>>>> interesting
>>>>>>>>>>>>> times
>>>>>>>>>>>>>     thus far.
>>>>>>>>>>>>>     Thanks for the link to your code, Rafael; once I get
>>>>>>>>>>>>> virtIO
>>>>>>>>>>>>> support
>>>>>>>>>>>>>     in, I can work on HDA support, though I might tackle USB
>>>>>>>>>>>>> support
>>>>>>>>>>>>>     second and HDA third. We'll see, but VirtIO definitely is
>>>>>>>>>>>>> coming
>>>>>>>>>>>>>     first.
>>>>>>>>>>>>> 
>>>>>>>>>>>>>     As I said before, I look forward to working with all of
>>>>>>>>>>>>> you
>>>>>>>>>>>>>     wonderful
>>>>>>>>>>>>>     people!
>>>>>>>>>>>>> 
>>>>>>>>>>>>>     On 3/30/21, Rafael Rodrigues Machado
>>>>>>>>>>>>>     <rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>>
>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>>>
>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>>
>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>>>>
>>>>>>>>>>>>>     <mailto:rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>>
>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>>>
>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>>
>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com <mailto:rafaelrodrigues.machado@gmail.com>>>>>>
>>>>>>>>>>>>>     wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>         This would be amazing so people can continue my work
>>>>>>>>>>>>> related
>>>>>>>>>>>>> to
>>>>>>>>>>>>>         accessibility at BIOS. Something desired by the blind
>>>>>>>>>>>>> people
>>>>>>>>>>>>>         since the
>>>>>>>>>>>>>         90's
>>>>>>>>>>>>>         Just for reference, this is what I have done:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>
>>>>>>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>>
>>>>>>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>
>>>>>>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>>>
>>>>>>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>
>>>>>>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>>
>>>>>>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>
>>>>>>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>>>>
>>>>>>>>>>>>> 
>>>>>>>>>>>>>         Thanks
>>>>>>>>>>>>>         Rafael
>>>>>>>>>>>>> 
>>>>>>>>>>>>>         Em seg, 29 de mar de 2021 20:24, Ethin Probst
>>>>>>>>>>>>>         <harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>
>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>
>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>>>>>
>>>>>>>>>>>>>         escreveu:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>>             Hello everyone,
>>>>>>>>>>>>> 
>>>>>>>>>>>>>             This is the first time I've ever contributed to
>>>>>>>>>>>>> EDK2.
>>>>>>>>>>>>> As
>>>>>>>>>>>>>             part of GSoC
>>>>>>>>>>>>>             2021, I have submitted a proposal to implement a
>>>>>>>>>>>>> UEFI
>>>>>>>>>>>>>             audio output
>>>>>>>>>>>>>             protocol that will utilize the VirtIO sound
>>>>>>>>>>>>> driver.
>>>>>>>>>>>>> I've
>>>>>>>>>>>>>             already
>>>>>>>>>>>>>             submitted a draft proposal, and apologize if I've
>>>>>>>>>>>>> done
>>>>>>>>>>>>>             things out of
>>>>>>>>>>>>>             order. This is my first time doing GSoC 2021, and
>>>>>>>>>>>>>             contributing to EDK2
>>>>>>>>>>>>>             felt like a really fun thing to do!
>>>>>>>>>>>>> 
>>>>>>>>>>>>>             I look forward to working with you guys on this
>>>>>>>>>>>>> and
>>>>>>>>>>>>> any
>>>>>>>>>>>>>             future projects!
>>>>>>>>>>>>>             :-)
>>>>>>>>>>>>> 
>>>>>>>>>>>>>             --
>>>>>>>>>>>>>             Signed,
>>>>>>>>>>>>>             Ethin D. Probst
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>>     --
>>>>>>>>>>>>>     Signed,
>>>>>>>>>>>>>     Ethin D. Probst
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Signed,
>>>>>>>>>>>>> Ethin D. Probst
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> --
>>>>>>>>>>> Signed,
>>>>>>>>>>> Ethin D. Probst
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> Signed,
>>>>>>>>> Ethin D. Probst
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> Signed,
>>>>>>> Ethin D. Probst
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Signed,
>>>>>> Ethin D. Probst
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> Signed,
>>>> Ethin D. Probst
>>>> 
>>>> 
>>>> 
>> 
>> 
> 
> 
> -- 
> Signed,
> Ethin D. Probst


[-- Attachment #2: Type: text/html, Size: 122622 bytes --]

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Ethin Probst]

So here's the rationale for my extra stuff:

- I hoped to add recording in case we in future want to add
accessibility aids like speech recognition (that was one of the todo
tasks on the EDK2 tasks list)
- Muting and volume control could easily be added by just replacing
the sample buffer with silence and by multiplying all the samples by a
percentage.
- We could have separate protocols for different audio devices, but my
rationale for making it do everything was that it (might) simplify
development. But looking at the UEFI specification there are separate
UEFI protocols for TCP/IP protocols so you have a point there.
- Finally, the reason I used enumerations for specifying parameters
like sample rate and stuff was that I was looking at this protocol
from a general UEFI applications point of view. VirtIO supports all of
the sample configurations listed in my gist, and it seems reasonable
to allow the application to control those parameters instead of
forcing a particular parameter configuration onto the developer.

Perhaps splitting all the separate audio device protocols into their
own individual UEFI protocols would be much easier, though. Volume
control and muting/unmuting shouldn't be too difficult though, I don't
think.

On 4/14/21, Andrew Fish <afish@apple.com> wrote:
>
>
>> On Apr 14, 2021, at 9:01 PM, Ethin Probst <harlydavidsen@gmail.com>
>> wrote:
>>
>> Hi Mike and Andrew,
>>
>> Thanks for your responses. I'm looking at the VirtIO block device now
>> but will certainly have a look at the others as well. We'll also need
>> to define a completely new protocol for audio, as well, as no existing
>> protocol will fit the bill. The generic protocol proposed by Andrew
>> might work, though I was thinking of a couple modifications: primarily
>> that the audio interface will most likely be asynchronous in nature.
>> Every audio library I've looked at out there that's open-source is
>> fully asynchronous, as are operating-system level APIs. For example,
>> the Microsoft Windows WASAPI audio API requires the application that
>> uses the audio engine to poll a particular variable that's updated as
>> the audio stream progresses, as demonstrated here
>> (https://docs.microsoft.com/en-us/windows/win32/coreaudio/rendering-a-stream
>> <https://docs.microsoft.com/en-us/windows/win32/coreaudio/rendering-a-stream>).
>> Obviously, I'm not going to make the code as complicated as the code
>> shown in the aforementioned example, since this is UEFI and not an
>> operating system, and making it too complicated would make it
>> difficult to use and understand, something that I'd like to avoid.
>> Therefore, for protocol design, would this be satisfactory? Not all of
>> it needs to be finished for GSoC; I can implement stubs for those that
>> I don't have time to implement, but I'd like to discuss the protocol
>> before I start working on a driver for it. I have a (incomplete)
>> outline of a (hopefully) good protocol at
>> https://gist.github.com/ethindp/56066e0561b901c1e276e82ff469436d
>> <https://gist.github.com/ethindp/56066e0561b901c1e276e82ff469436d>. I'd
>> appreciate your thoughts on it.
>>
>
> I’d drop the Audio Input part of it. I don’t see a lot of use recording
> audio when you boot the system, and it is going to be a mess dealing with
> built in microphones etc. vs. input jacks etc. If we wanted to do input we
> could define a 2nd protocol that lives on the same handle for that.
>
> The EFI APIs don’t generally have enumeration members so I’d drop that part
> too. The driver is going to get started on a PCI device and that is how the
> device is going to be selection. So we should have a VirtIO Audio driver, a
> USB Audio driver, and an HDA Audio driver, not one driver that does
> everything. If there are common operations then
>
> I really think we need the volume and mute members. I did a prototype for
> the emulator a few years back and it looked like [1] as a simple abstract
> for HDA Audo to the system. I assume we could make this generic.
>
> The firmware really just wants to play the sound for the canned resource.
> The calling code is not some GUI app the user can configure. So I’m not sure
> of the value of having to pass in sampleRate, sampleCout, and sampleFormat.
> I think my proposal basically assumed PCM 16 via a WAVE file or some such.
> So basically the calling code just has to grab a source and pass it to the
> Audio protocol. That is how our GUIs work the artwork is in some encoding we
> can decode and that gets converted to something we can draw to the raw frame
> buffer.
>
>
>  [1] My prototype from a while while back.
>
> /** @file
>   Abstraction for audio modeled on the High Definition Audio Specification.
>
>
>   This API is targeted at "Code First" with the UEFI Forum. Thus the plan is
>
>   to potential make this a standard in the future and definition will then
> move
>   to the MdePkg, and EFI_GUID will likely change.
>
>   Copyright (c) 2018-2019 Rafael Machado
> <rafaelrodrigues.machado@gmail.com>
>   Copyright (c) 2019, Apple Inc. All rights reserved.<BR>
>   SPDX-License-Identifier: BSD-2-Clause-Patent
>
> **/
>
> #ifndef __HDA_AUDIO_H__
> #define __HDA_AUDIO_H__
>
> ///
> /// Global ID for the HDA Audio Protocol
> ///
>
> // 61EE0891-E13E-11E9-A1C7-823F7D860801
> #define CODE_FIRST_HDA_AUDIO_PROTOCOL_GUID \
>   { \
>     0x61EE0891, 0xE13E, 0x11E9, { 0xA1, 0xC7, 0x82, 0x3F, 0x7D, 0x86, 0x08,
> 0x01 } \
>   }
>
> typedef struct _CODE_FIRST_HDA_AUDIO_PROTOCOL
> CODE_FIRST_HDA_AUDIO_PROTOCOL;
>
>
> typedef INT32   HDA_GAIN;
>
>
> /**
>   The struct of Audio Token.
> **/
> typedef struct {
>
>   ///
>   /// Event will be signaled when the read audo has been played.
>   /// If only synchronous playback is supported the Event must still get
> signaled.
>   ///
>   EFI_EVENT               Event;
>
>   ///
>   /// Defines whether or not the signaled event encountered an error.
>   ///
>   EFI_STATUS              TransactionStatus;
> } CODE_FIRST_HDA_AUDIO_TOKEN;
>
>
>
> /**
>   Play synchronous or asynchronous audio. If Token is passed in the audio is
> played
>   asynchronously, if Token is NULL then this call blocks until the Audio is
> complete.
>
>   @param[in]      This         A pointer to the
> CODE_FIRST_HDA_AUDIO_PROTOCOL instance.
>   @param[in, out] Token        A pointer to the token associated with the
> transaction.
>                                If NULL this functions blocks until audio
> play back is complete.
>   @param[in]      Buffer       PCM encoded buffer of the audio to play.
>   @param[in ]     BufferSize   The size of Buffer in bytes.
>
>   @retval EFI_SUCCESS           The audio started playing.
>   @retval EFI_UNSUPPORTED       Buffer is not a supported format.
>   @retval EFI_OUT_OF_RESOURCES  The request could not be completed due to a
> lack of resources.
>   @retval EFI_INVALID_PARAMETER One or more parameters are invalid.
>
> **/
> typedef
> EFI_STATUS
> (EFIAPI *CODE_FIRST_HDA_AUDIO_PROTOCOL_PLAY_STREAM)(
>   IN     CODE_FIRST_HDA_AUDIO_PROTOCOL   *This,
>   IN OUT CODE_FIRST_HDA_AUDIO_TOKEN      *Token,     OPTIONAL
>   IN     UINT8                           *Buffer,
>   IN     UINT64                          BufferSize
>   );
>
>
> /**
>   Stop playing asynchronous audio.
>
>   @param[in]      This         A pointer to the
> CODE_FIRST_HDA_AUDIO_PROTOCOL instance.
>   @param[in, out] Token        A pointer to the token associated with the
> transaction.
>
>   @retval EFI_SUCCESS           Audio stopped playing.
>   @retval EFI_OUT_OF_RESOURCES  The request could not be completed due to a
> lack of resources.
>   @retval EFI_INVALID_PARAMETER One or more parameters are invalid.
>
> **/
> typedef
> EFI_STATUS
> (EFIAPI *CODE_FIRST_HDA_AUDIO_PROTOCOL_STOP_STREAM)(
>   IN     CODE_FIRST_HDA_AUDIO_PROTOCOL   *This,
>   IN     CODE_FIRST_HDA_AUDIO_TOKEN      *Token
>   );
>
>
> /**
>   Return the current volume for audio played by this protocol.
>
>   @param[in]      This         A pointer to the
> CODE_FIRST_HDA_AUDIO_PROTOCOL instance.
>   @param[out]     Gain         A pointer to the value returned between 0 and
> 100.
>
>   @retval EFI_SUCCESS           Gain was returned.
>   @retval EFI_OUT_OF_RESOURCES  The request could not be completed due to a
> lack of resources.
>   @retval EFI_INVALID_PARAMETER One or more parameters are invalid.
>
> **/
> typedef
> EFI_STATUS
> (EFIAPI *CODE_FIRST_HDA_AUDIO_PROTOCOL_GET_VOLUME)(
>   IN     CODE_FIRST_HDA_AUDIO_PROTOCOL  *This,
>   IN OUT HDA_GAIN                       *Gain
>   );
>
>
> /**
>   Set the current volume for audio played by this protocol.
>
>   The result of calling this function while audio is playing asynchronously
> is undefined.
>
>   @param[in]      This         A pointer to the
> CODE_FIRST_HDA_AUDIO_PROTOCOL instance.
>   @param[in]      Gain         A value between 0 and 100 to set the volume.
>
>
>   @retval EFI_SUCCESS           Gain was updated.
>   @retval EFI_OUT_OF_RESOURCES  The request could not be completed due to a
> lack of resources.
>   @retval EFI_INVALID_PARAMETER One or more parameters are invalid.
>
> **/
> typedef
> EFI_STATUS
> (EFIAPI *CODE_FIRST_HDA_AUDIO_PROTOCOL_SET_VOLUME)(
>   IN     CODE_FIRST_HDA_AUDIO_PROTOCOL    *This,
>   IN OUT HDA_GAIN                         Gain
>   );
>
>
> /**
>   Increment the volume in an implementation defined quanta. The value of the
> Gain can never
>   be over 100. The final successful call will round the volume increase to
> 100. If this
>   function is called an the Gain is already set to 100 EFI_NO_MAPPING must
> be returned.
>
>   The result of calling this function while audio is playing asynchronously
> is undefined.
>
>   @param[in]      This         A pointer to the
> CODE_FIRST_HDA_AUDIO_PROTOCOL instance.
>
>   @retval EFI_SUCCESS           Gain was incremented.
>   @retval EFI_NO_MAPPING        Gasin was not updated since it was already
> set to 100.
>   @retval EFI_OUT_OF_RESOURCES  The request could not be completed due to a
> lack of resources.
>   @retval EFI_INVALID_PARAMETER One or more parameters are invalid.
>
> **/
> typedef
> EFI_STATUS
> (EFIAPI *CODE_FIRST_HDA_AUDIO_PROTOCOL_VOLUME_UP)(
>   IN     CODE_FIRST_HDA_AUDIO_PROTOCOL   *This
>   );
>
>
> /**
>   Decrement the volume in an implementation defined quanta. The value of the
> Gain can never
>   be under 0. The final successful call will round the volume decrease to 0.
> If this
>   function is called an the Gain is already set to 0 EFI_NO_MAPPING must be
> returned.
>
>   The result of calling this function while audio is playing asynchronously
> is undefined.
>
>   @param[in]      This         A pointer to the
> CODE_FIRST_HDA_AUDIO_PROTOCOL instance.
>
>   @retval EFI_SUCCESS           Gain was decremented.
>   @retval EFI_NO_MAPPING        Gain was not updated since it was already
> set to 0.
>   @retval EFI_OUT_OF_RESOURCES  The request could not be completed due to a
> lack of resources.
>   @retval EFI_INVALID_PARAMETER One or more parameters are invalid.
>
> **/
> typedef
> EFI_STATUS
> (EFIAPI *CODE_FIRST_HDA_AUDIO_PROTOCOL_VOLUME_DOWN)(
>   IN     CODE_FIRST_HDA_AUDIO_PROTOCOL   *This
>   );
>
>
> /**
>   Mute audio output, but retain the current Gain (volume Level).
>
>   The result of calling this function while audio is playing asynchronously
> is undefined.
>
>   @param[in]      This         A pointer to the
> CODE_FIRST_HDA_AUDIO_PROTOCOL instance.
>
>   @retval EFI_SUCCESS           Audio was muted.
>   @retval EFI_ALREADY_STARTED   Audio is already muted.
>   @retval EFI_OUT_OF_RESOURCES  The request could not be completed due to a
> lack of resources.
>   @retval EFI_INVALID_PARAMETER One or more parameters are invalid.
>
> **/
> typedef
> EFI_STATUS
> (EFIAPI *CODE_FIRST_HDA_AUDIO_PROTOCOL_MUTE)(
>   IN     CODE_FIRST_HDA_AUDIO_PROTOCOL   *This
>   );
>
> /**
>   Unmute audio output, but retain the current Gain (volume Level).
>
>   The result of calling this function while audio is playing asynchronously
> is undefined.
>
>   @param[in]      This         A pointer to the
> CODE_FIRST_HDA_AUDIO_PROTOCOL instance.
>
>   @retval EFI_SUCCESS           Audio was muted.
>   @retval EFI_ALREADY_STARTED   Audio is already unmuted.
>   @retval EFI_OUT_OF_RESOURCES  The request could not be completed due to a
> lack of resources.
>   @retval EFI_INVALID_PARAMETER One or more parameters are invalid.
>
> **/
> typedef
> EFI_STATUS
> (EFIAPI *CODE_FIRST_HDA_AUDIO_PROTOCOL_UNMUTE)(
>   IN     CODE_FIRST_HDA_AUDIO_PROTOCOL   *This
>   );
>
>
> /**
>   Reset the audio hardware.
>
>   The result of calling this function while audio is playing asynchronously
> is undefined.
>
>   @param[in]      This         A pointer to the
> CODE_FIRST_HDA_AUDIO_PROTOCOL instance.
>
>   @retval EFI_SUCCESS           Audio was muted.
>   @retval EFI_OUT_OF_RESOURCES  The request could not be completed due to a
> lack of resources.
>   @retval EFI_INVALID_PARAMETER One or more parameters are invalid.
>
> **/
> typedef
> EFI_STATUS
> (EFIAPI *CODE_FIRST_HDA_AUDIO_PROTOCOL_RESET)(
>   IN     CODE_FIRST_HDA_AUDIO_PROTOCOL   *This
>   );
>
>
> #define HDA_AUDIO_VERSION 0x00010000
>
> ///
> /// The CODE_FIRST_HDA_AUDIO_PROTOCOL provides an abstraction for an Audio
> device that
> /// can play PCM files.
> /// There is one CODE_FIRST_HDA_AUDIO_PROTOCOL instance for each Audio
> Hardware device.
> ///
> struct _CODE_FIRST_HDA_AUDIO_PROTOCOL {
>   UINT64                                      Version;
>   CODE_FIRST_HDA_AUDIO_PROTOCOL_PLAY_STREAM   PlayStream;
>   CODE_FIRST_HDA_AUDIO_PROTOCOL_STOP_STREAM   StopStream;
>   CODE_FIRST_HDA_AUDIO_PROTOCOL_GET_VOLUME    GetVolume;
>   CODE_FIRST_HDA_AUDIO_PROTOCOL_SET_VOLUME    SetVolume;
>   CODE_FIRST_HDA_AUDIO_PROTOCOL_VOLUME_UP     VolumeUp;
>   CODE_FIRST_HDA_AUDIO_PROTOCOL_VOLUME_DOWN   VolumeDown;
>   CODE_FIRST_HDA_AUDIO_PROTOCOL_MUTE          Mute;
>   CODE_FIRST_HDA_AUDIO_PROTOCOL_UNMUTE        UnMute;
>   CODE_FIRST_HDA_AUDIO_PROTOCOL_RESET         Reset;
> };
>
> extern EFI_GUID gBz2387HdaAudioProtocolGuid;
>
> #endif
>
>
> Thanks,
>
> Andrew Fish
>
>> On 4/14/21, Andrew Fish <afish@apple.com <mailto:afish@apple.com>> wrote:
>>>
>>>
>>>> On Apr 14, 2021, at 3:30 PM, Kinney, Michael D
>>>> <michael.d.kinney@intel.com> wrote:
>>>>
>>>> Hi Ethin,
>>>>
>>>> Most UEFI Drivers do use polling.
>>>>
>>>> If it is a blocking I/O operation the UEFI Driver waits for completion.
>>>> Typically by polling a status register until the I/O is complete and
>>>> then
>>>> return status.
>>>>
>>>> If it is a non-blocking I/O Operation, then the UEFI Driver can create
>>>> a
>>>> timer event to periodically check the completion status.
>>>>
>>>> Non-blocking APIs may also use an event to know when the I/O operation
>>>> is
>>>> completed and this can be used with the CheckEvent() service to poll
>>>> for
>>>> event completion.
>>>>
>>>> These concepts are discussed in the UEFI Driver Writer's Guide.
>>>>
>>>> https://tianocore-docs.github.io/edk2-UefiDriverWritersGuide/draft/edk2-UefiDriverWritersGuide-draft.pdf
>>>> <https://tianocore-docs.github.io/edk2-UefiDriverWritersGuide/draft/edk2-UefiDriverWritersGuide-draft.pdf
>>>> <https://tianocore-docs.github.io/edk2-UefiDriverWritersGuide/draft/edk2-UefiDriverWritersGuide-draft.pdf>>
>>>>
>>>> Specifically for audio.  If there is an audio playback buffer that will
>>>> take some time to send,
>>>> the Audio Protocol would likely define a non-blocking interface to
>>>> start
>>>> playback.  You may need
>>>> an event that is signaled when more audio data is needed or when the
>>>> playback is complete.  You
>>>> will need to think about the consumer of the Audio Protocol and how it
>>>> will interact with the
>>>> Audio Protocol and if the consumer also needs to do other activities
>>>> while
>>>> audio is playing or
>>>> if it is ok for the consumer to wait until the audio playback is
>>>> completed.
>>>>
>>>
>>> Mike,
>>>
>>> It is likely we want async and synchronous playback. If you are playing
>>> a
>>> boot bong you don’t want to block on its completion. If you are doing a
>>> GUI
>>> UI you don’t want to block on playback and then do a bunch of GUI math
>>> etc.
>>>
>>>
>>> Ethin,
>>>
>>> I’d take a look at some example drivers like VirtioBlkDxe[1]. It also
>>> looks
>>> like there is already a VirtioLib[2] to help with house keeping. I did a
>>> quick skim and I don’t see a VirtIo device with an Event driven API.  It
>>> looks like VirtioNetDxe[3] does have the concept of a callback to poll
>>> [4],
>>> so you might be able to leverage that concept into a timer event to
>>> check
>>> for completion.
>>>
>>> I’d not get hung up on the asynchronous part of the API. It might make
>>> sense
>>> to implement the synchronous version of the API in the driver 1st and
>>> fake
>>> the async for your 1st pass.
>>>
>>> If you look at other UEFI Async APIs they generally pass around a Token
>>> (usually an Event to signal on completion, and an EFI_STATUS)[5]. Thus
>>> faking the Async means making it look like the event fired before your
>>> API
>>> returned. Assuming that *Token is an argument to the protocol you do this
>>> to
>>> fake the Async transaction….
>>>
>>> If (Token != NULL) {
>>>  Token->TransactionStatus = Status;
>>>  gBS->SignalEvent (Token->Event);
>>> }
>>>
>>> This just make it look to the caller like the transaction completed by
>>> the
>>> time you returned to the caller. So from a caller perspective that is a
>>> valid way the API could work. The other upside to this is you can make a
>>> UEFI Shell App to test the protocol and also add a path to test the
>>> async
>>> API, even if for the 1st pass implementation that is faked out.
>>>
>>> [1] https://github.com/tianocore/edk2/tree/master/OvmfPkg/VirtioBlkDxe
>>> [2]
>>> https://github.com/tianocore/edk2/blob/master/OvmfPkg/Library/VirtioLib/VirtioLib.c
>>> [3] https://github.com/tianocore/edk2/tree/master/OvmfPkg/VirtioNetDxe
>>> [4]
>>> https://github.com/tianocore/edk2/blob/master/OvmfPkg/VirtioNetDxe/Events.c#L32
>>> [5]
>>> https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/BlockIo2.h#L41
>>>
>>> Thanks,
>>>
>>> Andrew Fish
>>>
>>>> Mike
>>>>
>>>>> -----Original Message-----
>>>>> From: devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
>>>>> <devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>> On Behalf
>>>>> Of Ethin
>>>>> Probst
>>>>> Sent: Wednesday, April 14, 2021 1:48 PM
>>>>> To: Andrew Fish <afish@apple.com <mailto:afish@apple.com>
>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>>>
>>>>> Cc: edk2-devel-groups-io <devel@edk2.groups.io
>>>>> <mailto:devel@edk2.groups.io>
>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>>; Leif
>>>>> Lindholm <leif@nuviainc.com <mailto:leif@nuviainc.com>
>>>>> <mailto:leif@nuviainc.com <mailto:leif@nuviainc.com>>>; Laszlo Ersek
>>>>> <lersek@redhat.com <mailto:lersek@redhat.com>
>>>>> <mailto:lersek@redhat.com <mailto:lersek@redhat.com>>>;
>>>>> Desimone, Nathaniel L <nathaniel.l.desimone@intel.com
>>>>> <mailto:nathaniel.l.desimone@intel.com>
>>>>> <mailto:nathaniel.l.desimone@intel.com
>>>>> <mailto:nathaniel.l.desimone@intel.com>>>; Rafael Rodrigues Machado
>>>>> <rafaelrodrigues.machado@gmail.com
>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>>; Gerd
>>>>> Hoffmann <kraxel@redhat.com <mailto:kraxel@redhat.com>
>>>>> <mailto:kraxel@redhat.com <mailto:kraxel@redhat.com>>>
>>>>> Subject: Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)
>>>>>
>>>>> These are some pretty good suggestions; however, while reading through
>>>>> the VirtIO specification again yesterday, I (re)-discovered that
>>>>> VirtIO devices are usually interrupt based. In particular, a VirtIO
>>>>> PCI/PCIe device defines the common, notifications, ISR status,
>>>>> device-specific configuration, PCI configuration access, shared memory
>>>>> region, and vendor-specific data capability structures in PCI
>>>>> configuration space. It doesn't look like the EFI_CREATE_EVENT or
>>>>> EFI_CREATE_EVENT_EX function works via interrupts, from what I can
>>>>> tell. I'm not sure but it doesn't seem like there's a way I can poll
>>>>> the device, though I might be missing something.
>>>>> The idea for the generic protocol is good. The interrupt issue might
>>>>> be a problem though and I'm not sure how to actually solve that.
>>>>>
>>>>> On 4/13/21, Andrew Fish <afish@apple.com <mailto:afish@apple.com>>
>>>>> wrote:
>>>>>> Ethin,
>>>>>>
>>>>>> In terms of defining the protocol stack it is good to start with the
>>>>>> producers and consumers and think about the problem from both
>>>>>> perspectives.
>>>>>> It is easy enough to think about the producer part of it as you are
>>>>>> thinking
>>>>>> about writing the driver. The driver is going to consume things like
>>>>>> the
>>>>>> PCI
>>>>>> I/O Protocol.
>>>>>>
>>>>>> The consumer of the sound Protocol is going to most likely be generic
>>>>>> EFI
>>>>>> platform code, and possibly an OS loader. In the boot process Audio
>>>>>> has
>>>>>> traditionally be used for error codes, sign of life (for example the
>>>>>> famous
>>>>>> Mac startup sound). We are also would like to have the option of
>>>>>> enabling
>>>>>> better accessibility features, especially for people how are visually
>>>>>> impaired. These days a lot of software engineers think of disk space
>>>>>> as
>>>>>> free
>>>>>> and really don’t consider the size of software, but this is not true
>>>>>> for
>>>>>> firmware. Firmware generally lives in NOR FLASH that is considered
>>>>>> expensive
>>>>>> (it is more expensive than NAND, but at the same time more reliable)
>>>>>> so
>>>>>> firmware implementations are constrained by the size of the code that
>>>>>> can be
>>>>>> carried, and the size of assets/resources that can be used for user
>>>>>> interfaces. The OS loader is some what less constrained, but it still
>>>>>> has to
>>>>>> share the EFI System Partition on the disk with potentially other OS
>>>>>> loaders.
>>>>>>
>>>>>> So the consumer wants a protocol that is unleveled and focused on the
>>>>>> task
>>>>>> at hand. I’m not too caught up on the names but in general I think
>>>>>> things
>>>>>> you want are (How many knobs we need is probably better answered by
>>>>>> an
>>>>>> audiophile, and that is not me):
>>>>>> 1) CompatibleBuffer() - Does driver support this buffer format.
>>>>>> 2) PlayBuffer() - Play the sound
>>>>>> 	a) We probably want a synchronous and asynchronous version of this
>>>>>> API.
>>>>>> For
>>>>>> example you don’t want to slow down the boot to wait for a boot beep
>>>>>> to
>>>>>> complete, and you may chose to implement an API that waits for the
>>>>>> sound
>>>>>> to
>>>>>> complete (and do some GUI work in parallel) vs. blocking on the
>>>>>> sound.
>>>>>> 	b) async in EFI usually means you return a pointer to an EFI_EVENT
>>>>>> that
>>>>>> gets signaled on completion.
>>>>>> 3) StopBuffer() - In case the asynchronous PlayBuffer() needs to be
>>>>>> stopped.
>>>>>> Think error exit.
>>>>>> 3) SetVolume()/GetVolume() - Set/Get Volume in units of 0 - 100
>>>>>> (trying
>>>>>> to
>>>>>> avoid db as that gets into capability and math that is likely best
>>>>>> abstracted by the driver)?
>>>>>> 4) Mute()/UnMute() - Mute and volume are often independent features in
>>>>>> a
>>>>>> UI
>>>>>> keeping them separate in API makes it easier to implement things.
>>>>>> 5) PlayTone() - Maybe for error sounds that don’t require canned
>>>>>> sound
>>>>>> files. Maybe TimeOn, TimeOff, Frequency, and how many times to
>>>>>> repeat.
>>>>>> 6) Do we need tuning values or Tone settings?
>>>>>>
>>>>>> At some point we might consider defining nvram variable for the
>>>>>> default
>>>>>> state of some of the tunable, especially mute and volume. For example
>>>>>> the
>>>>>> user may want to turn off all volume on the system so it would be
>>>>>> nice
>>>>>> if
>>>>>> the OS can set the EFI volume and mute. In the short run we can
>>>>>> probably
>>>>>> use
>>>>>> PCD values to set the default values.
>>>>>>
>>>>>> So I think we have a generic AUDIO API on top and likely a PCI I/O on
>>>>>> the
>>>>>> bottom. If we need more protocols to manage hardware devices then
>>>>>> those
>>>>>> protocols can be defined in the context of that hardware. So for
>>>>>> example
>>>>>> we
>>>>>> would probably end up with an HDA_CODEC protocol. I think the best
>>>>>> way
>>>>>> to
>>>>>> think about this is a disk. A lot of disk adapters just produce a raw
>>>>>> Block
>>>>>> I/O  protocol, but for a more common bus like ATA or SCSI you might
>>>>>> have
>>>>>> an
>>>>>> extra driver in place to make the common bits common code. I think
>>>>>> some
>>>>>> of
>>>>>> the same layers may be in place here. So likely VirtIo is simple and
>>>>>> just
>>>>>> produces the generic AUDIO API, while an HDA audio driver also has to
>>>>>> abstract some of the complexity of its hardware implementation and
>>>>>> standard.
>>>>>>
>>>>>>
>>>>>> In terms of picking the set of APIs and tunables it is probably good
>>>>>> to
>>>>>> start with VirtIo and USB and see what set make sense and what you
>>>>>> could
>>>>>> and
>>>>>> could not implement. HDA Audio is so complex you might want to look
>>>>>> at
>>>>>> it in
>>>>>> terms of the minute you have to implement to make it function. Think
>>>>>> what
>>>>>> assumptions are you forced to make to implement.
>>>>>>
>>>>>> This is a vey 10,000 foot view to start with. I think you will need
>>>>>> to
>>>>>> mix
>>>>>> this in the the reality of how it works in the real world to figure
>>>>>> out
>>>>>> the
>>>>>> right abstraction, but then again that is the beauty of having an
>>>>>> implementation. Likely also get some feedback from audiophiles.
>>>>>>
>>>>>> Oh and make sure you don’t go off an implement a lot of code just
>>>>>> because we
>>>>>> chose the wrong complexity or abstraction point. This is the one time
>>>>>> we
>>>>>> get
>>>>>> to change the public APIs so lets feel free to adjust them to make
>>>>>> the
>>>>>> most
>>>>>> sense for the job at hand.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Andrew Fish
>>>>>>
>>>>>>> On Apr 13, 2021, at 6:20 PM, Ethin Probst <harlydavidsen@gmail.com
>>>>>>> <mailto:harlydavidsen@gmail.com>>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Okay, so looking at the EDK2 driver developers guide, here are my
>>>>>>> thoughts:
>>>>>>>
>>>>>>> - Each audio driver will be a bus driver, even if it doesn't control
>>>>>>> buses in the traditional sense.
>>>>>>> - I think the initialization sequence should be different: there
>>>>>>> should be an AudioDxe, but it should contain three separate bus
>>>>>>> drivers for each kind of audio device supported.
>>>>>>> - For the VirtIO audio device driver, it'll most likely consume the
>>>>>>> PCI I/O protocol and produce the EFI_VIRTIO_AUDIO_OUTPUT_PROTOCOL
>>>>>>> and
>>>>>>> EFI_VIRTIO_AUDIO_INPUT_PROTOCOL protocols. This will just be an
>>>>>>> ordinary UEFI device driver.
>>>>>>> - The HDA audio device driver will consume the PCI I/O protocol and
>>>>>>> will produce different device handles per HDA controller found. I'd
>>>>>>> produce a handle per codec, but that seems overkill. Each handle
>>>>>>> will
>>>>>>> be attached to both an audio stream protocol and a controller
>>>>>>> management protocol. The audio stream protocol will manage the
>>>>>>> creation, control, and deletion of audio streams as well as the
>>>>>>> processing of audio data. The controller management protocol is
>>>>>>> responsible for allowing applications or other drivers to manage the
>>>>>>> HDA controller itself.
>>>>>>>
>>>>>>> I haven't planned for the USB audio device driver yet, but these are
>>>>>>> my thoughts so far. What do you guys think? Am I over-complicating
>>>>>>> this setup? How can it be improved upon?
>>>>>>>
>>>>>>> On 4/13/21, Ethin Probst via groups.io <http://groups.io/>
>>>>>>> <http://groups.io/ <http://groups.io/>>
>>>>>>> <harlydavidsen=gmail.com@groups.io
>>>>>>> <mailto:harlydavidsen=gmail.com@groups.io>
>>>>>>> <mailto:harlydavidsen=gmail.com@groups.io
>>>>>>> <mailto:harlydavidsen=gmail.com@groups.io>>> wrote:
>>>>>>>> Hi Andrew,
>>>>>>>>
>>>>>>>> The developer guide for EDK2 drivers is a godsend. Thank you very
>>>>>>>> much, and thank you, Mike, for your excellent work on the guide! I
>>>>>>>> may
>>>>>>>> just ahve to do my building on Linux and not Windows -- unless the
>>>>>>>> Bug
>>>>>>>> -- bug 3302 -- has been fixed. I'll have to do testing on Linux, at
>>>>>>>> any rate, since Windows hosts do not support VirtIO emulation and I
>>>>>>>> can't seem to find any way of emulating them in a guest machine
>>>>>>>> with
>>>>>>>> Windows as a host.
>>>>>>>>
>>>>>>>> On 4/13/21, Andrew Fish <afish@apple.com <mailto:afish@apple.com>
>>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>>>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On Apr 13, 2021, at 9:53 AM, Ethin Probst <harlydavidsen@gmail.com
>>>>>>>>>> <mailto:harlydavidsen@gmail.com>>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Would it be possible for us to conduct discussion on the UEFI
>>>>>>>>>> talkbox?
>>>>>>>>>> I don't mind using email, but things could definitely get moving
>>>>>>>>>> quicker over there (though its not a requirement obviously).
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Sure, don’t think I’ve really used that but as long as I get
>>>>>>>>> pointed
>>>>>>>>> int
>>>>>>>>> he
>>>>>>>>> right direction I can make it work.
>>>>>>>>>
>>>>>>>>> For a device driver the general UEFI model is for the Entry point
>>>>>>>>> of
>>>>>>>>> the
>>>>>>>>> driver to publish a EFI_DRIVER_BINDING_PROTOCOL[1]. The
>>>>>>>>> Supported()
>>>>>>>>> function
>>>>>>>>> matches on the PCI devices. The Start() function installs the
>>>>>>>>> Protocols
>>>>>>>>> to
>>>>>>>>> do work, and the Stop() undoes the Start().
>>>>>>>>>
>>>>>>>>> Mike Kinney started this back in the day and it describes how to
>>>>>>>>> write
>>>>>>>>> UEFI
>>>>>>>>> drivers:
>>>>>>>>> https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Driver-Writer%27s-Guide
>>>>>>>>> <https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Driver-Writer%27s-Guide>
>>>>>>>>>
>>>>>>>>> [1]https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/DriverBinding.h#L157
>>>>>>>>> <https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/DriverBinding.h#L157>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Andrew Fish
>>>>>>>>>
>>>>>>>>>> Here's how I generally envision the driver functioning:
>>>>>>>>>>
>>>>>>>>>> 1. Firmware/platform code calls InitaudioOutput() or something
>>>>>>>>>> like
>>>>>>>>>> it. This function scans the PCIe bus and scans for one of the
>>>>>>>>>> following:
>>>>>>>>>> - Vendor ID 0x1AF4, device ID 0x1059: VirtIO sound device
>>>>>>>>>> - PCI class 0x0C, subclass 0x03, program interface 0x30 or 0x40:
>>>>>>>>>> for
>>>>>>>>>> USB audio interface (I'm only thinking of targeting XHCI and USB
>>>>>>>>>> 4,
>>>>>>>>>> and not UHCI, OHCI or EHCI). But maybe EDK2 will take that out of
>>>>>>>>>> my
>>>>>>>>>> hands. If so, it will make things easier.
>>>>>>>>>> - For USB audio devices I'm not quite sure what to look for; I'm
>>>>>>>>>> definitely unused to USB.
>>>>>>>>>> 2. If any of the above cases are found, appropriate driver
>>>>>>>>>> initialization occurs. Since for the time being I am solely
>>>>>>>>>> focusing
>>>>>>>>>> on VirtIO sound devices, the VirtIO general initialization
>>>>>>>>>> sequence
>>>>>>>>>> will occur as outlined in sec. 3 of the VirtIO specification
>>>>>>>>>> available
>>>>>>>>>> at https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html
>>>>>>>>>> <https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html>
>>>>>>>>>> <https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html
>>>>>>>>>> <https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html>
>>>>>>>>>> <https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html
>>>>>>>>>> <https://www.kraxel.org/virtio/virtio-v1.1-cs01-sound-v7.html>>>.
>>>>>>>>>> As for actual protocol exposure that would be spec-worthy, for
>>>>>>>>>> EFI_AUDIO_OUTPUT_PROTOCOL, I'm not quite sure what to expose.
>>>>>>>>>> VirtIO
>>>>>>>>>> is rather simple: there's a buffer for sending and receiving
>>>>>>>>>> audio
>>>>>>>>>> data in PCM streams. So for that we could expose a Reset(),
>>>>>>>>>> RemapJack(), GetJackConfig(), GetPcmConfig(), SetPcmParams(),
>>>>>>>>>> Prepare(), Release(), Start(), and Stop() function for the
>>>>>>>>>> corresponding request types VIRTIO_SND_R_JACK_GET_CONFIG,
>>>>>>>>>> VIRTIO_SND_R_JACK_REMAP, VIRTIO_SND_R_PCM_GET_CONFIG,
>>>>>>>>>> VIRTIO_SND_R_PCM_SET_PARAMS, VIRTIO_SND_R_PCM_PREPARE,
>>>>>>>>>> VIRTIO_SND_R_PCM_RELEASE, VIRTIO_SND_R_PCM_START, and
>>>>>>>>>> VIRTIO_SND_R_PCM_STOP control requests. However, for HDA things
>>>>>>>>>> are
>>>>>>>>>> a
>>>>>>>>>> lot more complex, so I'm not sure how that should work.
>>>>>>>>>> For VirtIO -- which is what I'll focus on for now -- everything
>>>>>>>>>> is
>>>>>>>>>> described, in excellent detail, in sec. 5.14 of the above-linked
>>>>>>>>>> document. What are your guys's thoughts thus far and how should
>>>>>>>>>> everything be mapped to UEFI interfaces?
>>>>>>>>>>
>>>>>>>>>> On 4/13/21, Andrew Fish <afish@apple.com <mailto:afish@apple.com>
>>>>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>>
>>>>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>
>>>>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>>>>
>>>>>>>>>> wrote:
>>>>>>>>>>> Leif,
>>>>>>>>>>>
>>>>>>>>>>> Since I have put some brain cells around this area in the past I
>>>>>>>>>>> can
>>>>>>>>>>> be
>>>>>>>>>>> the
>>>>>>>>>>> backup and help out too.
>>>>>>>>>>>
>>>>>>>>>>> I’d also point out if you are having issues building or have
>>>>>>>>>>> general
>>>>>>>>>>> questions on how things work it is fine to use the mailing list.
>>>>>>>>>>> I’ve
>>>>>>>>>>> got
>>>>>>>>>>> a
>>>>>>>>>>> lot of feedback that folks read or search the mailing list
>>>>>>>>>>> looking
>>>>>>>>>>> for
>>>>>>>>>>> answer to their questions so one person asking can help out a
>>>>>>>>>>> lot
>>>>>>>>>>> of
>>>>>>>>>>> other
>>>>>>>>>>> people.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>
>>>>>>>>>>> Andrew Fish
>>>>>>>>>>>
>>>>>>>>>>>> On Apr 13, 2021, at 5:28 AM, Leif Lindholm <leif@nuviainc.com
>>>>>>>>>>>> <mailto:leif@nuviainc.com>
>>>>>>>>>>>> <mailto:leif@nuviainc.com <mailto:leif@nuviainc.com>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi all, especially Ethin.
>>>>>>>>>>>>
>>>>>>>>>>>> Apologies for radio silence - last week I was off on holiday,
>>>>>>>>>>>> and
>>>>>>>>>>>> before
>>>>>>>>>>>> that ... let's just say corporate acquisitions generate some
>>>>>>>>>>>> distractions.
>>>>>>>>>>>> Anyway, I'm back, and since I'm down as the mentor for this
>>>>>>>>>>>> task,
>>>>>>>>>>>> feel
>>>>>>>>>>>> free to spam me with any remaining/new questions.
>>>>>>>>>>>>
>>>>>>>>>>>> /
>>>>>>>>>>>> Leif
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Apr 6, 2021 at 4:17 PM Ethin Probst
>>>>>>>>>>>> <harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>>
>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>>
>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>>>>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>> I'll attach the bug for the build tools to the BZ shortly.
>>>>>>>>>>>> Laszlo, thanks for that. I don't know their email addresses
>>>>>>>>>>>> though.
>>>>>>>>>>>> And yes, I was going to make it device independent, as the
>>>>>>>>>>>> majority
>>>>>>>>>>>> (if not all) of UEFI protocols are.
>>>>>>>>>>>>
>>>>>>>>>>>> On 4/6/21, Laszlo Ersek <lersek@redhat.com
>>>>>>>>>>>> <mailto:lersek@redhat.com>
>>>>>>>>>>>> <mailto:lersek@redhat.com <mailto:lersek@redhat.com>>
>>>>>>>>>>>> <mailto:lersek@redhat.com <mailto:lersek@redhat.com>
>>>>>>>>>>>> <mailto:lersek@redhat.com <mailto:lersek@redhat.com>>>
>>>>>>>>>>>> <mailto:lersek@redhat.com <mailto:lersek@redhat.com>
>>>>>>>>>>>> <mailto:lersek@redhat.com <mailto:lersek@redhat.com>>
>>>>>>>>>>>> <mailto:lersek@redhat.com <mailto:lersek@redhat.com>
>>>>>>>>>>>> <mailto:lersek@redhat.com <mailto:lersek@redhat.com>>>>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> On 03/31/21 08:41, Nate DeSimone wrote:
>>>>>>>>>>>>>> Another option is to put the protocol definition in
>>>>>>>>>>>>>> MdeModulePkg
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>> mark it with the EDKII_ prefix. For my last “code first” UEFI
>>>>>>>>>>>>>> spec
>>>>>>>>>>>>>> contribution I did this with the PPI that added up getting
>>>>>>>>>>>>>> added.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The new audio protocol should be generic, only its
>>>>>>>>>>>>> implementation
>>>>>>>>>>>>> in
>>>>>>>>>>>>> question should be virtio specific.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please include Gerd Hoffmann (CC'd) in the protocol design, as
>>>>>>>>>>>>> well
>>>>>>>>>>>>> as
>>>>>>>>>>>>> the developers of the virtio-sound device model in QEMU.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>> Laszlo
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Nate
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *From: *<devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
>>>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>>
>>>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
>>>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>>>>>>>>>>> <mailto:devel@edk2.groups.io
>>>>>>>>>>>>>> <mailto:devel@edk2.groups.io>>>>>
>>>>>>>>>>>>>> on
>>>>>>>>>>>>>> behalf
>>>>>>>>>>>>>> of "Andrew Fish via groups.io <http://groups.io/>
>>>>>>>>>>>>>> <http://groups.io/ <http://groups.io/>>
>>>>>>>>>>>>>> <http://groups.io/ <http://groups.io/> <http://groups.io/
>>>>>>>>>>>>>> <http://groups.io/>>> <http://groups.io/ <http://groups.io/>
>>>>>>>>>>>>>> <http://groups.io/ <http://groups.io/>>
>>>>>>>>>>>>>> <http://groups.io/ <http://groups.io/> <http://groups.io/
>>>>>>>>>>>>>> <http://groups.io/>>>>"
>>>>>>>>>>>>>> <afish=apple.com@groups.io <mailto:afish=apple.com@groups.io>
>>>>>>>>>>>>>> <mailto:afish=apple.com@groups.io
>>>>>>>>>>>>>> <mailto:afish=apple.com@groups.io>>
>>>>>>>>>>>>>> <mailto:afish=apple.com@groups.io
>>>>>>>>>>>>>> <mailto:afish=apple.com@groups.io>
>>>>>>>>>>>>>> <mailto:afish=apple.com@groups.io
>>>>>>>>>>>>>> <mailto:afish=apple.com@groups.io>>>
>>>>>>>>>>>>>> <mailto:apple.com@groups.io <mailto:apple.com@groups.io>
>>>>>>>>>>>>>> <mailto:apple.com@groups.io <mailto:apple.com@groups.io>>
>>>>>>>>>>>>>> <mailto:apple.com@groups.io <mailto:apple.com@groups.io>
>>>>>>>>>>>>>> <mailto:apple.com@groups.io <mailto:apple.com@groups.io>>>>>
>>>>>>>>>>>>>> *Reply-To: *"devel@edk2.groups.io
>>>>>>>>>>>>>> <mailto:devel@edk2.groups.io> <mailto:devel@edk2.groups.io
>>>>>>>>>>>>>> <mailto:devel@edk2.groups.io>>
>>>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>>
>>>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
>>>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>>>>>>>>>>> <mailto:devel@edk2.groups.io
>>>>>>>>>>>>>> <mailto:devel@edk2.groups.io>>>>"
>>>>>>>>>>>>>> <devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
>>>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>>
>>>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
>>>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>>>>>>>>>>> <mailto:devel@edk2.groups.io
>>>>>>>>>>>>>> <mailto:devel@edk2.groups.io>>>>>,
>>>>>>>>>>>>>> "afish@apple.com <mailto:afish@apple.com>
>>>>>>>>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>>
>>>>>>>>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>
>>>>>>>>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>>>
>>>>>>>>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>
>>>>>>>>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>>
>>>>>>>>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>
>>>>>>>>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>>>>"
>>>>>>>>>>>>>> <afish@apple.com <mailto:afish@apple.com>
>>>>>>>>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>>
>>>>>>>>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>
>>>>>>>>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>>>
>>>>>>>>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>
>>>>>>>>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>>
>>>>>>>>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>
>>>>>>>>>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>>>>>
>>>>>>>>>>>>>> *Date: *Tuesday, March 30, 2021 at 10:54 PM
>>>>>>>>>>>>>> *To: *edk2-devel-groups-io <devel@edk2.groups.io
>>>>>>>>>>>>>> <mailto:devel@edk2.groups.io>
>>>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
>>>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>>
>>>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
>>>>>>>>>>>>>> <mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>>>>>>>>>>> <mailto:devel@edk2.groups.io
>>>>>>>>>>>>>> <mailto:devel@edk2.groups.io>>>>>,
>>>>>>>>>>>>>> "harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>>
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>>>
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>>
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>>>>"
>>>>>>>>>>>>>> <harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>>
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>>>
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>>
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>>>>>
>>>>>>>>>>>>>> *Cc: *Rafael Rodrigues Machado
>>>>>>>>>>>>>> <rafaelrodrigues.machado@gmail.com
>>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>
>>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>>
>>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>
>>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>>>>
>>>>>>>>>>>>>> *Subject: *Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mar 30, 2021, at 5:01 PM, Ethin Probst
>>>>>>>>>>>>>> <harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>>
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>>>
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>>
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>>>>
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>>
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>>>
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>>
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>>>>>>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm wondering where exactly I should add the VirtIO sound
>>>>>>>>>>>>>> protocol.
>>>>>>>>>>>>>> I
>>>>>>>>>>>>>> just familiarized myself with the build system and am about
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>> test
>>>>>>>>>>>>>> it
>>>>>>>>>>>>>> by building OVMF if possible, but I'm wondering where I
>>>>>>>>>>>>>> should
>>>>>>>>>>>>>> actually put the protocol and all that stuff. Maybe there's
>>>>>>>>>>>>>> documentation I've missed as well.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ethin,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> For the driver I’d match the patter of OVMF [1] and use
>>>>>>>>>>>>>> OvmfPkg/VirtioSoundDxe/. Maybe even use one of the other
>>>>>>>>>>>>>> drivers
>>>>>>>>>>>>>> as
>>>>>>>>>>>>>> a
>>>>>>>>>>>>>> template.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The protocol is more of a public thing. I think eventually we
>>>>>>>>>>>>>> would
>>>>>>>>>>>>>> like
>>>>>>>>>>>>>> to publish the protocol in the UEFI Spec (I can help with
>>>>>>>>>>>>>> that
>>>>>>>>>>>>>> part)
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>> that would mean we put the Protocol definition in
>>>>>>>>>>>>>> MdePkg/Include/Protocol, but we don’t want to do that before
>>>>>>>>>>>>>> it
>>>>>>>>>>>>>> is
>>>>>>>>>>>>>> standardized as that causes compatibility issues. So this is
>>>>>>>>>>>>>> a
>>>>>>>>>>>>>> “code
>>>>>>>>>>>>>> first project” (code prototype and then contribute to the
>>>>>>>>>>>>>> UEFI
>>>>>>>>>>>>>> Forum
>>>>>>>>>>>>>> for
>>>>>>>>>>>>>> inclusion in the specification) so we need to follow some
>>>>>>>>>>>>>> code
>>>>>>>>>>>>>> first
>>>>>>>>>>>>>> rules that I don’t remember of the top of my head? So why not
>>>>>>>>>>>>>> start
>>>>>>>>>>>>>> out
>>>>>>>>>>>>>> the protocol definition OvmfPkg/Include/Protocol. You can
>>>>>>>>>>>>>> also
>>>>>>>>>>>>>> add
>>>>>>>>>>>>>> a
>>>>>>>>>>>>>> test application looks like you can just use the root [2] of
>>>>>>>>>>>>>> OVMF
>>>>>>>>>>>>>> for
>>>>>>>>>>>>>> that. That way the project is not blocked.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> We can have a conversation on the mailing list about better
>>>>>>>>>>>>>> places
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>> put stuff, and it should be easy enough to move stuff around
>>>>>>>>>>>>>> if
>>>>>>>>>>>>>> everything else is working.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [1] find OvmfPkg  -iname '*Virtio*.inf'
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> OvmfPkg/VirtioScsiDxe/VirtioScsi.inf
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> OvmfPkg/Library/VirtioMmioDeviceLib/VirtioMmioDeviceLib.inf
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> OvmfPkg/Library/VirtioLib/VirtioLib.inf
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> OvmfPkg/VirtioGpuDxe/VirtioGpu.inf
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> OvmfPkg/VirtioBlkDxe/VirtioBlk.inf
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> OvmfPkg/Virtio10Dxe/Virtio10.inf
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> OvmfPkg/VirtioNetDxe/VirtioNet.inf
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> OvmfPkg/VirtioRngDxe/VirtioRng.inf
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> [2] /Volumes/Case/edk2-github/OvmfPkg>git grep APPLICATION --
>>>>>>>>>>>>>> *.inf
>>>>>>>>>>>>>> |
>>>>>>>>>>>>>> grep MODULE_TYPE
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> EnrollDefaultKeys/EnrollDefaultKeys.inf:13:  MODULE_TYPE
>>>>>>>>>>>>>> = UEFI_APPLICATION
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Andrew Fish
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 3/30/21, Ethin Probst via groups.io <http://groups.io/>
>>>>>>>>>>>>>> <http://groups.io/ <http://groups.io/>>
>>>>>>>>>>>>>> <http://groups.io/ <http://groups.io/> <http://groups.io/
>>>>>>>>>>>>>> <http://groups.io/>>>
>>>>>>>>>>>>>> <http://groups.io/ <http://groups.io/> <http://groups.io/
>>>>>>>>>>>>>> <http://groups.io/>> <http://groups.io/ <http://groups.io/>
>>>>>>>>>>>>>> <http://groups.io/ <http://groups.io/>>>>
>>>>>>>>>>>>>> <http://groups.io/ <http://groups.io/> <http://groups.io/
>>>>>>>>>>>>>> <http://groups.io/>> <http://groups.io/ <http://groups.io/>
>>>>>>>>>>>>>> <http://groups.io/ <http://groups.io/>>> <http://groups.io/
>>>>>>>>>>>>>> <http://groups.io/> <http://groups.io/ <http://groups.io/>>
>>>>>>>>>>>>>> <http://groups.io/ <http://groups.io/> <http://groups.io/
>>>>>>>>>>>>>> <http://groups.io/>>>>>
>>>>>>>>>>>>>> <harlydavidsen=gmail.com@groups.io
>>>>>>>>>>>>>> <mailto:harlydavidsen=gmail.com@groups.io>
>>>>>>>>>>>>>> <mailto:harlydavidsen=gmail.com@groups.io
>>>>>>>>>>>>>> <mailto:harlydavidsen=gmail.com@groups.io>>
>>>>>>>>>>>>>> <mailto:harlydavidsen=gmail.com@groups.io
>>>>>>>>>>>>>> <mailto:harlydavidsen=gmail.com@groups.io>
>>>>>>>>>>>>>> <mailto:harlydavidsen=gmail.com@groups.io
>>>>>>>>>>>>>> <mailto:harlydavidsen=gmail.com@groups.io>>>
>>>>>>>>>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>
>>>>>>>>>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>>
>>>>>>>>>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>
>>>>>>>>>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>>>>
>>>>>>>>>>>>>> <mailto:harlydavidsen
>>>>>>>>>>>>>> <mailto:harlydavidsen>=gmail.com@groups.io
>>>>>>>>>>>>>> <mailto:gmail.com@groups.io>
>>>>>>>>>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>>
>>>>>>>>>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>
>>>>>>>>>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>>>
>>>>>>>>>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>
>>>>>>>>>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>>
>>>>>>>>>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>
>>>>>>>>>>>>>> <mailto:gmail.com@groups.io <mailto:gmail.com@groups.io>>>>>>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     I agree. Plus, it gives me a chance to finally learn the
>>>>>>>>>>>>>> EDK2
>>>>>>>>>>>>>> build
>>>>>>>>>>>>>>     system and how it works! I've been working on a hobby OS
>>>>>>>>>>>>>> as
>>>>>>>>>>>>>> a
>>>>>>>>>>>>>> side
>>>>>>>>>>>>>>     project and, though learning from other code examples
>>>>>>>>>>>>>> from
>>>>>>>>>>>>>> OSes
>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>     fun, I have to say that learning from the firmware code
>>>>>>>>>>>>>> like
>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>     SeaBIOS has been some of the most enlightening and
>>>>>>>>>>>>>> interesting
>>>>>>>>>>>>>> times
>>>>>>>>>>>>>>     thus far.
>>>>>>>>>>>>>>     Thanks for the link to your code, Rafael; once I get
>>>>>>>>>>>>>> virtIO
>>>>>>>>>>>>>> support
>>>>>>>>>>>>>>     in, I can work on HDA support, though I might tackle USB
>>>>>>>>>>>>>> support
>>>>>>>>>>>>>>     second and HDA third. We'll see, but VirtIO definitely is
>>>>>>>>>>>>>> coming
>>>>>>>>>>>>>>     first.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     As I said before, I look forward to working with all of
>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>     wonderful
>>>>>>>>>>>>>>     people!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     On 3/30/21, Rafael Rodrigues Machado
>>>>>>>>>>>>>>     <rafaelrodrigues.machado@gmail.com
>>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>
>>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>>
>>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>
>>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>>>
>>>>>>>>>>>>>>     <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>
>>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>>
>>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>
>>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>
>>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com
>>>>>>>>>>>>>> <mailto:rafaelrodrigues.machado@gmail.com>>>>>>
>>>>>>>>>>>>>>     wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>         This would be amazing so people can continue my work
>>>>>>>>>>>>>> related
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>         accessibility at BIOS. Something desired by the blind
>>>>>>>>>>>>>> people
>>>>>>>>>>>>>>         since the
>>>>>>>>>>>>>>         90's
>>>>>>>>>>>>>>         Just for reference, this is what I have done:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
>>>>>>>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>
>>>>>>>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
>>>>>>>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>>
>>>>>>>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
>>>>>>>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>
>>>>>>>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
>>>>>>>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>>>
>>>>>>>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
>>>>>>>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>
>>>>>>>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
>>>>>>>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>>
>>>>>>>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
>>>>>>>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>
>>>>>>>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
>>>>>>>>>>>>>> <https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>         Thanks
>>>>>>>>>>>>>>         Rafael
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>         Em seg, 29 de mar de 2021 20:24, Ethin Probst
>>>>>>>>>>>>>>         <harlydavidsen@gmail.com
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>>
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>>>
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>>
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com
>>>>>>>>>>>>>> <mailto:harlydavidsen@gmail.com>>>>>
>>>>>>>>>>>>>>         escreveu:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>             Hello everyone,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>             This is the first time I've ever contributed to
>>>>>>>>>>>>>> EDK2.
>>>>>>>>>>>>>> As
>>>>>>>>>>>>>>             part of GSoC
>>>>>>>>>>>>>>             2021, I have submitted a proposal to implement a
>>>>>>>>>>>>>> UEFI
>>>>>>>>>>>>>>             audio output
>>>>>>>>>>>>>>             protocol that will utilize the VirtIO sound
>>>>>>>>>>>>>> driver.
>>>>>>>>>>>>>> I've
>>>>>>>>>>>>>>             already
>>>>>>>>>>>>>>             submitted a draft proposal, and apologize if I've
>>>>>>>>>>>>>> done
>>>>>>>>>>>>>>             things out of
>>>>>>>>>>>>>>             order. This is my first time doing GSoC 2021, and
>>>>>>>>>>>>>>             contributing to EDK2
>>>>>>>>>>>>>>             felt like a really fun thing to do!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>             I look forward to working with you guys on this
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>> any
>>>>>>>>>>>>>>             future projects!
>>>>>>>>>>>>>>             :-)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>             --
>>>>>>>>>>>>>>             Signed,
>>>>>>>>>>>>>>             Ethin D. Probst
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     --
>>>>>>>>>>>>>>     Signed,
>>>>>>>>>>>>>>     Ethin D. Probst
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Signed,
>>>>>>>>>>>>>> Ethin D. Probst
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Signed,
>>>>>>>>>>>> Ethin D. Probst
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Signed,
>>>>>>>>>> Ethin D. Probst
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Signed,
>>>>>>>> Ethin D. Probst
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Signed,
>>>>>>> Ethin D. Probst
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Signed,
>>>>> Ethin D. Probst
>>>>>
>>>>>
>>>>> 
>>>
>>>
>>
>>
>> --
>> Signed,
>> Ethin D. Probst
>
>


-- 
Signed,
Ethin D. Probst

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Laszlo Ersek]

On 04/15/21 06:01, Ethin Probst wrote:
> Hi Mike and Andrew,
> 
> Thanks for your responses. I'm looking at the VirtIO block device now
> but will certainly have a look at the others as well. We'll also need
> to define a completely new protocol for audio, as well, as no existing
> protocol will fit the bill. The generic protocol proposed by Andrew
> might work, though I was thinking of a couple modifications: primarily
> that the audio interface will most likely be asynchronous in nature.

EFI_SIMPLE_NETWORK_PROTOCOL is a good design for a request queueing API.
(One limitation that I could mention here is that it does not permit the
queueing of the exact same buffer (= bus adress) multiple times at the
same time, but that's not a grave limitation in practice.) For audio
output inspiration, you could excise the "admin" type member functions,
just focus on the queueing (also ignore Rx, only focus on Tx).

And then I suggest reading "OvmfPkg/VirtioNetDxe/TechNotes.txt", which
explains how EFI_SIMPLE_NETWORK_PROTOCOL is implemented for virtio-net.
It's the most complex of the virtio drivers in OvmfPkg (regarding virtio
exchanges), exactly because it needs to deal with bidirectional async
transfer. You can ignore the Rx direction and just look at Tx.

VirtioLib contains several utility functions. A subset of those
functions is only useful to the simpler (synchronous) virtio drivers,
such as virtio-blk, virtio-scsi, ..., that implement request-response
patterns. Because virtio-net is asynchronous (it does real queueing,
down from the EFI protocol interface), some of the request-response
helper functions in VirtioLib do not apply.

virtio-net is still used with polling; what's important to know is that
it's not the driver itself that performs the repeated checking. The SNP
protocol specifies three members that relate to polling; in all three
cases, the polling is driven from outside of the driver.

Tx polling is performed via EFI_SIMPLE_NETWORK.GetStatus(), it is called
repeatedly by whatever agent is using SNP.

Rx polling is performed either via EFI_SIMPLE_NETWORK.Receive() (called
repeatedly by whatever agent is using SNP), or via the "WaitForPacket"
event. The latter is still polling, only the loop is iternal the
WaitForEvent() boot service. Anyway, Rx should be OK to ignore for now.

Thanks
Laszlo

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Michael Brown]

On 15/04/2021 06:28, Ethin Probst wrote:
> - I hoped to add recording in case we in future want to add
> accessibility aids like speech recognition (that was one of the todo
> tasks on the EDK2 tasks list)

Is there any necessity for audio input and output to be implemented 
within the same protocol?  Unlike a network device (which is 
intrinsically bidirectional), it seems natural to conceptually separate 
audio input from audio output.

> - Muting and volume control could easily be added by just replacing
> the sample buffer with silence and by multiplying all the samples by a
> percentage.

The code controlling volume/mute may not have any access to the sample 
buffer.  The most natural implementation would seem to allow for a 
platform to notice volume up/down keypresses and use those to control 
the overall system volume, without any knowledge of which samples (if 
any) are currently being played by other code in the system.

> - Finally, the reason I used enumerations for specifying parameters
> like sample rate and stuff was that I was looking at this protocol
> from a general UEFI applications point of view. VirtIO supports all of
> the sample configurations listed in my gist, and it seems reasonable
> to allow the application to control those parameters instead of
> forcing a particular parameter configuration onto the developer.

Consider also the point of view of the developer implementing a driver 
for some other piece of audio hardware that happens not to support 
precisely the same sample rates etc as VirtIO.  It would be extremely 
ugly to force all future hardware to pretend to have the same 
capabilities as VirtIO just because the API was initially designed with 
VirtIO in mind.

As a developer on the other side of the API, writing code to play sound 
files on an arbitrary unknown platform, I would prefer to simply consume 
as simple as possible an abstraction of an audio output protocol and not 
have to care about what hardware is actually implementing it.

Both of these argue in favour of defining a very simple API that 
expresses only a common baseline capability that is plausibly 
implementable for every piece of audio hardware ever made.

Coupled with the relatively minimalistic requirements for boot-time 
audio, I'd probably suggest supporting only a single format for audio 
data, with a fixed sample rate (and possibly only mono output).

As always: perfection is achieved, not when there is nothing more to 
add, but when there is nothing left to take away.  :)

Thanks,

Michael

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Andrew Fish]

> On Apr 15, 2021, at 2:51 AM, Laszlo Ersek <lersek@redhat.com> wrote:
> 
> On 04/15/21 06:01, Ethin Probst wrote:
>> Hi Mike and Andrew,
>> 
>> Thanks for your responses. I'm looking at the VirtIO block device now
>> but will certainly have a look at the others as well. We'll also need
>> to define a completely new protocol for audio, as well, as no existing
>> protocol will fit the bill. The generic protocol proposed by Andrew
>> might work, though I was thinking of a couple modifications: primarily
>> that the audio interface will most likely be asynchronous in nature.
> 
> EFI_SIMPLE_NETWORK_PROTOCOL is a good design for a request queueing API.
> (One limitation that I could mention here is that it does not permit the
> queueing of the exact same buffer (= bus adress) multiple times at the
> same time, but that's not a grave limitation in practice.) For audio
> output inspiration, you could excise the "admin" type member functions,
> just focus on the queueing (also ignore Rx, only focus on Tx).
> 
> And then I suggest reading "OvmfPkg/VirtioNetDxe/TechNotes.txt", which
> explains how EFI_SIMPLE_NETWORK_PROTOCOL is implemented for virtio-net.
> It's the most complex of the virtio drivers in OvmfPkg (regarding virtio
> exchanges), exactly because it needs to deal with bidirectional async
> transfer. You can ignore the Rx direction and just look at Tx.
> 
> VirtioLib contains several utility functions. A subset of those
> functions is only useful to the simpler (synchronous) virtio drivers,
> such as virtio-blk, virtio-scsi, ..., that implement request-response
> patterns. Because virtio-net is asynchronous (it does real queueing,
> down from the EFI protocol interface), some of the request-response
> helper functions in VirtioLib do not apply.
> 
> virtio-net is still used with polling; what's important to know is that
> it's not the driver itself that performs the repeated checking. The SNP
> protocol specifies three members that relate to polling; in all three
> cases, the polling is driven from outside of the driver.
> 
> Tx polling is performed via EFI_SIMPLE_NETWORK.GetStatus(), it is called
> repeatedly by whatever agent is using SNP.
> 
> Rx polling is performed either via EFI_SIMPLE_NETWORK.Receive() (called
> repeatedly by whatever agent is using SNP), or via the "WaitForPacket"
> event. The latter is still polling, only the loop is iternal the
> WaitForEvent() boot service. Anyway, Rx should be OK to ignore for now.
> 

Laszlo,

In the audio case I think the driver can do its own polling so we don’t need to copy the networking stack from that point of view, but as you point out it is a good example of the VirtIo magic. 

Also thanks for the more detailed pointers. 

Thanks,

Andrew Fish

> Thanks
> Laszlo
> 
> 
> 
> 
> 
> 

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Andrew Fish]

> On Apr 15, 2021, at 5:07 AM, Michael Brown <mcb30@ipxe.org> wrote:
> 
> On 15/04/2021 06:28, Ethin Probst wrote:
>> - I hoped to add recording in case we in future want to add
>> accessibility aids like speech recognition (that was one of the todo
>> tasks on the EDK2 tasks list)
> 
> Is there any necessity for audio input and output to be implemented within the same protocol?  Unlike a network device (which is intrinsically bidirectional), it seems natural to conceptually separate audio input from audio output.
> 
>> - Muting and volume control could easily be added by just replacing
>> the sample buffer with silence and by multiplying all the samples by a
>> percentage.
> 
> The code controlling volume/mute may not have any access to the sample buffer.  The most natural implementation would seem to allow for a platform to notice volume up/down keypresses and use those to control the overall system volume, without any knowledge of which samples (if any) are currently being played by other code in the system.
> 

I’ve also thought of adding NVRAM variable that would let setup, UEFI Shell, or even the OS set the current volume, and Mute. This how it would be consumed concept is why I proposed mute and volume being separate APIs. The volume up/down API in addition to fixed percentage might be overkill, but it does allow a non liner mapping to the volume up/down keys. You would be surprised how picky audiophiles can be and it seems they like to file Bugzillas. 

>> - Finally, the reason I used enumerations for specifying parameters
>> like sample rate and stuff was that I was looking at this protocol
>> from a general UEFI applications point of view. VirtIO supports all of
>> the sample configurations listed in my gist, and it seems reasonable
>> to allow the application to control those parameters instead of
>> forcing a particular parameter configuration onto the developer.
> 
> Consider also the point of view of the developer implementing a driver for some other piece of audio hardware that happens not to support precisely the same sample rates etc as VirtIO.  It would be extremely ugly to force all future hardware to pretend to have the same capabilities as VirtIO just because the API was initially designed with VirtIO in mind.
> 
> As a developer on the other side of the API, writing code to play sound files on an arbitrary unknown platform, I would prefer to simply consume as simple as possible an abstraction of an audio output protocol and not have to care about what hardware is actually implementing it.
> 

It may make sense to have an API to load the buffer/stream and other APIs to play or pause. This could allow an optional API to configure how the stream is played back. If we add a version to the Protocol that would at least future proof us. 

We did get feedback that it is very common to speed up the auto playback rates for accessibility. I’m not sure if that is practical with a simple PCM 16 wave file with the firmware audio implementation. I guess that is something we could investigate. 

In terms of maybe adding text to speech there is an open source project that conceptually we could port to EFI. It would likely be a binary that would have to live on the EFI System Partition due to size. I was thinking that words per minute could be part of that API and it would produce a PCM 16 wave file that the audio protocol we are discussing could play. 

> Both of these argue in favour of defining a very simple API that expresses only a common baseline capability that is plausibly implementable for every piece of audio hardware ever made.
> 
> Coupled with the relatively minimalistic requirements for boot-time audio, I'd probably suggest supporting only a single format for audio data, with a fixed sample rate (and possibly only mono output).
> 

In my world the folks that work for Jony asked for a stereo boot bong to transition from left to right :). This is not the CODEC you are looking for was our response…. I also did not mention that some languages are right to left, as the only thing worse than one complex thing is two complex things to implement.

> As always: perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.  :)
> 

"Simplicity is the ultimate sophistication”

Thanks,

Andrew Fish 

> Thanks,
> 
> Michael
> 
> 
> 
> 
> 

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Ethin Probst]

> Is there any necessity for audio input and output to be implemented within the same protocol?  Unlike a network device (which is intrinsically bidirectional), it seems natural to conceptually separate audio input from audio output.

Nope, there isn't a necessity to make them in one, they can be
separated into two.

> The code controlling volume/mute may not have any access to the sample buffer.  The most natural implementation would seem to allow for a platform to notice volume up/down keypresses and use those to control the overall system volume, without any knowledge of which samples (if any) are currently being played by other code in the system.

Your assuming that the audio device your implementing the
volume/muting has volume control and muting functionality within
itself, then. This may not be the case, and so we'd need to
effectively simulate it within the driver, which isn't too hard to do.
As an example, the VirtIO driver does not have a request type for
muting or for volume control (this would, most likely, be within the
VIRTIO_SND_R_PCM_SET_PARAMS request, see sec. 5.14.6.4.3). Therefore,
either the driver would have to simulate the request or return
EFI_UNSUPPORTED this instance.

> Consider also the point of view of the developer implementing a driver for some other piece of audio hardware that happens not to support precisely the same sample rates etc as VirtIO.  It would be extremely ugly to force all future hardware to pretend to have the same capabilities as VirtIO just because the API was initially designed with VirtIO in mind.

Precisely, but the brilliance of VirtIO is that the sample rate,
sample format, &c., do not have to all be supported by a VirtIO
device. Notice, also, how in my protocol proposal I noted that the
sample rates, at least, were "recommended," not "required." Should a
device not happen to support a sample rate or sample format, all it
needs to do is return EFI_INVALID_PARAMETER. Section 5.14.6.2.1
(VIRTIO_SND_R_JACK_GET_CONFIG) describes how a jack tells you what
sample rates it supports, channel mappings, &c.

I do understand how just using a predefined sample rate and sample
format might be a good idea, and if that's the best way, then that's
what we'll do. The protocol can always be revised at a later time if
necessary. I apologize if my stance seems obstinate.

Also, thank you, Laszlo, for your advice -- I hadn't considered that a
network driver would be another good way of figuring out how async
works in UEFI.

On 4/15/21, Andrew Fish <afish@apple.com> wrote:
>
>
>> On Apr 15, 2021, at 5:07 AM, Michael Brown <mcb30@ipxe.org> wrote:
>>
>> On 15/04/2021 06:28, Ethin Probst wrote:
>>> - I hoped to add recording in case we in future want to add
>>> accessibility aids like speech recognition (that was one of the todo
>>> tasks on the EDK2 tasks list)
>>
>> Is there any necessity for audio input and output to be implemented within
>> the same protocol?  Unlike a network device (which is intrinsically
>> bidirectional), it seems natural to conceptually separate audio input from
>> audio output.
>>
>>> - Muting and volume control could easily be added by just replacing
>>> the sample buffer with silence and by multiplying all the samples by a
>>> percentage.
>>
>> The code controlling volume/mute may not have any access to the sample
>> buffer.  The most natural implementation would seem to allow for a
>> platform to notice volume up/down keypresses and use those to control the
>> overall system volume, without any knowledge of which samples (if any) are
>> currently being played by other code in the system.
>>
>
> I’ve also thought of adding NVRAM variable that would let setup, UEFI Shell,
> or even the OS set the current volume, and Mute. This how it would be
> consumed concept is why I proposed mute and volume being separate APIs. The
> volume up/down API in addition to fixed percentage might be overkill, but it
> does allow a non liner mapping to the volume up/down keys. You would be
> surprised how picky audiophiles can be and it seems they like to file
> Bugzillas.
>
>>> - Finally, the reason I used enumerations for specifying parameters
>>> like sample rate and stuff was that I was looking at this protocol
>>> from a general UEFI applications point of view. VirtIO supports all of
>>> the sample configurations listed in my gist, and it seems reasonable
>>> to allow the application to control those parameters instead of
>>> forcing a particular parameter configuration onto the developer.
>>
>> Consider also the point of view of the developer implementing a driver for
>> some other piece of audio hardware that happens not to support precisely
>> the same sample rates etc as VirtIO.  It would be extremely ugly to force
>> all future hardware to pretend to have the same capabilities as VirtIO
>> just because the API was initially designed with VirtIO in mind.
>>
>> As a developer on the other side of the API, writing code to play sound
>> files on an arbitrary unknown platform, I would prefer to simply consume
>> as simple as possible an abstraction of an audio output protocol and not
>> have to care about what hardware is actually implementing it.
>>
>
> It may make sense to have an API to load the buffer/stream and other APIs to
> play or pause. This could allow an optional API to configure how the stream
> is played back. If we add a version to the Protocol that would at least
> future proof us.
>
> We did get feedback that it is very common to speed up the auto playback
> rates for accessibility. I’m not sure if that is practical with a simple PCM
> 16 wave file with the firmware audio implementation. I guess that is
> something we could investigate.
>
> In terms of maybe adding text to speech there is an open source project that
> conceptually we could port to EFI. It would likely be a binary that would
> have to live on the EFI System Partition due to size. I was thinking that
> words per minute could be part of that API and it would produce a PCM 16
> wave file that the audio protocol we are discussing could play.
>
>> Both of these argue in favour of defining a very simple API that expresses
>> only a common baseline capability that is plausibly implementable for
>> every piece of audio hardware ever made.
>>
>> Coupled with the relatively minimalistic requirements for boot-time audio,
>> I'd probably suggest supporting only a single format for audio data, with
>> a fixed sample rate (and possibly only mono output).
>>
>
> In my world the folks that work for Jony asked for a stereo boot bong to
> transition from left to right :). This is not the CODEC you are looking for
> was our response…. I also did not mention that some languages are right to
> left, as the only thing worse than one complex thing is two complex things
> to implement.
>
>> As always: perfection is achieved, not when there is nothing more to add,
>> but when there is nothing left to take away.  :)
>>
>
> "Simplicity is the ultimate sophistication”
>
> Thanks,
>
> Andrew Fish
>
>> Thanks,
>>
>> Michael
>>
>>
>> 
>>
>>
>
>


-- 
Signed,
Ethin D. Probst

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Andrew Fish]

> On Apr 15, 2021, at 1:11 PM, Ethin Probst <harlydavidsen@gmail.com> wrote:
> 
>> Is there any necessity for audio input and output to be implemented within the same protocol?  Unlike a network device (which is intrinsically bidirectional), it seems natural to conceptually separate audio input from audio output.
> 
> Nope, there isn't a necessity to make them in one, they can be
> separated into two.
> 
>> The code controlling volume/mute may not have any access to the sample buffer.  The most natural implementation would seem to allow for a platform to notice volume up/down keypresses and use those to control the overall system volume, without any knowledge of which samples (if any) are currently being played by other code in the system.
> 
> Your assuming that the audio device your implementing the
> volume/muting has volume control and muting functionality within
> itself, then.

Not really. We are assuming that audio hardware has a better understanding of how that system implements volume than some generic EFI Code that is by definition platform agnostic. 

> This may not be the case, and so we'd need to
> effectively simulate it within the driver, which isn't too hard to do.
> As an example, the VirtIO driver does not have a request type for
> muting or for volume control (this would, most likely, be within the
> VIRTIO_SND_R_PCM_SET_PARAMS request, see sec. 5.14.6.4.3). Therefore,
> either the driver would have to simulate the request or return
> EFI_UNSUPPORTED this instance.
> 

So this is an example of above since the audio hardware knows it is routing the sound output into another subsystem, and that subsystem controls the volume. So the VirtIo Sound Driver know best how to bstract volume/mute for this platform.

>> Consider also the point of view of the developer implementing a driver for some other piece of audio hardware that happens not to support precisely the same sample rates etc as VirtIO.  It would be extremely ugly to force all future hardware to pretend to have the same capabilities as VirtIO just because the API was initially designed with VirtIO in mind.
> 
> Precisely, but the brilliance of VirtIO

The brilliance of VirtIO is that it just needs to implement a generic device driver for a given operating system. In most cases these operating systems have sounds subsystems that manage sound and want fine granularity of control on what is going on. So the drivers are implemented to maximizes flexibility since the OS has lots of generic code that deals with sound, and even user configurable knobs to control audio. In our case that extra layer does not exist in EFI and the end user code just want to tell the driver do some simple things.

Maybe it is easier to think about with an example. Lets say I want to play a cool sound on every boot. What would be the workflow to make the happen. 
1) Encode the sound using a standard tool into a Wave PCM 16.
2) Place the Wave file in the Firmware Volume using a given UUID as the name. As simple as editing the platform FDF file. 
3) Write some BDS code
  a) Lookup Wave file by UUID and read it into memory. 
  b) Point the EFI Sound Protocol at the buffer with the Wave file
  c) Tell the EFI Sound Protocol to play the sound. 

If you start adding in a lot of perimeters that work flow starts getting really complicated really quickly. 

> is that the sample rate,
> sample format, &c., do not have to all be supported by a VirtIO
> device. Notice, also, how in my protocol proposal I noted that the
> sample rates, at least, were "recommended," not "required." Should a
> device not happen to support a sample rate or sample format, all it
> needs to do is return EFI_INVALID_PARAMETER. Section 5.14.6.2.1
> (VIRTIO_SND_R_JACK_GET_CONFIG) describes how a jack tells you what
> sample rates it supports, channel mappings, &c.
> 
> I do understand how just using a predefined sample rate and sample
> format might be a good idea, and if that's the best way, then that's
> what we'll do. The protocol can always be revised at a later time if
> necessary. I apologize if my stance seems obstinate.
> 

I think if we add the version into the protocol and make sure we have a separate load and play operation we could add a member to set the extra perimeters if needed. There might also be some platform specific generic tunables that might be interesting for a future member function. 

Thanks,

Andrew Fish

> Also, thank you, Laszlo, for your advice -- I hadn't considered that a
> network driver would be another good way of figuring out how async
> works in UEFI.
> 
> On 4/15/21, Andrew Fish <afish@apple.com> wrote:
>> 
>> 
>>> On Apr 15, 2021, at 5:07 AM, Michael Brown <mcb30@ipxe.org> wrote:
>>> 
>>> On 15/04/2021 06:28, Ethin Probst wrote:
>>>> - I hoped to add recording in case we in future want to add
>>>> accessibility aids like speech recognition (that was one of the todo
>>>> tasks on the EDK2 tasks list)
>>> 
>>> Is there any necessity for audio input and output to be implemented within
>>> the same protocol?  Unlike a network device (which is intrinsically
>>> bidirectional), it seems natural to conceptually separate audio input from
>>> audio output.
>>> 
>>>> - Muting and volume control could easily be added by just replacing
>>>> the sample buffer with silence and by multiplying all the samples by a
>>>> percentage.
>>> 
>>> The code controlling volume/mute may not have any access to the sample
>>> buffer.  The most natural implementation would seem to allow for a
>>> platform to notice volume up/down keypresses and use those to control the
>>> overall system volume, without any knowledge of which samples (if any) are
>>> currently being played by other code in the system.
>>> 
>> 
>> I’ve also thought of adding NVRAM variable that would let setup, UEFI Shell,
>> or even the OS set the current volume, and Mute. This how it would be
>> consumed concept is why I proposed mute and volume being separate APIs. The
>> volume up/down API in addition to fixed percentage might be overkill, but it
>> does allow a non liner mapping to the volume up/down keys. You would be
>> surprised how picky audiophiles can be and it seems they like to file
>> Bugzillas.
>> 
>>>> - Finally, the reason I used enumerations for specifying parameters
>>>> like sample rate and stuff was that I was looking at this protocol
>>>> from a general UEFI applications point of view. VirtIO supports all of
>>>> the sample configurations listed in my gist, and it seems reasonable
>>>> to allow the application to control those parameters instead of
>>>> forcing a particular parameter configuration onto the developer.
>>> 
>>> Consider also the point of view of the developer implementing a driver for
>>> some other piece of audio hardware that happens not to support precisely
>>> the same sample rates etc as VirtIO.  It would be extremely ugly to force
>>> all future hardware to pretend to have the same capabilities as VirtIO
>>> just because the API was initially designed with VirtIO in mind.
>>> 
>>> As a developer on the other side of the API, writing code to play sound
>>> files on an arbitrary unknown platform, I would prefer to simply consume
>>> as simple as possible an abstraction of an audio output protocol and not
>>> have to care about what hardware is actually implementing it.
>>> 
>> 
>> It may make sense to have an API to load the buffer/stream and other APIs to
>> play or pause. This could allow an optional API to configure how the stream
>> is played back. If we add a version to the Protocol that would at least
>> future proof us.
>> 
>> We did get feedback that it is very common to speed up the auto playback
>> rates for accessibility. I’m not sure if that is practical with a simple PCM
>> 16 wave file with the firmware audio implementation. I guess that is
>> something we could investigate.
>> 
>> In terms of maybe adding text to speech there is an open source project that
>> conceptually we could port to EFI. It would likely be a binary that would
>> have to live on the EFI System Partition due to size. I was thinking that
>> words per minute could be part of that API and it would produce a PCM 16
>> wave file that the audio protocol we are discussing could play.
>> 
>>> Both of these argue in favour of defining a very simple API that expresses
>>> only a common baseline capability that is plausibly implementable for
>>> every piece of audio hardware ever made.
>>> 
>>> Coupled with the relatively minimalistic requirements for boot-time audio,
>>> I'd probably suggest supporting only a single format for audio data, with
>>> a fixed sample rate (and possibly only mono output).
>>> 
>> 
>> In my world the folks that work for Jony asked for a stereo boot bong to
>> transition from left to right :). This is not the CODEC you are looking for
>> was our response…. I also did not mention that some languages are right to
>> left, as the only thing worse than one complex thing is two complex things
>> to implement.
>> 
>>> As always: perfection is achieved, not when there is nothing more to add,
>>> but when there is nothing left to take away.  :)
>>> 
>> 
>> "Simplicity is the ultimate sophistication”
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
>>> Thanks,
>>> 
>>> Michael
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 
> 
> -- 
> Signed,
> Ethin D. Probst

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Ethin Probst]

Hi Andrew,

What would that protocol interface look like if we utilized your idea?
With mine (though I need to add channel mapping as well), your
workflow for playing a stereo sound from left to right would probably
be something like this:
1) Encode the sound using a standard tool into a Wave PCM 16.
2) Place the Wave file in the Firmware Volume using a given UUID as
the name. As simple as editing the platform FDF file.
3) Write some BDS code
  a) Lookup Wave file by UUID and read it into memory.
  b) Decode the audio file (audio devices will not do this decoding
for you, you have to do that yourself).
  c) Call EFI_AUDIO_PROTOCOL.LoadBuffer(), passing in the sample rate
of your audio, EFI_AUDIO_PROTOCOL_SAMPLE_FORMAT_S16 for signed 16-bit
PCM audio, the channel mapping, the number of samples, and the samples
themselves.
  d) call EFI_BOOT_SERVICES.CreateEvent()/EFI_BOOT_SERVICES.CreateEventEx()
for a playback event to signal.
  e) call EFI_AUDIO_PROTOCOL.StartPlayback(), passing in the event you
just created.
The reason that LoadBuffer() takes so many parameters is because the
device does not know the audio that your passing in. If I'm given an
array of 16-bit audio samples, its impossible to know the parameters
(sample rate, sample format, channel mapping, etc.) from that alone.
Using your idea, though, my protocol could be greatly simplified.
Forcing a particular channel mapping, sample rate and sample format on
everyone would complicate application code. From an application point
of view, one would, with that type of protocol, need to do the
following:
1) Load an audio file in any audio file format from any storage mechanism.
2) Decode the audio file format to extract the samples and audio metadata.
3) Resample the (now decoded) audio samples and convert (quantize) the
audio samples into signed 16-bit PCM audio.
4) forward the samples onto the EFI audio protocol.
There is another option. (I'm happy we're discussing this now -- we
can hammer out all the details now which will make a lot of things
easier.) Since I'll most likely end up splitting the device-specific
interfaces to different audio protocols, we could make a simple audio
protocol that makes various assumptions about the audio samples your
giving it (e.g.: sample rate, format, ...). This would just allow
audio output and input in signed 16-bit PCM audio, as you've
suggested, and would be a simple and easy to use interface. Something
like:
typedef struct EFI_SIMPLE_AUDIO_PROTOCOL {
  EFI_SIMPLE_AUDIO_PROTOCOL_RESET Reset;
  EFI_SIMPLE_AUDIO_PROTOCOL_START Start;
  EFI_SIMPLE_AUDIO_PROTOCOL_STOP Stop;
} EFI_SIMPLE_AUDIO_PROTOCOL;
This way, users and driver developers have a simple audio protocol
they can implement if they like. It would assume signed 16-bit PCM
audio and mono channel mappings at 44100 Hz. Then, we can have an
advanced protocol for each device type (HDA, USB, VirtIO, ...) that
exposes all the knobs for sample formats, sample rates, that kind of
thing. Obviously, like the majority (if not all) UEFI protocols, these
advanced protocols would be optional. I think, however, that the
simple audio protocol should be a required protocol in all UEFI
implementations. But that might not be possible. So would this simpler
interface work as a starting point?

On 4/15/21, Andrew Fish <afish@apple.com> wrote:
>
>
>> On Apr 15, 2021, at 1:11 PM, Ethin Probst <harlydavidsen@gmail.com>
>> wrote:
>>
>>> Is there any necessity for audio input and output to be implemented
>>> within the same protocol?  Unlike a network device (which is
>>> intrinsically bidirectional), it seems natural to conceptually separate
>>> audio input from audio output.
>>
>> Nope, there isn't a necessity to make them in one, they can be
>> separated into two.
>>
>>> The code controlling volume/mute may not have any access to the sample
>>> buffer.  The most natural implementation would seem to allow for a
>>> platform to notice volume up/down keypresses and use those to control the
>>> overall system volume, without any knowledge of which samples (if any)
>>> are currently being played by other code in the system.
>>
>> Your assuming that the audio device your implementing the
>> volume/muting has volume control and muting functionality within
>> itself, then.
>
> Not really. We are assuming that audio hardware has a better understanding
> of how that system implements volume than some generic EFI Code that is by
> definition platform agnostic.
>
>> This may not be the case, and so we'd need to
>> effectively simulate it within the driver, which isn't too hard to do.
>> As an example, the VirtIO driver does not have a request type for
>> muting or for volume control (this would, most likely, be within the
>> VIRTIO_SND_R_PCM_SET_PARAMS request, see sec. 5.14.6.4.3). Therefore,
>> either the driver would have to simulate the request or return
>> EFI_UNSUPPORTED this instance.
>>
>
> So this is an example of above since the audio hardware knows it is routing
> the sound output into another subsystem, and that subsystem controls the
> volume. So the VirtIo Sound Driver know best how to bstract volume/mute for
> this platform.
>
>>> Consider also the point of view of the developer implementing a driver
>>> for some other piece of audio hardware that happens not to support
>>> precisely the same sample rates etc as VirtIO.  It would be extremely
>>> ugly to force all future hardware to pretend to have the same
>>> capabilities as VirtIO just because the API was initially designed with
>>> VirtIO in mind.
>>
>> Precisely, but the brilliance of VirtIO
>
> The brilliance of VirtIO is that it just needs to implement a generic device
> driver for a given operating system. In most cases these operating systems
> have sounds subsystems that manage sound and want fine granularity of
> control on what is going on. So the drivers are implemented to maximizes
> flexibility since the OS has lots of generic code that deals with sound, and
> even user configurable knobs to control audio. In our case that extra layer
> does not exist in EFI and the end user code just want to tell the driver do
> some simple things.
>
> Maybe it is easier to think about with an example. Lets say I want to play a
> cool sound on every boot. What would be the workflow to make the happen.
> 1) Encode the sound using a standard tool into a Wave PCM 16.
> 2) Place the Wave file in the Firmware Volume using a given UUID as the
> name. As simple as editing the platform FDF file.
> 3) Write some BDS code
>   a) Lookup Wave file by UUID and read it into memory.
>   b) Point the EFI Sound Protocol at the buffer with the Wave file
>   c) Tell the EFI Sound Protocol to play the sound.
>
> If you start adding in a lot of perimeters that work flow starts getting
> really complicated really quickly.
>
>> is that the sample rate,
>> sample format, &c., do not have to all be supported by a VirtIO
>> device. Notice, also, how in my protocol proposal I noted that the
>> sample rates, at least, were "recommended," not "required." Should a
>> device not happen to support a sample rate or sample format, all it
>> needs to do is return EFI_INVALID_PARAMETER. Section 5.14.6.2.1
>> (VIRTIO_SND_R_JACK_GET_CONFIG) describes how a jack tells you what
>> sample rates it supports, channel mappings, &c.
>>
>> I do understand how just using a predefined sample rate and sample
>> format might be a good idea, and if that's the best way, then that's
>> what we'll do. The protocol can always be revised at a later time if
>> necessary. I apologize if my stance seems obstinate.
>>
>
> I think if we add the version into the protocol and make sure we have a
> separate load and play operation we could add a member to set the extra
> perimeters if needed. There might also be some platform specific generic
> tunables that might be interesting for a future member function.
>
> Thanks,
>
> Andrew Fish
>
>> Also, thank you, Laszlo, for your advice -- I hadn't considered that a
>> network driver would be another good way of figuring out how async
>> works in UEFI.
>>
>> On 4/15/21, Andrew Fish <afish@apple.com> wrote:
>>>
>>>
>>>> On Apr 15, 2021, at 5:07 AM, Michael Brown <mcb30@ipxe.org> wrote:
>>>>
>>>> On 15/04/2021 06:28, Ethin Probst wrote:
>>>>> - I hoped to add recording in case we in future want to add
>>>>> accessibility aids like speech recognition (that was one of the todo
>>>>> tasks on the EDK2 tasks list)
>>>>
>>>> Is there any necessity for audio input and output to be implemented
>>>> within
>>>> the same protocol?  Unlike a network device (which is intrinsically
>>>> bidirectional), it seems natural to conceptually separate audio input
>>>> from
>>>> audio output.
>>>>
>>>>> - Muting and volume control could easily be added by just replacing
>>>>> the sample buffer with silence and by multiplying all the samples by a
>>>>> percentage.
>>>>
>>>> The code controlling volume/mute may not have any access to the sample
>>>> buffer.  The most natural implementation would seem to allow for a
>>>> platform to notice volume up/down keypresses and use those to control
>>>> the
>>>> overall system volume, without any knowledge of which samples (if any)
>>>> are
>>>> currently being played by other code in the system.
>>>>
>>>
>>> I’ve also thought of adding NVRAM variable that would let setup, UEFI
>>> Shell,
>>> or even the OS set the current volume, and Mute. This how it would be
>>> consumed concept is why I proposed mute and volume being separate APIs.
>>> The
>>> volume up/down API in addition to fixed percentage might be overkill, but
>>> it
>>> does allow a non liner mapping to the volume up/down keys. You would be
>>> surprised how picky audiophiles can be and it seems they like to file
>>> Bugzillas.
>>>
>>>>> - Finally, the reason I used enumerations for specifying parameters
>>>>> like sample rate and stuff was that I was looking at this protocol
>>>>> from a general UEFI applications point of view. VirtIO supports all of
>>>>> the sample configurations listed in my gist, and it seems reasonable
>>>>> to allow the application to control those parameters instead of
>>>>> forcing a particular parameter configuration onto the developer.
>>>>
>>>> Consider also the point of view of the developer implementing a driver
>>>> for
>>>> some other piece of audio hardware that happens not to support
>>>> precisely
>>>> the same sample rates etc as VirtIO.  It would be extremely ugly to
>>>> force
>>>> all future hardware to pretend to have the same capabilities as VirtIO
>>>> just because the API was initially designed with VirtIO in mind.
>>>>
>>>> As a developer on the other side of the API, writing code to play sound
>>>> files on an arbitrary unknown platform, I would prefer to simply
>>>> consume
>>>> as simple as possible an abstraction of an audio output protocol and
>>>> not
>>>> have to care about what hardware is actually implementing it.
>>>>
>>>
>>> It may make sense to have an API to load the buffer/stream and other APIs
>>> to
>>> play or pause. This could allow an optional API to configure how the
>>> stream
>>> is played back. If we add a version to the Protocol that would at least
>>> future proof us.
>>>
>>> We did get feedback that it is very common to speed up the auto playback
>>> rates for accessibility. I’m not sure if that is practical with a simple
>>> PCM
>>> 16 wave file with the firmware audio implementation. I guess that is
>>> something we could investigate.
>>>
>>> In terms of maybe adding text to speech there is an open source project
>>> that
>>> conceptually we could port to EFI. It would likely be a binary that
>>> would
>>> have to live on the EFI System Partition due to size. I was thinking
>>> that
>>> words per minute could be part of that API and it would produce a PCM 16
>>> wave file that the audio protocol we are discussing could play.
>>>
>>>> Both of these argue in favour of defining a very simple API that
>>>> expresses
>>>> only a common baseline capability that is plausibly implementable for
>>>> every piece of audio hardware ever made.
>>>>
>>>> Coupled with the relatively minimalistic requirements for boot-time
>>>> audio,
>>>> I'd probably suggest supporting only a single format for audio data,
>>>> with
>>>> a fixed sample rate (and possibly only mono output).
>>>>
>>>
>>> In my world the folks that work for Jony asked for a stereo boot bong to
>>> transition from left to right :). This is not the CODEC you are looking
>>> for
>>> was our response…. I also did not mention that some languages are right
>>> to
>>> left, as the only thing worse than one complex thing is two complex
>>> things
>>> to implement.
>>>
>>>> As always: perfection is achieved, not when there is nothing more to
>>>> add,
>>>> but when there is nothing left to take away.  :)
>>>>
>>>
>>> "Simplicity is the ultimate sophistication”
>>>
>>> Thanks,
>>>
>>> Andrew Fish
>>>
>>>> Thanks,
>>>>
>>>> Michael
>>>>
>>>>
>>>> 
>>>>
>>>>
>>>
>>>
>>
>>
>> --
>> Signed,
>> Ethin D. Probst
>
>


-- 
Signed,
Ethin D. Probst

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Ethin Probst]

Also, I'm a bit confused. I've looked at several VirtIO devices now
and have seen things like this:
#define VIRTIO_PCI_DEVICE_SIGNATURE   SIGNATURE_32 ('V', 'P', 'C', 'I')
// ...
  UINT32                 Signature;
I'm quite confused because I can't seem to find this anywhere in the
VirtIO specification. The spec says nothing about signature values
anywhere, just the magic value of 0x74726976. So where does this come
from?

On 4/15/21, Ethin Probst via groups.io
<harlydavidsen=gmail.com@groups.io> wrote:
> Hi Andrew,
>
> What would that protocol interface look like if we utilized your idea?
> With mine (though I need to add channel mapping as well), your
> workflow for playing a stereo sound from left to right would probably
> be something like this:
> 1) Encode the sound using a standard tool into a Wave PCM 16.
> 2) Place the Wave file in the Firmware Volume using a given UUID as
> the name. As simple as editing the platform FDF file.
> 3) Write some BDS code
>   a) Lookup Wave file by UUID and read it into memory.
>   b) Decode the audio file (audio devices will not do this decoding
> for you, you have to do that yourself).
>   c) Call EFI_AUDIO_PROTOCOL.LoadBuffer(), passing in the sample rate
> of your audio, EFI_AUDIO_PROTOCOL_SAMPLE_FORMAT_S16 for signed 16-bit
> PCM audio, the channel mapping, the number of samples, and the samples
> themselves.
>   d) call EFI_BOOT_SERVICES.CreateEvent()/EFI_BOOT_SERVICES.CreateEventEx()
> for a playback event to signal.
>   e) call EFI_AUDIO_PROTOCOL.StartPlayback(), passing in the event you
> just created.
> The reason that LoadBuffer() takes so many parameters is because the
> device does not know the audio that your passing in. If I'm given an
> array of 16-bit audio samples, its impossible to know the parameters
> (sample rate, sample format, channel mapping, etc.) from that alone.
> Using your idea, though, my protocol could be greatly simplified.
> Forcing a particular channel mapping, sample rate and sample format on
> everyone would complicate application code. From an application point
> of view, one would, with that type of protocol, need to do the
> following:
> 1) Load an audio file in any audio file format from any storage mechanism.
> 2) Decode the audio file format to extract the samples and audio metadata.
> 3) Resample the (now decoded) audio samples and convert (quantize) the
> audio samples into signed 16-bit PCM audio.
> 4) forward the samples onto the EFI audio protocol.
> There is another option. (I'm happy we're discussing this now -- we
> can hammer out all the details now which will make a lot of things
> easier.) Since I'll most likely end up splitting the device-specific
> interfaces to different audio protocols, we could make a simple audio
> protocol that makes various assumptions about the audio samples your
> giving it (e.g.: sample rate, format, ...). This would just allow
> audio output and input in signed 16-bit PCM audio, as you've
> suggested, and would be a simple and easy to use interface. Something
> like:
> typedef struct EFI_SIMPLE_AUDIO_PROTOCOL {
>   EFI_SIMPLE_AUDIO_PROTOCOL_RESET Reset;
>   EFI_SIMPLE_AUDIO_PROTOCOL_START Start;
>   EFI_SIMPLE_AUDIO_PROTOCOL_STOP Stop;
> } EFI_SIMPLE_AUDIO_PROTOCOL;
> This way, users and driver developers have a simple audio protocol
> they can implement if they like. It would assume signed 16-bit PCM
> audio and mono channel mappings at 44100 Hz. Then, we can have an
> advanced protocol for each device type (HDA, USB, VirtIO, ...) that
> exposes all the knobs for sample formats, sample rates, that kind of
> thing. Obviously, like the majority (if not all) UEFI protocols, these
> advanced protocols would be optional. I think, however, that the
> simple audio protocol should be a required protocol in all UEFI
> implementations. But that might not be possible. So would this simpler
> interface work as a starting point?
>
> On 4/15/21, Andrew Fish <afish@apple.com> wrote:
>>
>>
>>> On Apr 15, 2021, at 1:11 PM, Ethin Probst <harlydavidsen@gmail.com>
>>> wrote:
>>>
>>>> Is there any necessity for audio input and output to be implemented
>>>> within the same protocol?  Unlike a network device (which is
>>>> intrinsically bidirectional), it seems natural to conceptually separate
>>>> audio input from audio output.
>>>
>>> Nope, there isn't a necessity to make them in one, they can be
>>> separated into two.
>>>
>>>> The code controlling volume/mute may not have any access to the sample
>>>> buffer.  The most natural implementation would seem to allow for a
>>>> platform to notice volume up/down keypresses and use those to control
>>>> the
>>>> overall system volume, without any knowledge of which samples (if any)
>>>> are currently being played by other code in the system.
>>>
>>> Your assuming that the audio device your implementing the
>>> volume/muting has volume control and muting functionality within
>>> itself, then.
>>
>> Not really. We are assuming that audio hardware has a better
>> understanding
>> of how that system implements volume than some generic EFI Code that is
>> by
>> definition platform agnostic.
>>
>>> This may not be the case, and so we'd need to
>>> effectively simulate it within the driver, which isn't too hard to do.
>>> As an example, the VirtIO driver does not have a request type for
>>> muting or for volume control (this would, most likely, be within the
>>> VIRTIO_SND_R_PCM_SET_PARAMS request, see sec. 5.14.6.4.3). Therefore,
>>> either the driver would have to simulate the request or return
>>> EFI_UNSUPPORTED this instance.
>>>
>>
>> So this is an example of above since the audio hardware knows it is
>> routing
>> the sound output into another subsystem, and that subsystem controls the
>> volume. So the VirtIo Sound Driver know best how to bstract volume/mute
>> for
>> this platform.
>>
>>>> Consider also the point of view of the developer implementing a driver
>>>> for some other piece of audio hardware that happens not to support
>>>> precisely the same sample rates etc as VirtIO.  It would be extremely
>>>> ugly to force all future hardware to pretend to have the same
>>>> capabilities as VirtIO just because the API was initially designed with
>>>> VirtIO in mind.
>>>
>>> Precisely, but the brilliance of VirtIO
>>
>> The brilliance of VirtIO is that it just needs to implement a generic
>> device
>> driver for a given operating system. In most cases these operating
>> systems
>> have sounds subsystems that manage sound and want fine granularity of
>> control on what is going on. So the drivers are implemented to maximizes
>> flexibility since the OS has lots of generic code that deals with sound,
>> and
>> even user configurable knobs to control audio. In our case that extra
>> layer
>> does not exist in EFI and the end user code just want to tell the driver
>> do
>> some simple things.
>>
>> Maybe it is easier to think about with an example. Lets say I want to play
>> a
>> cool sound on every boot. What would be the workflow to make the happen.
>> 1) Encode the sound using a standard tool into a Wave PCM 16.
>> 2) Place the Wave file in the Firmware Volume using a given UUID as the
>> name. As simple as editing the platform FDF file.
>> 3) Write some BDS code
>>   a) Lookup Wave file by UUID and read it into memory.
>>   b) Point the EFI Sound Protocol at the buffer with the Wave file
>>   c) Tell the EFI Sound Protocol to play the sound.
>>
>> If you start adding in a lot of perimeters that work flow starts getting
>> really complicated really quickly.
>>
>>> is that the sample rate,
>>> sample format, &c., do not have to all be supported by a VirtIO
>>> device. Notice, also, how in my protocol proposal I noted that the
>>> sample rates, at least, were "recommended," not "required." Should a
>>> device not happen to support a sample rate or sample format, all it
>>> needs to do is return EFI_INVALID_PARAMETER. Section 5.14.6.2.1
>>> (VIRTIO_SND_R_JACK_GET_CONFIG) describes how a jack tells you what
>>> sample rates it supports, channel mappings, &c.
>>>
>>> I do understand how just using a predefined sample rate and sample
>>> format might be a good idea, and if that's the best way, then that's
>>> what we'll do. The protocol can always be revised at a later time if
>>> necessary. I apologize if my stance seems obstinate.
>>>
>>
>> I think if we add the version into the protocol and make sure we have a
>> separate load and play operation we could add a member to set the extra
>> perimeters if needed. There might also be some platform specific generic
>> tunables that might be interesting for a future member function.
>>
>> Thanks,
>>
>> Andrew Fish
>>
>>> Also, thank you, Laszlo, for your advice -- I hadn't considered that a
>>> network driver would be another good way of figuring out how async
>>> works in UEFI.
>>>
>>> On 4/15/21, Andrew Fish <afish@apple.com> wrote:
>>>>
>>>>
>>>>> On Apr 15, 2021, at 5:07 AM, Michael Brown <mcb30@ipxe.org> wrote:
>>>>>
>>>>> On 15/04/2021 06:28, Ethin Probst wrote:
>>>>>> - I hoped to add recording in case we in future want to add
>>>>>> accessibility aids like speech recognition (that was one of the todo
>>>>>> tasks on the EDK2 tasks list)
>>>>>
>>>>> Is there any necessity for audio input and output to be implemented
>>>>> within
>>>>> the same protocol?  Unlike a network device (which is intrinsically
>>>>> bidirectional), it seems natural to conceptually separate audio input
>>>>> from
>>>>> audio output.
>>>>>
>>>>>> - Muting and volume control could easily be added by just replacing
>>>>>> the sample buffer with silence and by multiplying all the samples by
>>>>>> a
>>>>>> percentage.
>>>>>
>>>>> The code controlling volume/mute may not have any access to the sample
>>>>> buffer.  The most natural implementation would seem to allow for a
>>>>> platform to notice volume up/down keypresses and use those to control
>>>>> the
>>>>> overall system volume, without any knowledge of which samples (if any)
>>>>> are
>>>>> currently being played by other code in the system.
>>>>>
>>>>
>>>> I’ve also thought of adding NVRAM variable that would let setup, UEFI
>>>> Shell,
>>>> or even the OS set the current volume, and Mute. This how it would be
>>>> consumed concept is why I proposed mute and volume being separate APIs.
>>>> The
>>>> volume up/down API in addition to fixed percentage might be overkill,
>>>> but
>>>> it
>>>> does allow a non liner mapping to the volume up/down keys. You would be
>>>> surprised how picky audiophiles can be and it seems they like to file
>>>> Bugzillas.
>>>>
>>>>>> - Finally, the reason I used enumerations for specifying parameters
>>>>>> like sample rate and stuff was that I was looking at this protocol
>>>>>> from a general UEFI applications point of view. VirtIO supports all
>>>>>> of
>>>>>> the sample configurations listed in my gist, and it seems reasonable
>>>>>> to allow the application to control those parameters instead of
>>>>>> forcing a particular parameter configuration onto the developer.
>>>>>
>>>>> Consider also the point of view of the developer implementing a driver
>>>>> for
>>>>> some other piece of audio hardware that happens not to support
>>>>> precisely
>>>>> the same sample rates etc as VirtIO.  It would be extremely ugly to
>>>>> force
>>>>> all future hardware to pretend to have the same capabilities as VirtIO
>>>>> just because the API was initially designed with VirtIO in mind.
>>>>>
>>>>> As a developer on the other side of the API, writing code to play
>>>>> sound
>>>>> files on an arbitrary unknown platform, I would prefer to simply
>>>>> consume
>>>>> as simple as possible an abstraction of an audio output protocol and
>>>>> not
>>>>> have to care about what hardware is actually implementing it.
>>>>>
>>>>
>>>> It may make sense to have an API to load the buffer/stream and other
>>>> APIs
>>>> to
>>>> play or pause. This could allow an optional API to configure how the
>>>> stream
>>>> is played back. If we add a version to the Protocol that would at least
>>>> future proof us.
>>>>
>>>> We did get feedback that it is very common to speed up the auto
>>>> playback
>>>> rates for accessibility. I’m not sure if that is practical with a
>>>> simple
>>>> PCM
>>>> 16 wave file with the firmware audio implementation. I guess that is
>>>> something we could investigate.
>>>>
>>>> In terms of maybe adding text to speech there is an open source project
>>>> that
>>>> conceptually we could port to EFI. It would likely be a binary that
>>>> would
>>>> have to live on the EFI System Partition due to size. I was thinking
>>>> that
>>>> words per minute could be part of that API and it would produce a PCM
>>>> 16
>>>> wave file that the audio protocol we are discussing could play.
>>>>
>>>>> Both of these argue in favour of defining a very simple API that
>>>>> expresses
>>>>> only a common baseline capability that is plausibly implementable for
>>>>> every piece of audio hardware ever made.
>>>>>
>>>>> Coupled with the relatively minimalistic requirements for boot-time
>>>>> audio,
>>>>> I'd probably suggest supporting only a single format for audio data,
>>>>> with
>>>>> a fixed sample rate (and possibly only mono output).
>>>>>
>>>>
>>>> In my world the folks that work for Jony asked for a stereo boot bong
>>>> to
>>>> transition from left to right :). This is not the CODEC you are looking
>>>> for
>>>> was our response…. I also did not mention that some languages are right
>>>> to
>>>> left, as the only thing worse than one complex thing is two complex
>>>> things
>>>> to implement.
>>>>
>>>>> As always: perfection is achieved, not when there is nothing more to
>>>>> add,
>>>>> but when there is nothing left to take away.  :)
>>>>>
>>>>
>>>> "Simplicity is the ultimate sophistication”
>>>>
>>>> Thanks,
>>>>
>>>> Andrew Fish
>>>>
>>>>> Thanks,
>>>>>
>>>>> Michael
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Signed,
>>> Ethin D. Probst
>>
>>
>
>
> --
> Signed,
> Ethin D. Probst
>
>
> 
>
>
>


-- 
Signed,
Ethin D. Probst

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Michael Brown]

On 16/04/2021 00:42, Ethin Probst wrote:
> Forcing a particular channel mapping, sample rate and sample format on
> everyone would complicate application code. From an application point
> of view, one would, with that type of protocol, need to do the
> following:
> 1) Load an audio file in any audio file format from any storage mechanism.
> 2) Decode the audio file format to extract the samples and audio metadata.
> 3) Resample the (now decoded) audio samples and convert (quantize) the
> audio samples into signed 16-bit PCM audio.
> 4) forward the samples onto the EFI audio protocol.

You have made an incorrect assumption that there exists a requirement to 
be able to play audio files in arbitrary formats.  This requirement does 
not exist.

With a protocol-mandated fixed baseline set of audio parameters (sample 
rate etc), what would happen in practice is that the audio files would 
be encoded in that format at *build* time, using tools entirely external 
to UEFI.  The application code is then trivially simple: it just does 
"load blob, pass blob to audio protocol".

> typedef struct EFI_SIMPLE_AUDIO_PROTOCOL {
>    EFI_SIMPLE_AUDIO_PROTOCOL_RESET Reset;
>    EFI_SIMPLE_AUDIO_PROTOCOL_START Start;
>    EFI_SIMPLE_AUDIO_PROTOCOL_STOP Stop;
> } EFI_SIMPLE_AUDIO_PROTOCOL;

This is now starting to look like something that belongs in boot-time 
firmware.  :)

Michael

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Michael Brown]

On 16/04/2021 01:59, Ethin Probst wrote:
> Also, I'm a bit confused. I've looked at several VirtIO devices now
> and have seen things like this:
> #define VIRTIO_PCI_DEVICE_SIGNATURE   SIGNATURE_32 ('V', 'P', 'C', 'I')
> // ...
>    UINT32                 Signature;
> I'm quite confused because I can't seem to find this anywhere in the
> VirtIO specification. The spec says nothing about signature values
> anywhere, just the magic value of 0x74726976. So where does this come
> from?

 From a quick look at the code, it seems to be a private signature value 
applied to a software-only data structure used by the UEFI driver, and 
is used solely for sanity checking that a pointer is pointing to the 
right kind of object.

Michael

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Ethin Probst]

Oh, okay, thank you.

On 4/15/21, Michael Brown <mcb30@ipxe.org> wrote:
> On 16/04/2021 01:59, Ethin Probst wrote:
>> Also, I'm a bit confused. I've looked at several VirtIO devices now
>> and have seen things like this:
>> #define VIRTIO_PCI_DEVICE_SIGNATURE   SIGNATURE_32 ('V', 'P', 'C', 'I')
>> // ...
>>    UINT32                 Signature;
>> I'm quite confused because I can't seem to find this anywhere in the
>> VirtIO specification. The spec says nothing about signature values
>> anywhere, just the magic value of 0x74726976. So where does this come
>> from?
>
>  From a quick look at the code, it seems to be a private signature value
> applied to a software-only data structure used by the UEFI driver, and
> is used solely for sanity checking that a pointer is pointing to the
> right kind of object.
>
> Michael
>


-- 
Signed,
Ethin D. Probst

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Andrew Fish]

[-- Attachment #1: Type: text/plain, Size: 2067 bytes --]



> On Apr 15, 2021, at 6:03 PM, Michael Brown <mcb30@ipxe.org> wrote:
> 
> On 16/04/2021 01:59, Ethin Probst wrote:
>> Also, I'm a bit confused. I've looked at several VirtIO devices now
>> and have seen things like this:
>> #define VIRTIO_PCI_DEVICE_SIGNATURE   SIGNATURE_32 ('V', 'P', 'C', 'I')
>> // ...
>>   UINT32                 Signature;
>> I'm quite confused because I can't seem to find this anywhere in the
>> VirtIO specification. The spec says nothing about signature values
>> anywhere, just the magic value of 0x74726976. So where does this come
>> from?
> 
> From a quick look at the code, it seems to be a private signature value applied to a software-only data structure used by the UEFI driver, and is used solely for sanity checking that a pointer is pointing to the right kind of object.
> 

Ethin,

This is a common edk2 code pattern. We have something called a Containment Record (CR) macro [1] and the DEBUG version of the CR macro [2] checks the signature. What happens is the public API is a Field in the private data structure, thus you can convert the This pointer to the private context of the driver for that protocol instances. The driver publishes the protocol from the Start() function so that is why the This pointer is always going to be a member of the larger private context structure. 

This pattern is also used for double linked lists as the data structure to represent the link list is generic and the data is attached to it via the Containment Record scheme by making that linked list data structure part of the larger data structure. 

[1] #define BASE_CR(Record, TYPE, Field)  ((TYPE *) ((CHAR8 *) (Record) - OFFSET_OF (TYPE, Field)))

[2] 
  #define CR(Record, TYPE, Field, TestSignature)                                              \
    (DebugAssertEnabled () && (BASE_CR (Record, TYPE, Field)->Signature != TestSignature)) ?  \
    (TYPE *) (_ASSERT (CR has Bad Signature), Record) :                                       \
    BASE_CR (Record, TYPE, Field)

Thanks,

Andrew Fish


[-- Attachment #2: Type: text/html, Size: 9743 bytes --]

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Ethin Probst]

Thanks, Andrew, that explains a lot. I've gotten the EDK2 build
process working successfully (which makes me really happy) so I can,
in theory, begin development on the protocol and driver at any time,
though I'm not sure if starting development now would be a good idea.
As noted in the EDK2 driver development guide I'm working on the
latest validated branch (edk2-stable202102). I guess the base
requirements for an audio protocol that we can all agree on are these:
- The audio protocol should allow for muting and volume control.
- The protocol should not be overly complicated to implement,
especially if it is to be standardized in future. (I think we can all
agree that it also shouldn't be hard to use, either.)
- The protocol should be multiple protocols, one for each audio device
supported. (I just use the singular to refer to the entire set of
them.).
Looking at the idea of my simple audio protocol that I outlined
previously, I don't think that's necessarily going to be possible or
easy -- not in the context of providing a single simple audio protocol
that manages the underlying device(s). In particular, if that's
something that would be desirable, we'd need to develop the
device-specific protocols first and then the simple audio protocol,
which would consume all of the device-specific ones and produce the
simple one. Since I'll only be working on VirtIO to start with,
though, that shouldn't be too complex, I don't think. I'd need to add
volume control and muting to my simple audio protocol idea though --
which is easy to do (apparently VirtIO makes this really easy; all you
need to do is set the channel mapping to VIRTIO_SND_PCM_CH_NA).
But backing up a way and focusing solely on VirtIO, here's what I'll
definitely have:
- A Start method that begins playback/recording (though I'll just
implement playback for now), and a Stop() method to stop a stream.
- A GetVolume() and SetVolume() function for volume control.
- A Mute()/Unmute() for muting and unmuting the stream.
- (Maybe?) A LoadBuffer()/UnloadBuffer() function for loading samples
into the appropriate queues (unless we want Start() to handle that).
The rest of the VirtIO device functionality can probably be ignored,
e.g.: jack remapping and such.
The only problem I see is the period_bytes parameter. In order for a
stream to be set up we have to send the VIRTIO_SND_R_PCM_SET_PARAMS
request, and period_bytes has to be a divisor of buffer_bytes (that
is, period_bytes % buffer_bytes == 0). If it doesn't violate GSoC
program rules and you guys are okay with it, I might develop a
preliminary protocol and a driver that uses it in order to figure out
exactly what the specification means in certain paragraphs, e.g.: in
sec. 5.14.6.6 where it seems to conflict with itself and says that all
buffers are of period_bytes bytes, but earlier in sec. 5.14.6.4.3 it
says that buffer_bytes is the size of the hardware buffer used by the
driver. I'm also going to see if I can glean anything from the Linux
kernel source code, as the kernel has a VirtIO sound driver that was
recently implemented. (I could also just write a driver for my hobby
OS kernel as well, but my kernel has no VirtIO support at the moment,
so I'd be implementing it from scratch.) If I can't start now and
develop when I have time, I'll just learn what I can from the Linux
sources.

On 4/15/21, Andrew Fish via groups.io <afish=apple.com@groups.io> wrote:
>
>
>> On Apr 15, 2021, at 6:03 PM, Michael Brown <mcb30@ipxe.org> wrote:
>>
>> On 16/04/2021 01:59, Ethin Probst wrote:
>>> Also, I'm a bit confused. I've looked at several VirtIO devices now
>>> and have seen things like this:
>>> #define VIRTIO_PCI_DEVICE_SIGNATURE   SIGNATURE_32 ('V', 'P', 'C', 'I')
>>> // ...
>>>   UINT32                 Signature;
>>> I'm quite confused because I can't seem to find this anywhere in the
>>> VirtIO specification. The spec says nothing about signature values
>>> anywhere, just the magic value of 0x74726976. So where does this come
>>> from?
>>
>> From a quick look at the code, it seems to be a private signature value
>> applied to a software-only data structure used by the UEFI driver, and is
>> used solely for sanity checking that a pointer is pointing to the right
>> kind of object.
>>
>
> Ethin,
>
> This is a common edk2 code pattern. We have something called a Containment
> Record (CR) macro [1] and the DEBUG version of the CR macro [2] checks the
> signature. What happens is the public API is a Field in the private data
> structure, thus you can convert the This pointer to the private context of
> the driver for that protocol instances. The driver publishes the protocol
> from the Start() function so that is why the This pointer is always going to
> be a member of the larger private context structure.
>
> This pattern is also used for double linked lists as the data structure to
> represent the link list is generic and the data is attached to it via the
> Containment Record scheme by making that linked list data structure part of
> the larger data structure.
>
> [1] #define BASE_CR(Record, TYPE, Field)  ((TYPE *) ((CHAR8 *) (Record) -
> OFFSET_OF (TYPE, Field)))
>
> [2]
>   #define CR(Record, TYPE, Field, TestSignature)
>                  \
>     (DebugAssertEnabled () && (BASE_CR (Record, TYPE, Field)->Signature !=
> TestSignature)) ?  \
>     (TYPE *) (_ASSERT (CR has Bad Signature), Record) :
>                  \
>     BASE_CR (Record, TYPE, Field)
>
> Thanks,
>
> Andrew Fish
>
>
>
> 
>
>
>


-- 
Signed,
Ethin D. Probst

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Andrew Fish]

> On Apr 15, 2021, at 5:59 PM, Michael Brown <mcb30@ipxe.org> wrote:
> 
> On 16/04/2021 00:42, Ethin Probst wrote:
>> Forcing a particular channel mapping, sample rate and sample format on
>> everyone would complicate application code. From an application point
>> of view, one would, with that type of protocol, need to do the
>> following:
>> 1) Load an audio file in any audio file format from any storage mechanism.
>> 2) Decode the audio file format to extract the samples and audio metadata.
>> 3) Resample the (now decoded) audio samples and convert (quantize) the
>> audio samples into signed 16-bit PCM audio.
>> 4) forward the samples onto the EFI audio protocol.
> 
> You have made an incorrect assumption that there exists a requirement to be able to play audio files in arbitrary formats.  This requirement does not exist.
> 
> With a protocol-mandated fixed baseline set of audio parameters (sample rate etc), what would happen in practice is that the audio files would be encoded in that format at *build* time, using tools entirely external to UEFI.  The application code is then trivially simple: it just does "load blob, pass blob to audio protocol".
> 


Ethin,

Given the goal is an industry standard we value interoperability more that flexibility. 

How about another use case. Lets say the Linux OS loader (Grub) wants to have an accessible UI so it decides to sore sound files on the EFI System Partition and use our new fancy UEFI Audio Protocol to add audio to the OS loader GUI. So that version of Grub needs to work on 1,000 of different PCs and a wide range of UEFI Audio driver implementations. It is a much easier world if Wave PCM 16 bit just works every place. You could add a lot of complexity and try to encode the audio on the fly, maybe even in Linux proper but that falls down if you are booting from read only media like a DVD or backup tape (yes people still do that in server land). 

The other problem with flexibility is you just made the test matrix very large for every driver that needs to get implemented. For something as complex as Intel HDA how you hook up the hardware and what CODECs you use may impact the quality of the playback for a given board. Your EFI is likely going to pick a single encoding at that will get tested all the time if your system has audio, but all 50 other things you support not so much. So that will required testing, and some one with audiophile ears (or an AI program) to test all the combinations. I’m not kidding I get BZs on the quality of the boot bong on our systems. 


>> typedef struct EFI_SIMPLE_AUDIO_PROTOCOL {
>>   EFI_SIMPLE_AUDIO_PROTOCOL_RESET Reset;
>>   EFI_SIMPLE_AUDIO_PROTOCOL_START Start;
>>   EFI_SIMPLE_AUDIO_PROTOCOL_STOP Stop;
>> } EFI_SIMPLE_AUDIO_PROTOCOL;
> 
> This is now starting to look like something that belongs in boot-time firmware.  :)
> 

I think that got a little too simple I’d go back and look at the example I posted to the thread but add an API to load the buffer, and then play the buffer (that way we can an API in the future to twiddle knobs). That API also implements the async EFI interface. Trust me the 1st thing that is going to happen when we add audio is some one is going to complain in xyz state we should mute audio, or we should honer audio volume and mute settings from setup, or from values set in the OS. Or some one is going to want the volume keys on the keyboard to work in EFI. 

Also if you need to pick apart the Wave PCM 16 byte file to feed it into the audio hardware that probably means we should have a library that does that work, so other Audio drivers can share that code. Also having a library makes it easier to write a unit test. We need to be security conscious as we need to treat the Audo file as attacker controlled data. 

Thanks,

Andrew Fish

> Michael
> 
> 
> 
> 
> 

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Ethin Probst]

Thanks for that explanation (I missed Mike's message). Earlier I sent
a summary of those things that we can agree on: mainly, that we have
mute, volume control, a load buffer, (maybe) an unload buffer, and a
start/stop stream function. Now that I fully understand the
ramifications of this I don't mind settling for a specific format and
sample rate, and signed 16-bit PCM audio is, I think, the most widely
used one out there, besides 64-bit floating point samples, which I've
only seen used in DAWs, and that's something we don't need.
Are you sure you want the firmware itself to handle the decoding of
WAV audio? I can make a library class for that, but I'll definitely
need help with the security aspect.

On 4/16/21, Andrew Fish via groups.io <afish=apple.com@groups.io> wrote:
>
>
>> On Apr 15, 2021, at 5:59 PM, Michael Brown <mcb30@ipxe.org> wrote:
>>
>> On 16/04/2021 00:42, Ethin Probst wrote:
>>> Forcing a particular channel mapping, sample rate and sample format on
>>> everyone would complicate application code. From an application point
>>> of view, one would, with that type of protocol, need to do the
>>> following:
>>> 1) Load an audio file in any audio file format from any storage
>>> mechanism.
>>> 2) Decode the audio file format to extract the samples and audio
>>> metadata.
>>> 3) Resample the (now decoded) audio samples and convert (quantize) the
>>> audio samples into signed 16-bit PCM audio.
>>> 4) forward the samples onto the EFI audio protocol.
>>
>> You have made an incorrect assumption that there exists a requirement to
>> be able to play audio files in arbitrary formats.  This requirement does
>> not exist.
>>
>> With a protocol-mandated fixed baseline set of audio parameters (sample
>> rate etc), what would happen in practice is that the audio files would be
>> encoded in that format at *build* time, using tools entirely external to
>> UEFI.  The application code is then trivially simple: it just does "load
>> blob, pass blob to audio protocol".
>>
>
>
> Ethin,
>
> Given the goal is an industry standard we value interoperability more that
> flexibility.
>
> How about another use case. Lets say the Linux OS loader (Grub) wants to
> have an accessible UI so it decides to sore sound files on the EFI System
> Partition and use our new fancy UEFI Audio Protocol to add audio to the OS
> loader GUI. So that version of Grub needs to work on 1,000 of different PCs
> and a wide range of UEFI Audio driver implementations. It is a much easier
> world if Wave PCM 16 bit just works every place. You could add a lot of
> complexity and try to encode the audio on the fly, maybe even in Linux
> proper but that falls down if you are booting from read only media like a
> DVD or backup tape (yes people still do that in server land).
>
> The other problem with flexibility is you just made the test matrix very
> large for every driver that needs to get implemented. For something as
> complex as Intel HDA how you hook up the hardware and what CODECs you use
> may impact the quality of the playback for a given board. Your EFI is likely
> going to pick a single encoding at that will get tested all the time if your
> system has audio, but all 50 other things you support not so much. So that
> will required testing, and some one with audiophile ears (or an AI program)
> to test all the combinations. I’m not kidding I get BZs on the quality of
> the boot bong on our systems.
>
>
>>> typedef struct EFI_SIMPLE_AUDIO_PROTOCOL {
>>>   EFI_SIMPLE_AUDIO_PROTOCOL_RESET Reset;
>>>   EFI_SIMPLE_AUDIO_PROTOCOL_START Start;
>>>   EFI_SIMPLE_AUDIO_PROTOCOL_STOP Stop;
>>> } EFI_SIMPLE_AUDIO_PROTOCOL;
>>
>> This is now starting to look like something that belongs in boot-time
>> firmware.  :)
>>
>
> I think that got a little too simple I’d go back and look at the example I
> posted to the thread but add an API to load the buffer, and then play the
> buffer (that way we can an API in the future to twiddle knobs). That API
> also implements the async EFI interface. Trust me the 1st thing that is
> going to happen when we add audio is some one is going to complain in xyz
> state we should mute audio, or we should honer audio volume and mute
> settings from setup, or from values set in the OS. Or some one is going to
> want the volume keys on the keyboard to work in EFI.
>
> Also if you need to pick apart the Wave PCM 16 byte file to feed it into the
> audio hardware that probably means we should have a library that does that
> work, so other Audio drivers can share that code. Also having a library
> makes it easier to write a unit test. We need to be security conscious as we
> need to treat the Audo file as attacker controlled data.
>
> Thanks,
>
> Andrew Fish
>
>> Michael
>>
>>
>>
>>
>>
>
>
>
> 
>
>
>


-- 
Signed,
Ethin D. Probst

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Leif Lindholm]

Hi Ethin,

I think we also want to have a SetMode function, even if we don't get
around to implement proper support for it as part of GSoC (although I
expect at least for virtio, that should be pretty straightforward).

It's quite likely that speech for UI would be stored as 8kHz (or
20kHz) in some systems, whereas the example for playing a tune in GRUB
would more likely be a 44.1 kHz mp3/wav/ogg/flac.

For the GSoC project, I think it would be quite reasonable to
pre-generate pure PCM streams for testing rather than decoding
anything on the fly.

Porting/writing decoders is really a separate task from enabling the
output. I would much rather see USB *and* HDA support able to play pcm
streams before worrying about decoding.

/
    Leif

On Fri, Apr 16, 2021 at 00:33:06 -0500, Ethin Probst wrote:
> Thanks for that explanation (I missed Mike's message). Earlier I sent
> a summary of those things that we can agree on: mainly, that we have
> mute, volume control, a load buffer, (maybe) an unload buffer, and a
> start/stop stream function. Now that I fully understand the
> ramifications of this I don't mind settling for a specific format and
> sample rate, and signed 16-bit PCM audio is, I think, the most widely
> used one out there, besides 64-bit floating point samples, which I've
> only seen used in DAWs, and that's something we don't need.
> Are you sure you want the firmware itself to handle the decoding of
> WAV audio? I can make a library class for that, but I'll definitely
> need help with the security aspect.
> 
> On 4/16/21, Andrew Fish via groups.io <afish=apple.com@groups.io> wrote:
> >
> >
> >> On Apr 15, 2021, at 5:59 PM, Michael Brown <mcb30@ipxe.org> wrote:
> >>
> >> On 16/04/2021 00:42, Ethin Probst wrote:
> >>> Forcing a particular channel mapping, sample rate and sample format on
> >>> everyone would complicate application code. From an application point
> >>> of view, one would, with that type of protocol, need to do the
> >>> following:
> >>> 1) Load an audio file in any audio file format from any storage
> >>> mechanism.
> >>> 2) Decode the audio file format to extract the samples and audio
> >>> metadata.
> >>> 3) Resample the (now decoded) audio samples and convert (quantize) the
> >>> audio samples into signed 16-bit PCM audio.
> >>> 4) forward the samples onto the EFI audio protocol.
> >>
> >> You have made an incorrect assumption that there exists a requirement to
> >> be able to play audio files in arbitrary formats.  This requirement does
> >> not exist.
> >>
> >> With a protocol-mandated fixed baseline set of audio parameters (sample
> >> rate etc), what would happen in practice is that the audio files would be
> >> encoded in that format at *build* time, using tools entirely external to
> >> UEFI.  The application code is then trivially simple: it just does "load
> >> blob, pass blob to audio protocol".
> >>
> >
> >
> > Ethin,
> >
> > Given the goal is an industry standard we value interoperability more that
> > flexibility.
> >
> > How about another use case. Lets say the Linux OS loader (Grub) wants to
> > have an accessible UI so it decides to sore sound files on the EFI System
> > Partition and use our new fancy UEFI Audio Protocol to add audio to the OS
> > loader GUI. So that version of Grub needs to work on 1,000 of different PCs
> > and a wide range of UEFI Audio driver implementations. It is a much easier
> > world if Wave PCM 16 bit just works every place. You could add a lot of
> > complexity and try to encode the audio on the fly, maybe even in Linux
> > proper but that falls down if you are booting from read only media like a
> > DVD or backup tape (yes people still do that in server land).
> >
> > The other problem with flexibility is you just made the test matrix very
> > large for every driver that needs to get implemented. For something as
> > complex as Intel HDA how you hook up the hardware and what CODECs you use
> > may impact the quality of the playback for a given board. Your EFI is likely
> > going to pick a single encoding at that will get tested all the time if your
> > system has audio, but all 50 other things you support not so much. So that
> > will required testing, and some one with audiophile ears (or an AI program)
> > to test all the combinations. I’m not kidding I get BZs on the quality of
> > the boot bong on our systems.
> >
> >
> >>> typedef struct EFI_SIMPLE_AUDIO_PROTOCOL {
> >>>   EFI_SIMPLE_AUDIO_PROTOCOL_RESET Reset;
> >>>   EFI_SIMPLE_AUDIO_PROTOCOL_START Start;
> >>>   EFI_SIMPLE_AUDIO_PROTOCOL_STOP Stop;
> >>> } EFI_SIMPLE_AUDIO_PROTOCOL;
> >>
> >> This is now starting to look like something that belongs in boot-time
> >> firmware.  :)
> >>
> >
> > I think that got a little too simple I’d go back and look at the example I
> > posted to the thread but add an API to load the buffer, and then play the
> > buffer (that way we can an API in the future to twiddle knobs). That API
> > also implements the async EFI interface. Trust me the 1st thing that is
> > going to happen when we add audio is some one is going to complain in xyz
> > state we should mute audio, or we should honer audio volume and mute
> > settings from setup, or from values set in the OS. Or some one is going to
> > want the volume keys on the keyboard to work in EFI.
> >
> > Also if you need to pick apart the Wave PCM 16 byte file to feed it into the
> > audio hardware that probably means we should have a library that does that
> > work, so other Audio drivers can share that code. Also having a library
> > makes it easier to write a unit test. We need to be security conscious as we
> > need to treat the Audo file as attacker controlled data.
> >
> > Thanks,
> >
> > Andrew Fish
> >
> >> Michael
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> > 
> >
> >
> >
> 
> 
> -- 
> Signed,
> Ethin D. Probst

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Marvin Häuser]

Good day,

Sorry for the nitpicking.

- Protocols always need a "Revision" field as first member. This is used 
to be able to expand its capabilities in later revisions without 
introducing a new, distinct protocol.
- Consider the name EFI_SIMPLE_AUDIO_OUTPUT(!)_PROTOCOL, to not cause 
confusion if input is ever added. Input in my opinion should be a 
separate protocol as there is no reason why they would necessarily be 
coupled topology-wise (think of an USB microphone, it will never have 
any sort of output).
- To make code safety a bit easier, try to use "CONST" for "IN" 
(non-OUT) pointers, so that CONST can be propagated where possible.
- Please do *not* make the events caller-owned. We had it multiple times 
already on production firmware that events are left dangling and may be 
polled/signaled after ExitBS(). The caller should be able to decide on 
some policy maybe (i.e. abort or block on ExitBS() until the playback 
finished), as cut-off audio may be awkward; but the callee definitely 
should implement "event safety" itself. Maybe avoid exposing events 
directly at all and provide nice abstractions the caller cannot misuse.
- I don't think audio should be required at all, the required subset 
should firstly consider minimalism and security. Accessibility will not 
be of concern for some IoT device, the audio code would simply eat 
space, and introduce a larger surface for bugs.

Best regards,
Marvin

On 16.04.21 01:42, Ethin Probst wrote:
> Hi Andrew,
>
> What would that protocol interface look like if we utilized your idea?
> With mine (though I need to add channel mapping as well), your
> workflow for playing a stereo sound from left to right would probably
> be something like this:
> 1) Encode the sound using a standard tool into a Wave PCM 16.
> 2) Place the Wave file in the Firmware Volume using a given UUID as
> the name. As simple as editing the platform FDF file.
> 3) Write some BDS code
>    a) Lookup Wave file by UUID and read it into memory.
>    b) Decode the audio file (audio devices will not do this decoding
> for you, you have to do that yourself).
>    c) Call EFI_AUDIO_PROTOCOL.LoadBuffer(), passing in the sample rate
> of your audio, EFI_AUDIO_PROTOCOL_SAMPLE_FORMAT_S16 for signed 16-bit
> PCM audio, the channel mapping, the number of samples, and the samples
> themselves.
>    d) call EFI_BOOT_SERVICES.CreateEvent()/EFI_BOOT_SERVICES.CreateEventEx()
> for a playback event to signal.
>    e) call EFI_AUDIO_PROTOCOL.StartPlayback(), passing in the event you
> just created.
> The reason that LoadBuffer() takes so many parameters is because the
> device does not know the audio that your passing in. If I'm given an
> array of 16-bit audio samples, its impossible to know the parameters
> (sample rate, sample format, channel mapping, etc.) from that alone.
> Using your idea, though, my protocol could be greatly simplified.
> Forcing a particular channel mapping, sample rate and sample format on
> everyone would complicate application code. From an application point
> of view, one would, with that type of protocol, need to do the
> following:
> 1) Load an audio file in any audio file format from any storage mechanism.
> 2) Decode the audio file format to extract the samples and audio metadata.
> 3) Resample the (now decoded) audio samples and convert (quantize) the
> audio samples into signed 16-bit PCM audio.
> 4) forward the samples onto the EFI audio protocol.
> There is another option. (I'm happy we're discussing this now -- we
> can hammer out all the details now which will make a lot of things
> easier.) Since I'll most likely end up splitting the device-specific
> interfaces to different audio protocols, we could make a simple audio
> protocol that makes various assumptions about the audio samples your
> giving it (e.g.: sample rate, format, ...). This would just allow
> audio output and input in signed 16-bit PCM audio, as you've
> suggested, and would be a simple and easy to use interface. Something
> like:
> typedef struct EFI_SIMPLE_AUDIO_PROTOCOL {
>    EFI_SIMPLE_AUDIO_PROTOCOL_RESET Reset;
>    EFI_SIMPLE_AUDIO_PROTOCOL_START Start;
>    EFI_SIMPLE_AUDIO_PROTOCOL_STOP Stop;
> } EFI_SIMPLE_AUDIO_PROTOCOL;
> This way, users and driver developers have a simple audio protocol
> they can implement if they like. It would assume signed 16-bit PCM
> audio and mono channel mappings at 44100 Hz. Then, we can have an
> advanced protocol for each device type (HDA, USB, VirtIO, ...) that
> exposes all the knobs for sample formats, sample rates, that kind of
> thing. Obviously, like the majority (if not all) UEFI protocols, these
> advanced protocols would be optional. I think, however, that the
> simple audio protocol should be a required protocol in all UEFI
> implementations. But that might not be possible. So would this simpler
> interface work as a starting point?
>
> On 4/15/21, Andrew Fish <afish@apple.com> wrote:
>>
>>> On Apr 15, 2021, at 1:11 PM, Ethin Probst <harlydavidsen@gmail.com>
>>> wrote:
>>>
>>>> Is there any necessity for audio input and output to be implemented
>>>> within the same protocol?  Unlike a network device (which is
>>>> intrinsically bidirectional), it seems natural to conceptually separate
>>>> audio input from audio output.
>>> Nope, there isn't a necessity to make them in one, they can be
>>> separated into two.
>>>
>>>> The code controlling volume/mute may not have any access to the sample
>>>> buffer.  The most natural implementation would seem to allow for a
>>>> platform to notice volume up/down keypresses and use those to control the
>>>> overall system volume, without any knowledge of which samples (if any)
>>>> are currently being played by other code in the system.
>>> Your assuming that the audio device your implementing the
>>> volume/muting has volume control and muting functionality within
>>> itself, then.
>> Not really. We are assuming that audio hardware has a better understanding
>> of how that system implements volume than some generic EFI Code that is by
>> definition platform agnostic.
>>
>>> This may not be the case, and so we'd need to
>>> effectively simulate it within the driver, which isn't too hard to do.
>>> As an example, the VirtIO driver does not have a request type for
>>> muting or for volume control (this would, most likely, be within the
>>> VIRTIO_SND_R_PCM_SET_PARAMS request, see sec. 5.14.6.4.3). Therefore,
>>> either the driver would have to simulate the request or return
>>> EFI_UNSUPPORTED this instance.
>>>
>> So this is an example of above since the audio hardware knows it is routing
>> the sound output into another subsystem, and that subsystem controls the
>> volume. So the VirtIo Sound Driver know best how to bstract volume/mute for
>> this platform.
>>
>>>> Consider also the point of view of the developer implementing a driver
>>>> for some other piece of audio hardware that happens not to support
>>>> precisely the same sample rates etc as VirtIO.  It would be extremely
>>>> ugly to force all future hardware to pretend to have the same
>>>> capabilities as VirtIO just because the API was initially designed with
>>>> VirtIO in mind.
>>> Precisely, but the brilliance of VirtIO
>> The brilliance of VirtIO is that it just needs to implement a generic device
>> driver for a given operating system. In most cases these operating systems
>> have sounds subsystems that manage sound and want fine granularity of
>> control on what is going on. So the drivers are implemented to maximizes
>> flexibility since the OS has lots of generic code that deals with sound, and
>> even user configurable knobs to control audio. In our case that extra layer
>> does not exist in EFI and the end user code just want to tell the driver do
>> some simple things.
>>
>> Maybe it is easier to think about with an example. Lets say I want to play a
>> cool sound on every boot. What would be the workflow to make the happen.
>> 1) Encode the sound using a standard tool into a Wave PCM 16.
>> 2) Place the Wave file in the Firmware Volume using a given UUID as the
>> name. As simple as editing the platform FDF file.
>> 3) Write some BDS code
>>    a) Lookup Wave file by UUID and read it into memory.
>>    b) Point the EFI Sound Protocol at the buffer with the Wave file
>>    c) Tell the EFI Sound Protocol to play the sound.
>>
>> If you start adding in a lot of perimeters that work flow starts getting
>> really complicated really quickly.
>>
>>> is that the sample rate,
>>> sample format, &c., do not have to all be supported by a VirtIO
>>> device. Notice, also, how in my protocol proposal I noted that the
>>> sample rates, at least, were "recommended," not "required." Should a
>>> device not happen to support a sample rate or sample format, all it
>>> needs to do is return EFI_INVALID_PARAMETER. Section 5.14.6.2.1
>>> (VIRTIO_SND_R_JACK_GET_CONFIG) describes how a jack tells you what
>>> sample rates it supports, channel mappings, &c.
>>>
>>> I do understand how just using a predefined sample rate and sample
>>> format might be a good idea, and if that's the best way, then that's
>>> what we'll do. The protocol can always be revised at a later time if
>>> necessary. I apologize if my stance seems obstinate.
>>>
>> I think if we add the version into the protocol and make sure we have a
>> separate load and play operation we could add a member to set the extra
>> perimeters if needed. There might also be some platform specific generic
>> tunables that might be interesting for a future member function.
>>
>> Thanks,
>>
>> Andrew Fish
>>
>>> Also, thank you, Laszlo, for your advice -- I hadn't considered that a
>>> network driver would be another good way of figuring out how async
>>> works in UEFI.
>>>
>>> On 4/15/21, Andrew Fish <afish@apple.com> wrote:
>>>>
>>>>> On Apr 15, 2021, at 5:07 AM, Michael Brown <mcb30@ipxe.org> wrote:
>>>>>
>>>>> On 15/04/2021 06:28, Ethin Probst wrote:
>>>>>> - I hoped to add recording in case we in future want to add
>>>>>> accessibility aids like speech recognition (that was one of the todo
>>>>>> tasks on the EDK2 tasks list)
>>>>> Is there any necessity for audio input and output to be implemented
>>>>> within
>>>>> the same protocol?  Unlike a network device (which is intrinsically
>>>>> bidirectional), it seems natural to conceptually separate audio input
>>>>> from
>>>>> audio output.
>>>>>
>>>>>> - Muting and volume control could easily be added by just replacing
>>>>>> the sample buffer with silence and by multiplying all the samples by a
>>>>>> percentage.
>>>>> The code controlling volume/mute may not have any access to the sample
>>>>> buffer.  The most natural implementation would seem to allow for a
>>>>> platform to notice volume up/down keypresses and use those to control
>>>>> the
>>>>> overall system volume, without any knowledge of which samples (if any)
>>>>> are
>>>>> currently being played by other code in the system.
>>>>>
>>>> I’ve also thought of adding NVRAM variable that would let setup, UEFI
>>>> Shell,
>>>> or even the OS set the current volume, and Mute. This how it would be
>>>> consumed concept is why I proposed mute and volume being separate APIs.
>>>> The
>>>> volume up/down API in addition to fixed percentage might be overkill, but
>>>> it
>>>> does allow a non liner mapping to the volume up/down keys. You would be
>>>> surprised how picky audiophiles can be and it seems they like to file
>>>> Bugzillas.
>>>>
>>>>>> - Finally, the reason I used enumerations for specifying parameters
>>>>>> like sample rate and stuff was that I was looking at this protocol
>>>>>> from a general UEFI applications point of view. VirtIO supports all of
>>>>>> the sample configurations listed in my gist, and it seems reasonable
>>>>>> to allow the application to control those parameters instead of
>>>>>> forcing a particular parameter configuration onto the developer.
>>>>> Consider also the point of view of the developer implementing a driver
>>>>> for
>>>>> some other piece of audio hardware that happens not to support
>>>>> precisely
>>>>> the same sample rates etc as VirtIO.  It would be extremely ugly to
>>>>> force
>>>>> all future hardware to pretend to have the same capabilities as VirtIO
>>>>> just because the API was initially designed with VirtIO in mind.
>>>>>
>>>>> As a developer on the other side of the API, writing code to play sound
>>>>> files on an arbitrary unknown platform, I would prefer to simply
>>>>> consume
>>>>> as simple as possible an abstraction of an audio output protocol and
>>>>> not
>>>>> have to care about what hardware is actually implementing it.
>>>>>
>>>> It may make sense to have an API to load the buffer/stream and other APIs
>>>> to
>>>> play or pause. This could allow an optional API to configure how the
>>>> stream
>>>> is played back. If we add a version to the Protocol that would at least
>>>> future proof us.
>>>>
>>>> We did get feedback that it is very common to speed up the auto playback
>>>> rates for accessibility. I’m not sure if that is practical with a simple
>>>> PCM
>>>> 16 wave file with the firmware audio implementation. I guess that is
>>>> something we could investigate.
>>>>
>>>> In terms of maybe adding text to speech there is an open source project
>>>> that
>>>> conceptually we could port to EFI. It would likely be a binary that
>>>> would
>>>> have to live on the EFI System Partition due to size. I was thinking
>>>> that
>>>> words per minute could be part of that API and it would produce a PCM 16
>>>> wave file that the audio protocol we are discussing could play.
>>>>
>>>>> Both of these argue in favour of defining a very simple API that
>>>>> expresses
>>>>> only a common baseline capability that is plausibly implementable for
>>>>> every piece of audio hardware ever made.
>>>>>
>>>>> Coupled with the relatively minimalistic requirements for boot-time
>>>>> audio,
>>>>> I'd probably suggest supporting only a single format for audio data,
>>>>> with
>>>>> a fixed sample rate (and possibly only mono output).
>>>>>
>>>> In my world the folks that work for Jony asked for a stereo boot bong to
>>>> transition from left to right :). This is not the CODEC you are looking
>>>> for
>>>> was our response…. I also did not mention that some languages are right
>>>> to
>>>> left, as the only thing worse than one complex thing is two complex
>>>> things
>>>> to implement.
>>>>
>>>>> As always: perfection is achieved, not when there is nothing more to
>>>>> add,
>>>>> but when there is nothing left to take away.  :)
>>>>>
>>>> "Simplicity is the ultimate sophistication”
>>>>
>>>> Thanks,
>>>>
>>>> Andrew Fish
>>>>
>>>>> Thanks,
>>>>>
>>>>> Michael
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>> --
>>> Signed,
>>> Ethin D. Probst
>>
>

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Andrew Fish]

[-- Attachment #1: Type: text/plain, Size: 15862 bytes --]



> On Apr 16, 2021, at 6:22 AM, Marvin Häuser <mhaeuser@posteo.de> wrote:
> 
> Good day,
> 
> Sorry for the nitpicking.
> 
> - Protocols always need a "Revision" field as first member. This is used to be able to expand its capabilities in later revisions without introducing a new, distinct protocol.
> - Consider the name EFI_SIMPLE_AUDIO_OUTPUT(!)_PROTOCOL, to not cause confusion if input is ever added. Input in my opinion should be a separate protocol as there is no reason why they would necessarily be coupled topology-wise (think of an USB microphone, it will never have any sort of output).
> - To make code safety a bit easier, try to use "CONST" for "IN" (non-OUT) pointers, so that CONST can be propagated where possible.
> - Please do *not* make the events caller-owned. We had it multiple times already on production firmware that events are left dangling and may be polled/signaled after ExitBS(). The caller should be able to decide on some policy maybe (i.e. abort or block on ExitBS() until the playback finished), as cut-off audio may be awkward; but the callee definitely should implement "event safety" itself. Maybe avoid exposing events directly at all and provide nice abstractions the caller cannot misuse.
> - I don't think audio should be required at all, the required subset should firstly consider minimalism and security. Accessibility will not be of concern for some IoT device, the audio code would simply eat space, and introduce a larger surface for bugs.
> 

Marvin,

Generally how we work this in the UEFI Specification is we make it optional via the following wording: “If a platform includes the ability to play audio in EFI then the EFI_SIMPLE_AUDIO_OUTPUT_PROTOCOL must be implemented. 

Basically this requirement will get added to UEFI Specification 2.6.2 Platform-Specific Elements.

Thanks,

Andrew Fish

> Best regards,
> Marvin
> 
> On 16.04.21 01:42, Ethin Probst wrote:
>> Hi Andrew,
>> 
>> What would that protocol interface look like if we utilized your idea?
>> With mine (though I need to add channel mapping as well), your
>> workflow for playing a stereo sound from left to right would probably
>> be something like this:
>> 1) Encode the sound using a standard tool into a Wave PCM 16.
>> 2) Place the Wave file in the Firmware Volume using a given UUID as
>> the name. As simple as editing the platform FDF file.
>> 3) Write some BDS code
>>   a) Lookup Wave file by UUID and read it into memory.
>>   b) Decode the audio file (audio devices will not do this decoding
>> for you, you have to do that yourself).
>>   c) Call EFI_AUDIO_PROTOCOL.LoadBuffer(), passing in the sample rate
>> of your audio, EFI_AUDIO_PROTOCOL_SAMPLE_FORMAT_S16 for signed 16-bit
>> PCM audio, the channel mapping, the number of samples, and the samples
>> themselves.
>>   d) call EFI_BOOT_SERVICES.CreateEvent()/EFI_BOOT_SERVICES.CreateEventEx()
>> for a playback event to signal.
>>   e) call EFI_AUDIO_PROTOCOL.StartPlayback(), passing in the event you
>> just created.
>> The reason that LoadBuffer() takes so many parameters is because the
>> device does not know the audio that your passing in. If I'm given an
>> array of 16-bit audio samples, its impossible to know the parameters
>> (sample rate, sample format, channel mapping, etc.) from that alone.
>> Using your idea, though, my protocol could be greatly simplified.
>> Forcing a particular channel mapping, sample rate and sample format on
>> everyone would complicate application code. From an application point
>> of view, one would, with that type of protocol, need to do the
>> following:
>> 1) Load an audio file in any audio file format from any storage mechanism.
>> 2) Decode the audio file format to extract the samples and audio metadata.
>> 3) Resample the (now decoded) audio samples and convert (quantize) the
>> audio samples into signed 16-bit PCM audio.
>> 4) forward the samples onto the EFI audio protocol.
>> There is another option. (I'm happy we're discussing this now -- we
>> can hammer out all the details now which will make a lot of things
>> easier.) Since I'll most likely end up splitting the device-specific
>> interfaces to different audio protocols, we could make a simple audio
>> protocol that makes various assumptions about the audio samples your
>> giving it (e.g.: sample rate, format, ...). This would just allow
>> audio output and input in signed 16-bit PCM audio, as you've
>> suggested, and would be a simple and easy to use interface. Something
>> like:
>> typedef struct EFI_SIMPLE_AUDIO_PROTOCOL {
>>   EFI_SIMPLE_AUDIO_PROTOCOL_RESET Reset;
>>   EFI_SIMPLE_AUDIO_PROTOCOL_START Start;
>>   EFI_SIMPLE_AUDIO_PROTOCOL_STOP Stop;
>> } EFI_SIMPLE_AUDIO_PROTOCOL;
>> This way, users and driver developers have a simple audio protocol
>> they can implement if they like. It would assume signed 16-bit PCM
>> audio and mono channel mappings at 44100 Hz. Then, we can have an
>> advanced protocol for each device type (HDA, USB, VirtIO, ...) that
>> exposes all the knobs for sample formats, sample rates, that kind of
>> thing. Obviously, like the majority (if not all) UEFI protocols, these
>> advanced protocols would be optional. I think, however, that the
>> simple audio protocol should be a required protocol in all UEFI
>> implementations. But that might not be possible. So would this simpler
>> interface work as a starting point?
>> 
>> On 4/15/21, Andrew Fish <afish@apple.com> wrote:
>>> 
>>>> On Apr 15, 2021, at 1:11 PM, Ethin Probst <harlydavidsen@gmail.com>
>>>> wrote:
>>>> 
>>>>> Is there any necessity for audio input and output to be implemented
>>>>> within the same protocol?  Unlike a network device (which is
>>>>> intrinsically bidirectional), it seems natural to conceptually separate
>>>>> audio input from audio output.
>>>> Nope, there isn't a necessity to make them in one, they can be
>>>> separated into two.
>>>> 
>>>>> The code controlling volume/mute may not have any access to the sample
>>>>> buffer.  The most natural implementation would seem to allow for a
>>>>> platform to notice volume up/down keypresses and use those to control the
>>>>> overall system volume, without any knowledge of which samples (if any)
>>>>> are currently being played by other code in the system.
>>>> Your assuming that the audio device your implementing the
>>>> volume/muting has volume control and muting functionality within
>>>> itself, then.
>>> Not really. We are assuming that audio hardware has a better understanding
>>> of how that system implements volume than some generic EFI Code that is by
>>> definition platform agnostic.
>>> 
>>>> This may not be the case, and so we'd need to
>>>> effectively simulate it within the driver, which isn't too hard to do.
>>>> As an example, the VirtIO driver does not have a request type for
>>>> muting or for volume control (this would, most likely, be within the
>>>> VIRTIO_SND_R_PCM_SET_PARAMS request, see sec. 5.14.6.4.3). Therefore,
>>>> either the driver would have to simulate the request or return
>>>> EFI_UNSUPPORTED this instance.
>>>> 
>>> So this is an example of above since the audio hardware knows it is routing
>>> the sound output into another subsystem, and that subsystem controls the
>>> volume. So the VirtIo Sound Driver know best how to bstract volume/mute for
>>> this platform.
>>> 
>>>>> Consider also the point of view of the developer implementing a driver
>>>>> for some other piece of audio hardware that happens not to support
>>>>> precisely the same sample rates etc as VirtIO.  It would be extremely
>>>>> ugly to force all future hardware to pretend to have the same
>>>>> capabilities as VirtIO just because the API was initially designed with
>>>>> VirtIO in mind.
>>>> Precisely, but the brilliance of VirtIO
>>> The brilliance of VirtIO is that it just needs to implement a generic device
>>> driver for a given operating system. In most cases these operating systems
>>> have sounds subsystems that manage sound and want fine granularity of
>>> control on what is going on. So the drivers are implemented to maximizes
>>> flexibility since the OS has lots of generic code that deals with sound, and
>>> even user configurable knobs to control audio. In our case that extra layer
>>> does not exist in EFI and the end user code just want to tell the driver do
>>> some simple things.
>>> 
>>> Maybe it is easier to think about with an example. Lets say I want to play a
>>> cool sound on every boot. What would be the workflow to make the happen.
>>> 1) Encode the sound using a standard tool into a Wave PCM 16.
>>> 2) Place the Wave file in the Firmware Volume using a given UUID as the
>>> name. As simple as editing the platform FDF file.
>>> 3) Write some BDS code
>>>   a) Lookup Wave file by UUID and read it into memory.
>>>   b) Point the EFI Sound Protocol at the buffer with the Wave file
>>>   c) Tell the EFI Sound Protocol to play the sound.
>>> 
>>> If you start adding in a lot of perimeters that work flow starts getting
>>> really complicated really quickly.
>>> 
>>>> is that the sample rate,
>>>> sample format, &c., do not have to all be supported by a VirtIO
>>>> device. Notice, also, how in my protocol proposal I noted that the
>>>> sample rates, at least, were "recommended," not "required." Should a
>>>> device not happen to support a sample rate or sample format, all it
>>>> needs to do is return EFI_INVALID_PARAMETER. Section 5.14.6.2.1
>>>> (VIRTIO_SND_R_JACK_GET_CONFIG) describes how a jack tells you what
>>>> sample rates it supports, channel mappings, &c.
>>>> 
>>>> I do understand how just using a predefined sample rate and sample
>>>> format might be a good idea, and if that's the best way, then that's
>>>> what we'll do. The protocol can always be revised at a later time if
>>>> necessary. I apologize if my stance seems obstinate.
>>>> 
>>> I think if we add the version into the protocol and make sure we have a
>>> separate load and play operation we could add a member to set the extra
>>> perimeters if needed. There might also be some platform specific generic
>>> tunables that might be interesting for a future member function.
>>> 
>>> Thanks,
>>> 
>>> Andrew Fish
>>> 
>>>> Also, thank you, Laszlo, for your advice -- I hadn't considered that a
>>>> network driver would be another good way of figuring out how async
>>>> works in UEFI.
>>>> 
>>>> On 4/15/21, Andrew Fish <afish@apple.com> wrote:
>>>>> 
>>>>>> On Apr 15, 2021, at 5:07 AM, Michael Brown <mcb30@ipxe.org> wrote:
>>>>>> 
>>>>>> On 15/04/2021 06:28, Ethin Probst wrote:
>>>>>>> - I hoped to add recording in case we in future want to add
>>>>>>> accessibility aids like speech recognition (that was one of the todo
>>>>>>> tasks on the EDK2 tasks list)
>>>>>> Is there any necessity for audio input and output to be implemented
>>>>>> within
>>>>>> the same protocol?  Unlike a network device (which is intrinsically
>>>>>> bidirectional), it seems natural to conceptually separate audio input
>>>>>> from
>>>>>> audio output.
>>>>>> 
>>>>>>> - Muting and volume control could easily be added by just replacing
>>>>>>> the sample buffer with silence and by multiplying all the samples by a
>>>>>>> percentage.
>>>>>> The code controlling volume/mute may not have any access to the sample
>>>>>> buffer.  The most natural implementation would seem to allow for a
>>>>>> platform to notice volume up/down keypresses and use those to control
>>>>>> the
>>>>>> overall system volume, without any knowledge of which samples (if any)
>>>>>> are
>>>>>> currently being played by other code in the system.
>>>>>> 
>>>>> I’ve also thought of adding NVRAM variable that would let setup, UEFI
>>>>> Shell,
>>>>> or even the OS set the current volume, and Mute. This how it would be
>>>>> consumed concept is why I proposed mute and volume being separate APIs.
>>>>> The
>>>>> volume up/down API in addition to fixed percentage might be overkill, but
>>>>> it
>>>>> does allow a non liner mapping to the volume up/down keys. You would be
>>>>> surprised how picky audiophiles can be and it seems they like to file
>>>>> Bugzillas.
>>>>> 
>>>>>>> - Finally, the reason I used enumerations for specifying parameters
>>>>>>> like sample rate and stuff was that I was looking at this protocol
>>>>>>> from a general UEFI applications point of view. VirtIO supports all of
>>>>>>> the sample configurations listed in my gist, and it seems reasonable
>>>>>>> to allow the application to control those parameters instead of
>>>>>>> forcing a particular parameter configuration onto the developer.
>>>>>> Consider also the point of view of the developer implementing a driver
>>>>>> for
>>>>>> some other piece of audio hardware that happens not to support
>>>>>> precisely
>>>>>> the same sample rates etc as VirtIO.  It would be extremely ugly to
>>>>>> force
>>>>>> all future hardware to pretend to have the same capabilities as VirtIO
>>>>>> just because the API was initially designed with VirtIO in mind.
>>>>>> 
>>>>>> As a developer on the other side of the API, writing code to play sound
>>>>>> files on an arbitrary unknown platform, I would prefer to simply
>>>>>> consume
>>>>>> as simple as possible an abstraction of an audio output protocol and
>>>>>> not
>>>>>> have to care about what hardware is actually implementing it.
>>>>>> 
>>>>> It may make sense to have an API to load the buffer/stream and other APIs
>>>>> to
>>>>> play or pause. This could allow an optional API to configure how the
>>>>> stream
>>>>> is played back. If we add a version to the Protocol that would at least
>>>>> future proof us.
>>>>> 
>>>>> We did get feedback that it is very common to speed up the auto playback
>>>>> rates for accessibility. I’m not sure if that is practical with a simple
>>>>> PCM
>>>>> 16 wave file with the firmware audio implementation. I guess that is
>>>>> something we could investigate.
>>>>> 
>>>>> In terms of maybe adding text to speech there is an open source project
>>>>> that
>>>>> conceptually we could port to EFI. It would likely be a binary that
>>>>> would
>>>>> have to live on the EFI System Partition due to size. I was thinking
>>>>> that
>>>>> words per minute could be part of that API and it would produce a PCM 16
>>>>> wave file that the audio protocol we are discussing could play.
>>>>> 
>>>>>> Both of these argue in favour of defining a very simple API that
>>>>>> expresses
>>>>>> only a common baseline capability that is plausibly implementable for
>>>>>> every piece of audio hardware ever made.
>>>>>> 
>>>>>> Coupled with the relatively minimalistic requirements for boot-time
>>>>>> audio,
>>>>>> I'd probably suggest supporting only a single format for audio data,
>>>>>> with
>>>>>> a fixed sample rate (and possibly only mono output).
>>>>>> 
>>>>> In my world the folks that work for Jony asked for a stereo boot bong to
>>>>> transition from left to right :). This is not the CODEC you are looking
>>>>> for
>>>>> was our response…. I also did not mention that some languages are right
>>>>> to
>>>>> left, as the only thing worse than one complex thing is two complex
>>>>> things
>>>>> to implement.
>>>>> 
>>>>>> As always: perfection is achieved, not when there is nothing more to
>>>>>> add,
>>>>>> but when there is nothing left to take away.  :)
>>>>>> 
>>>>> "Simplicity is the ultimate sophistication”
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> Andrew Fish
>>>>> 
>>>>>> Thanks,
>>>>>> 
>>>>>> Michael
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> --
>>>> Signed,
>>>> Ethin D. Probst
>>> 
>> 
> 
> 
> 
> 


[-- Attachment #2: Type: text/html, Size: 29760 bytes --]

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Marvin Häuser]

On 16.04.21 16:34, Andrew Fish via groups.io wrote:
>
>
>> On Apr 16, 2021, at 6:22 AM, Marvin Häuser <mhaeuser@posteo.de 
>> <mailto:mhaeuser@posteo.de>> wrote:
>>
>> Good day,
>>
>> Sorry for the nitpicking.
>>
>> - Protocols always need a "Revision" field as first member. This is 
>> used to be able to expand its capabilities in later revisions without 
>> introducing a new, distinct protocol.
>> - Consider the name EFI_SIMPLE_AUDIO_OUTPUT(!)_PROTOCOL, to not cause 
>> confusion if input is ever added. Input in my opinion should be a 
>> separate protocol as there is no reason why they would necessarily be 
>> coupled topology-wise (think of an USB microphone, it will never have 
>> any sort of output).
>> - To make code safety a bit easier, try to use "CONST" for "IN" 
>> (non-OUT) pointers, so that CONST can be propagated where possible.
>> - Please do *not* make the events caller-owned. We had it multiple 
>> times already on production firmware that events are left dangling 
>> and may be polled/signaled after ExitBS(). The caller should be able 
>> to decide on some policy maybe (i.e. abort or block on ExitBS() until 
>> the playback finished), as cut-off audio may be awkward; but the 
>> callee definitely should implement "event safety" itself. Maybe avoid 
>> exposing events directly at all and provide nice abstractions the 
>> caller cannot misuse.
>> - I don't think audio should be required at all, the required subset 
>> should firstly consider minimalism and security. Accessibility will 
>> not be of concern for some IoT device, the audio code would simply 
>> eat space, and introduce a larger surface for bugs.
>>
>
> Marvin,
>
> Generally how we work this in the UEFI Specification is we make it 
> optional via the following wording: “If a platform includes the 
> ability to play audio in EFI then the EFI_SIMPLE_AUDIO_OUTPUT_PROTOCOL 
> must be implemented.

Yes, this sounds good. Just saying it should not be strictly mandatory 
on all platforms. :) Thanks!

Best regards,
Marvin

>
> Basically this requirement will get added to UEFI Specification 2.6.2 
> Platform-Specific Elements.
>
> Thanks,
>
> Andrew Fish
>
>> Best regards,
>> Marvin
>>
>> On 16.04.21 01:42, Ethin Probst wrote:
>>> Hi Andrew,
>>>
>>> What would that protocol interface look like if we utilized your idea?
>>> With mine (though I need to add channel mapping as well), your
>>> workflow for playing a stereo sound from left to right would probably
>>> be something like this:
>>> 1) Encode the sound using a standard tool into a Wave PCM 16.
>>> 2) Place the Wave file in the Firmware Volume using a given UUID as
>>> the name. As simple as editing the platform FDF file.
>>> 3) Write some BDS code
>>> a) Lookup Wave file by UUID and read it into memory.
>>> b) Decode the audio file (audio devices will not do this decoding
>>> for you, you have to do that yourself).
>>> c) Call EFI_AUDIO_PROTOCOL.LoadBuffer(), passing in the sample rate
>>> of your audio, EFI_AUDIO_PROTOCOL_SAMPLE_FORMAT_S16 for signed 16-bit
>>> PCM audio, the channel mapping, the number of samples, and the samples
>>> themselves.
>>>   d) call 
>>> EFI_BOOT_SERVICES.CreateEvent()/EFI_BOOT_SERVICES.CreateEventEx()
>>> for a playback event to signal.
>>>   e) call EFI_AUDIO_PROTOCOL.StartPlayback(), passing in the event you
>>> just created.
>>> The reason that LoadBuffer() takes so many parameters is because the
>>> device does not know the audio that your passing in. If I'm given an
>>> array of 16-bit audio samples, its impossible to know the parameters
>>> (sample rate, sample format, channel mapping, etc.) from that alone.
>>> Using your idea, though, my protocol could be greatly simplified.
>>> Forcing a particular channel mapping, sample rate and sample format on
>>> everyone would complicate application code. From an application point
>>> of view, one would, with that type of protocol, need to do the
>>> following:
>>> 1) Load an audio file in any audio file format from any storage 
>>> mechanism.
>>> 2) Decode the audio file format to extract the samples and audio 
>>> metadata.
>>> 3) Resample the (now decoded) audio samples and convert (quantize) the
>>> audio samples into signed 16-bit PCM audio.
>>> 4) forward the samples onto the EFI audio protocol.
>>> There is another option. (I'm happy we're discussing this now -- we
>>> can hammer out all the details now which will make a lot of things
>>> easier.) Since I'll most likely end up splitting the device-specific
>>> interfaces to different audio protocols, we could make a simple audio
>>> protocol that makes various assumptions about the audio samples your
>>> giving it (e.g.: sample rate, format, ...). This would just allow
>>> audio output and input in signed 16-bit PCM audio, as you've
>>> suggested, and would be a simple and easy to use interface. Something
>>> like:
>>> typedef struct EFI_SIMPLE_AUDIO_PROTOCOL {
>>>   EFI_SIMPLE_AUDIO_PROTOCOL_RESET Reset;
>>>   EFI_SIMPLE_AUDIO_PROTOCOL_START Start;
>>>   EFI_SIMPLE_AUDIO_PROTOCOL_STOP Stop;
>>> } EFI_SIMPLE_AUDIO_PROTOCOL;
>>> This way, users and driver developers have a simple audio protocol
>>> they can implement if they like. It would assume signed 16-bit PCM
>>> audio and mono channel mappings at 44100 Hz. Then, we can have an
>>> advanced protocol for each device type (HDA, USB, VirtIO, ...) that
>>> exposes all the knobs for sample formats, sample rates, that kind of
>>> thing. Obviously, like the majority (if not all) UEFI protocols, these
>>> advanced protocols would be optional. I think, however, that the
>>> simple audio protocol should be a required protocol in all UEFI
>>> implementations. But that might not be possible. So would this simpler
>>> interface work as a starting point?
>>>
>>> On 4/15/21, Andrew Fish <afish@apple.com <mailto:afish@apple.com>> 
>>> wrote:
>>>>
>>>>> On Apr 15, 2021, at 1:11 PM, Ethin Probst <harlydavidsen@gmail.com 
>>>>> <mailto:harlydavidsen@gmail.com>>
>>>>> wrote:
>>>>>
>>>>>> Is there any necessity for audio input and output to be implemented
>>>>>> within the same protocol?  Unlike a network device (which is
>>>>>> intrinsically bidirectional), it seems natural to conceptually 
>>>>>> separate
>>>>>> audio input from audio output.
>>>>> Nope, there isn't a necessity to make them in one, they can be
>>>>> separated into two.
>>>>>
>>>>>> The code controlling volume/mute may not have any access to the 
>>>>>> sample
>>>>>> buffer.  The most natural implementation would seem to allow for a
>>>>>> platform to notice volume up/down keypresses and use those to 
>>>>>> control the
>>>>>> overall system volume, without any knowledge of which samples (if 
>>>>>> any)
>>>>>> are currently being played by other code in the system.
>>>>> Your assuming that the audio device your implementing the
>>>>> volume/muting has volume control and muting functionality within
>>>>> itself, then.
>>>> Not really. We are assuming that audio hardware has a better 
>>>> understanding
>>>> of how that system implements volume than some generic EFI Code 
>>>> that is by
>>>> definition platform agnostic.
>>>>
>>>>> This may not be the case, and so we'd need to
>>>>> effectively simulate it within the driver, which isn't too hard to do.
>>>>> As an example, the VirtIO driver does not have a request type for
>>>>> muting or for volume control (this would, most likely, be within the
>>>>> VIRTIO_SND_R_PCM_SET_PARAMS request, see sec. 5.14.6.4.3). Therefore,
>>>>> either the driver would have to simulate the request or return
>>>>> EFI_UNSUPPORTED this instance.
>>>>>
>>>> So this is an example of above since the audio hardware knows it is 
>>>> routing
>>>> the sound output into another subsystem, and that subsystem 
>>>> controls the
>>>> volume. So the VirtIo Sound Driver know best how to bstract 
>>>> volume/mute for
>>>> this platform.
>>>>
>>>>>> Consider also the point of view of the developer implementing a 
>>>>>> driver
>>>>>> for some other piece of audio hardware that happens not to support
>>>>>> precisely the same sample rates etc as VirtIO.  It would be extremely
>>>>>> ugly to force all future hardware to pretend to have the same
>>>>>> capabilities as VirtIO just because the API was initially 
>>>>>> designed with
>>>>>> VirtIO in mind.
>>>>> Precisely, but the brilliance of VirtIO
>>>> The brilliance of VirtIO is that it just needs to implement a 
>>>> generic device
>>>> driver for a given operating system. In most cases these operating 
>>>> systems
>>>> have sounds subsystems that manage sound and want fine granularity of
>>>> control on what is going on. So the drivers are implemented to 
>>>> maximizes
>>>> flexibility since the OS has lots of generic code that deals with 
>>>> sound, and
>>>> even user configurable knobs to control audio. In our case that 
>>>> extra layer
>>>> does not exist in EFI and the end user code just want to tell the 
>>>> driver do
>>>> some simple things.
>>>>
>>>> Maybe it is easier to think about with an example. Lets say I want 
>>>> to play a
>>>> cool sound on every boot. What would be the workflow to make the 
>>>> happen.
>>>> 1) Encode the sound using a standard tool into a Wave PCM 16.
>>>> 2) Place the Wave file in the Firmware Volume using a given UUID as the
>>>> name. As simple as editing the platform FDF file.
>>>> 3) Write some BDS code
>>>>   a) Lookup Wave file by UUID and read it into memory.
>>>>   b) Point the EFI Sound Protocol at the buffer with the Wave file
>>>>   c) Tell the EFI Sound Protocol to play the sound.
>>>>
>>>> If you start adding in a lot of perimeters that work flow starts 
>>>> getting
>>>> really complicated really quickly.
>>>>
>>>>> is that the sample rate,
>>>>> sample format, &c., do not have to all be supported by a VirtIO
>>>>> device. Notice, also, how in my protocol proposal I noted that the
>>>>> sample rates, at least, were "recommended," not "required." Should a
>>>>> device not happen to support a sample rate or sample format, all it
>>>>> needs to do is return EFI_INVALID_PARAMETER. Section 5.14.6.2.1
>>>>> (VIRTIO_SND_R_JACK_GET_CONFIG) describes how a jack tells you what
>>>>> sample rates it supports, channel mappings, &c.
>>>>>
>>>>> I do understand how just using a predefined sample rate and sample
>>>>> format might be a good idea, and if that's the best way, then that's
>>>>> what we'll do. The protocol can always be revised at a later time if
>>>>> necessary. I apologize if my stance seems obstinate.
>>>>>
>>>> I think if we add the version into the protocol and make sure we have a
>>>> separate load and play operation we could add a member to set the extra
>>>> perimeters if needed. There might also be some platform specific 
>>>> generic
>>>> tunables that might be interesting for a future member function.
>>>>
>>>> Thanks,
>>>>
>>>> Andrew Fish
>>>>
>>>>> Also, thank you, Laszlo, for your advice -- I hadn't considered that a
>>>>> network driver would be another good way of figuring out how async
>>>>> works in UEFI.
>>>>>
>>>>> On 4/15/21, Andrew Fish <afish@apple.com <mailto:afish@apple.com>> 
>>>>> wrote:
>>>>>>
>>>>>>> On Apr 15, 2021, at 5:07 AM, Michael Brown <mcb30@ipxe.org 
>>>>>>> <mailto:mcb30@ipxe.org>> wrote:
>>>>>>>
>>>>>>> On 15/04/2021 06:28, Ethin Probst wrote:
>>>>>>>> - I hoped to add recording in case we in future want to add
>>>>>>>> accessibility aids like speech recognition (that was one of the 
>>>>>>>> todo
>>>>>>>> tasks on the EDK2 tasks list)
>>>>>>> Is there any necessity for audio input and output to be implemented
>>>>>>> within
>>>>>>> the same protocol?  Unlike a network device (which is intrinsically
>>>>>>> bidirectional), it seems natural to conceptually separate audio 
>>>>>>> input
>>>>>>> from
>>>>>>> audio output.
>>>>>>>
>>>>>>>> - Muting and volume control could easily be added by just replacing
>>>>>>>> the sample buffer with silence and by multiplying all the 
>>>>>>>> samples by a
>>>>>>>> percentage.
>>>>>>> The code controlling volume/mute may not have any access to the 
>>>>>>> sample
>>>>>>> buffer.  The most natural implementation would seem to allow for a
>>>>>>> platform to notice volume up/down keypresses and use those to 
>>>>>>> control
>>>>>>> the
>>>>>>> overall system volume, without any knowledge of which samples 
>>>>>>> (if any)
>>>>>>> are
>>>>>>> currently being played by other code in the system.
>>>>>>>
>>>>>> I’ve also thought of adding NVRAM variable that would let setup, UEFI
>>>>>> Shell,
>>>>>> or even the OS set the current volume, and Mute. This how it would be
>>>>>> consumed concept is why I proposed mute and volume being separate 
>>>>>> APIs.
>>>>>> The
>>>>>> volume up/down API in addition to fixed percentage might be 
>>>>>> overkill, but
>>>>>> it
>>>>>> does allow a non liner mapping to the volume up/down keys. You 
>>>>>> would be
>>>>>> surprised how picky audiophiles can be and it seems they like to file
>>>>>> Bugzillas.
>>>>>>
>>>>>>>> - Finally, the reason I used enumerations for specifying parameters
>>>>>>>> like sample rate and stuff was that I was looking at this protocol
>>>>>>>> from a general UEFI applications point of view. VirtIO supports 
>>>>>>>> all of
>>>>>>>> the sample configurations listed in my gist, and it seems 
>>>>>>>> reasonable
>>>>>>>> to allow the application to control those parameters instead of
>>>>>>>> forcing a particular parameter configuration onto the developer.
>>>>>>> Consider also the point of view of the developer implementing a 
>>>>>>> driver
>>>>>>> for
>>>>>>> some other piece of audio hardware that happens not to support
>>>>>>> precisely
>>>>>>> the same sample rates etc as VirtIO.  It would be extremely ugly to
>>>>>>> force
>>>>>>> all future hardware to pretend to have the same capabilities as 
>>>>>>> VirtIO
>>>>>>> just because the API was initially designed with VirtIO in mind.
>>>>>>>
>>>>>>> As a developer on the other side of the API, writing code to 
>>>>>>> play sound
>>>>>>> files on an arbitrary unknown platform, I would prefer to simply
>>>>>>> consume
>>>>>>> as simple as possible an abstraction of an audio output protocol and
>>>>>>> not
>>>>>>> have to care about what hardware is actually implementing it.
>>>>>>>
>>>>>> It may make sense to have an API to load the buffer/stream and 
>>>>>> other APIs
>>>>>> to
>>>>>> play or pause. This could allow an optional API to configure how the
>>>>>> stream
>>>>>> is played back. If we add a version to the Protocol that would at 
>>>>>> least
>>>>>> future proof us.
>>>>>>
>>>>>> We did get feedback that it is very common to speed up the auto 
>>>>>> playback
>>>>>> rates for accessibility. I’m not sure if that is practical with a 
>>>>>> simple
>>>>>> PCM
>>>>>> 16 wave file with the firmware audio implementation. I guess that is
>>>>>> something we could investigate.
>>>>>>
>>>>>> In terms of maybe adding text to speech there is an open source 
>>>>>> project
>>>>>> that
>>>>>> conceptually we could port to EFI. It would likely be a binary that
>>>>>> would
>>>>>> have to live on the EFI System Partition due to size. I was thinking
>>>>>> that
>>>>>> words per minute could be part of that API and it would produce a 
>>>>>> PCM 16
>>>>>> wave file that the audio protocol we are discussing could play.
>>>>>>
>>>>>>> Both of these argue in favour of defining a very simple API that
>>>>>>> expresses
>>>>>>> only a common baseline capability that is plausibly 
>>>>>>> implementable for
>>>>>>> every piece of audio hardware ever made.
>>>>>>>
>>>>>>> Coupled with the relatively minimalistic requirements for boot-time
>>>>>>> audio,
>>>>>>> I'd probably suggest supporting only a single format for audio data,
>>>>>>> with
>>>>>>> a fixed sample rate (and possibly only mono output).
>>>>>>>
>>>>>> In my world the folks that work for Jony asked for a stereo boot 
>>>>>> bong to
>>>>>> transition from left to right :). This is not the CODEC you are 
>>>>>> looking
>>>>>> for
>>>>>> was our response…. I also did not mention that some languages are 
>>>>>> right
>>>>>> to
>>>>>> left, as the only thing worse than one complex thing is two complex
>>>>>> things
>>>>>> to implement.
>>>>>>
>>>>>>> As always: perfection is achieved, not when there is nothing more to
>>>>>>> add,
>>>>>>> but when there is nothing left to take away.  :)
>>>>>>>
>>>>>> "Simplicity is the ultimate sophistication”
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Andrew Fish
>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Michael
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Signed,
>>>>> Ethin D. Probst
>>>>
>>>
>>
>>
>>
>
> 

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Andrew Fish]

> On Apr 16, 2021, at 4:34 AM, Leif Lindholm <leif@nuviainc.com> wrote:
> 
> Hi Ethin,
> 
> I think we also want to have a SetMode function, even if we don't get
> around to implement proper support for it as part of GSoC (although I
> expect at least for virtio, that should be pretty straightforward).
> 

Leif,

I’m think if we have an API to load the buffer and a 2nd API to play the buffer an optional 3rd API could configure the streams. 

> It's quite likely that speech for UI would be stored as 8kHz (or
> 20kHz) in some systems, whereas the example for playing a tune in GRUB
> would more likely be a 44.1 kHz mp3/wav/ogg/flac.
> 
> For the GSoC project, I think it would be quite reasonable to
> pre-generate pure PCM streams for testing rather than decoding
> anything on the fly.
> 
> Porting/writing decoders is really a separate task from enabling the
> output. I would much rather see USB *and* HDA support able to play pcm
> streams before worrying about decoding.
> 

I agree it might turn out it is easier to have the text to speech code just encode a PCM directly. 

Thanks,

Andrew Fish

> /
>    Leif
> 
> On Fri, Apr 16, 2021 at 00:33:06 -0500, Ethin Probst wrote:
>> Thanks for that explanation (I missed Mike's message). Earlier I sent
>> a summary of those things that we can agree on: mainly, that we have
>> mute, volume control, a load buffer, (maybe) an unload buffer, and a
>> start/stop stream function. Now that I fully understand the
>> ramifications of this I don't mind settling for a specific format and
>> sample rate, and signed 16-bit PCM audio is, I think, the most widely
>> used one out there, besides 64-bit floating point samples, which I've
>> only seen used in DAWs, and that's something we don't need.
>> Are you sure you want the firmware itself to handle the decoding of
>> WAV audio? I can make a library class for that, but I'll definitely
>> need help with the security aspect.
>> 
>> On 4/16/21, Andrew Fish via groups.io <afish=apple.com@groups.io> wrote:
>>> 
>>> 
>>>> On Apr 15, 2021, at 5:59 PM, Michael Brown <mcb30@ipxe.org> wrote:
>>>> 
>>>> On 16/04/2021 00:42, Ethin Probst wrote:
>>>>> Forcing a particular channel mapping, sample rate and sample format on
>>>>> everyone would complicate application code. From an application point
>>>>> of view, one would, with that type of protocol, need to do the
>>>>> following:
>>>>> 1) Load an audio file in any audio file format from any storage
>>>>> mechanism.
>>>>> 2) Decode the audio file format to extract the samples and audio
>>>>> metadata.
>>>>> 3) Resample the (now decoded) audio samples and convert (quantize) the
>>>>> audio samples into signed 16-bit PCM audio.
>>>>> 4) forward the samples onto the EFI audio protocol.
>>>> 
>>>> You have made an incorrect assumption that there exists a requirement to
>>>> be able to play audio files in arbitrary formats.  This requirement does
>>>> not exist.
>>>> 
>>>> With a protocol-mandated fixed baseline set of audio parameters (sample
>>>> rate etc), what would happen in practice is that the audio files would be
>>>> encoded in that format at *build* time, using tools entirely external to
>>>> UEFI.  The application code is then trivially simple: it just does "load
>>>> blob, pass blob to audio protocol".
>>>> 
>>> 
>>> 
>>> Ethin,
>>> 
>>> Given the goal is an industry standard we value interoperability more that
>>> flexibility.
>>> 
>>> How about another use case. Lets say the Linux OS loader (Grub) wants to
>>> have an accessible UI so it decides to sore sound files on the EFI System
>>> Partition and use our new fancy UEFI Audio Protocol to add audio to the OS
>>> loader GUI. So that version of Grub needs to work on 1,000 of different PCs
>>> and a wide range of UEFI Audio driver implementations. It is a much easier
>>> world if Wave PCM 16 bit just works every place. You could add a lot of
>>> complexity and try to encode the audio on the fly, maybe even in Linux
>>> proper but that falls down if you are booting from read only media like a
>>> DVD or backup tape (yes people still do that in server land).
>>> 
>>> The other problem with flexibility is you just made the test matrix very
>>> large for every driver that needs to get implemented. For something as
>>> complex as Intel HDA how you hook up the hardware and what CODECs you use
>>> may impact the quality of the playback for a given board. Your EFI is likely
>>> going to pick a single encoding at that will get tested all the time if your
>>> system has audio, but all 50 other things you support not so much. So that
>>> will required testing, and some one with audiophile ears (or an AI program)
>>> to test all the combinations. I’m not kidding I get BZs on the quality of
>>> the boot bong on our systems.
>>> 
>>> 
>>>>> typedef struct EFI_SIMPLE_AUDIO_PROTOCOL {
>>>>>  EFI_SIMPLE_AUDIO_PROTOCOL_RESET Reset;
>>>>>  EFI_SIMPLE_AUDIO_PROTOCOL_START Start;
>>>>>  EFI_SIMPLE_AUDIO_PROTOCOL_STOP Stop;
>>>>> } EFI_SIMPLE_AUDIO_PROTOCOL;
>>>> 
>>>> This is now starting to look like something that belongs in boot-time
>>>> firmware.  :)
>>>> 
>>> 
>>> I think that got a little too simple I’d go back and look at the example I
>>> posted to the thread but add an API to load the buffer, and then play the
>>> buffer (that way we can an API in the future to twiddle knobs). That API
>>> also implements the async EFI interface. Trust me the 1st thing that is
>>> going to happen when we add audio is some one is going to complain in xyz
>>> state we should mute audio, or we should honer audio volume and mute
>>> settings from setup, or from values set in the OS. Or some one is going to
>>> want the volume keys on the keyboard to work in EFI.
>>> 
>>> Also if you need to pick apart the Wave PCM 16 byte file to feed it into the
>>> audio hardware that probably means we should have a library that does that
>>> work, so other Audio drivers can share that code. Also having a library
>>> makes it easier to write a unit test. We need to be security conscious as we
>>> need to treat the Audo file as attacker controlled data.
>>> 
>>> Thanks,
>>> 
>>> Andrew Fish
>>> 
>>>> Michael
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> -- 
>> Signed,
>> Ethin D. Probst
> 
> 
> 
> 
> 

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Ethin Probst]

Yes, three APIs (maybe like this) would work well:
- Start, Stop: begin playback of a stream
- SetVolume, GetVolume, Mute, Unmute: control volume of output and enable muting
- CreateStream, ReleaseStream, SetStreamSampleRate: Control sample
rate of stream (but not sample format since Signed 16-bit PCM is
enough)
Marvin, how do you suggest we make the events then? We need some way
of notifying the caller that the stream has concluded. We could make
the driver create the event and pass it back to the caller as an
event, but you'd still have dangling pointers (this is C, after all).
We could just make a IsPlaying() function and WaitForCompletion()
function and allow the driver to do the event handling -- would that
work?

On 4/16/21, Andrew Fish <afish@apple.com> wrote:
>
>
>> On Apr 16, 2021, at 4:34 AM, Leif Lindholm <leif@nuviainc.com> wrote:
>>
>> Hi Ethin,
>>
>> I think we also want to have a SetMode function, even if we don't get
>> around to implement proper support for it as part of GSoC (although I
>> expect at least for virtio, that should be pretty straightforward).
>>
>
> Leif,
>
> I’m think if we have an API to load the buffer and a 2nd API to play the
> buffer an optional 3rd API could configure the streams.
>
>> It's quite likely that speech for UI would be stored as 8kHz (or
>> 20kHz) in some systems, whereas the example for playing a tune in GRUB
>> would more likely be a 44.1 kHz mp3/wav/ogg/flac.
>>
>> For the GSoC project, I think it would be quite reasonable to
>> pre-generate pure PCM streams for testing rather than decoding
>> anything on the fly.
>>
>> Porting/writing decoders is really a separate task from enabling the
>> output. I would much rather see USB *and* HDA support able to play pcm
>> streams before worrying about decoding.
>>
>
> I agree it might turn out it is easier to have the text to speech code just
> encode a PCM directly.
>
> Thanks,
>
> Andrew Fish
>
>> /
>>    Leif
>>
>> On Fri, Apr 16, 2021 at 00:33:06 -0500, Ethin Probst wrote:
>>> Thanks for that explanation (I missed Mike's message). Earlier I sent
>>> a summary of those things that we can agree on: mainly, that we have
>>> mute, volume control, a load buffer, (maybe) an unload buffer, and a
>>> start/stop stream function. Now that I fully understand the
>>> ramifications of this I don't mind settling for a specific format and
>>> sample rate, and signed 16-bit PCM audio is, I think, the most widely
>>> used one out there, besides 64-bit floating point samples, which I've
>>> only seen used in DAWs, and that's something we don't need.
>>> Are you sure you want the firmware itself to handle the decoding of
>>> WAV audio? I can make a library class for that, but I'll definitely
>>> need help with the security aspect.
>>>
>>> On 4/16/21, Andrew Fish via groups.io <afish=apple.com@groups.io> wrote:
>>>>
>>>>
>>>>> On Apr 15, 2021, at 5:59 PM, Michael Brown <mcb30@ipxe.org> wrote:
>>>>>
>>>>> On 16/04/2021 00:42, Ethin Probst wrote:
>>>>>> Forcing a particular channel mapping, sample rate and sample format
>>>>>> on
>>>>>> everyone would complicate application code. From an application point
>>>>>> of view, one would, with that type of protocol, need to do the
>>>>>> following:
>>>>>> 1) Load an audio file in any audio file format from any storage
>>>>>> mechanism.
>>>>>> 2) Decode the audio file format to extract the samples and audio
>>>>>> metadata.
>>>>>> 3) Resample the (now decoded) audio samples and convert (quantize)
>>>>>> the
>>>>>> audio samples into signed 16-bit PCM audio.
>>>>>> 4) forward the samples onto the EFI audio protocol.
>>>>>
>>>>> You have made an incorrect assumption that there exists a requirement
>>>>> to
>>>>> be able to play audio files in arbitrary formats.  This requirement
>>>>> does
>>>>> not exist.
>>>>>
>>>>> With a protocol-mandated fixed baseline set of audio parameters
>>>>> (sample
>>>>> rate etc), what would happen in practice is that the audio files would
>>>>> be
>>>>> encoded in that format at *build* time, using tools entirely external
>>>>> to
>>>>> UEFI.  The application code is then trivially simple: it just does
>>>>> "load
>>>>> blob, pass blob to audio protocol".
>>>>>
>>>>
>>>>
>>>> Ethin,
>>>>
>>>> Given the goal is an industry standard we value interoperability more
>>>> that
>>>> flexibility.
>>>>
>>>> How about another use case. Lets say the Linux OS loader (Grub) wants
>>>> to
>>>> have an accessible UI so it decides to sore sound files on the EFI
>>>> System
>>>> Partition and use our new fancy UEFI Audio Protocol to add audio to the
>>>> OS
>>>> loader GUI. So that version of Grub needs to work on 1,000 of different
>>>> PCs
>>>> and a wide range of UEFI Audio driver implementations. It is a much
>>>> easier
>>>> world if Wave PCM 16 bit just works every place. You could add a lot of
>>>> complexity and try to encode the audio on the fly, maybe even in Linux
>>>> proper but that falls down if you are booting from read only media like
>>>> a
>>>> DVD or backup tape (yes people still do that in server land).
>>>>
>>>> The other problem with flexibility is you just made the test matrix
>>>> very
>>>> large for every driver that needs to get implemented. For something as
>>>> complex as Intel HDA how you hook up the hardware and what CODECs you
>>>> use
>>>> may impact the quality of the playback for a given board. Your EFI is
>>>> likely
>>>> going to pick a single encoding at that will get tested all the time if
>>>> your
>>>> system has audio, but all 50 other things you support not so much. So
>>>> that
>>>> will required testing, and some one with audiophile ears (or an AI
>>>> program)
>>>> to test all the combinations. I’m not kidding I get BZs on the quality
>>>> of
>>>> the boot bong on our systems.
>>>>
>>>>
>>>>>> typedef struct EFI_SIMPLE_AUDIO_PROTOCOL {
>>>>>>  EFI_SIMPLE_AUDIO_PROTOCOL_RESET Reset;
>>>>>>  EFI_SIMPLE_AUDIO_PROTOCOL_START Start;
>>>>>>  EFI_SIMPLE_AUDIO_PROTOCOL_STOP Stop;
>>>>>> } EFI_SIMPLE_AUDIO_PROTOCOL;
>>>>>
>>>>> This is now starting to look like something that belongs in boot-time
>>>>> firmware.  :)
>>>>>
>>>>
>>>> I think that got a little too simple I’d go back and look at the example
>>>> I
>>>> posted to the thread but add an API to load the buffer, and then play
>>>> the
>>>> buffer (that way we can an API in the future to twiddle knobs). That
>>>> API
>>>> also implements the async EFI interface. Trust me the 1st thing that is
>>>> going to happen when we add audio is some one is going to complain in
>>>> xyz
>>>> state we should mute audio, or we should honer audio volume and mute
>>>> settings from setup, or from values set in the OS. Or some one is going
>>>> to
>>>> want the volume keys on the keyboard to work in EFI.
>>>>
>>>> Also if you need to pick apart the Wave PCM 16 byte file to feed it into
>>>> the
>>>> audio hardware that probably means we should have a library that does
>>>> that
>>>> work, so other Audio drivers can share that code. Also having a library
>>>> makes it easier to write a unit test. We need to be security conscious
>>>> as we
>>>> need to treat the Audo file as attacker controlled data.
>>>>
>>>> Thanks,
>>>>
>>>> Andrew Fish
>>>>
>>>>> Michael
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Signed,
>>> Ethin D. Probst
>>
>>
>> 
>>
>>
>
>


-- 
Signed,
Ethin D. Probst

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Ethin Probst]

Also, forgot to add this before sending: yes, speech synthesizers
usually generate the PCM audio on the fly. They can write it to an
output file, but if your just using it in a screen reader, then you
end up streaming it to the audio device. This raises another issue I
was pondering, but I (don't think) we need to handle that quite yet.
The problem involves output generated by the HII, console, etc.: when
we're using a speech synthesizer, it might be configured to speak at a
faster or slower rate depending on the preferences of the user (we
definitely want to let the user control these things because different
people have different preferences on the speed of speech synthesizers:
some can understand it at really fast rates and others can't, for
example). The problem arises when we want to forward output from the
screen (say, the simple text output protocol). Assume that a user is
running the EFI shell as an example, which, if I'm not mistaken, uses
this protocol. The shell calls
EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.OutputString(). We probably then want
this function to forward the string passed in onto the speech
synthesizer, assuming that accessibility features are enabled (I'm
assuming we'd want to make that a toggle). The problem is that one can
call EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.OutputString() many times. During
all these calls, text is being sent to the synthesizer, its generating
samples, and forwarding those samples onto the audio output protocol.
The problem is: how do we ensure that these samples don't overlap or
cause other problems (e.g.: interrupt streams that are still being
processed)? As I said, these are things we don't need to necessarily
consider now, but this is a problem we'll need to tackle in the
future.

On 4/16/21, Ethin Probst <harlydavidsen@gmail.com> wrote:
> Yes, three APIs (maybe like this) would work well:
> - Start, Stop: begin playback of a stream
> - SetVolume, GetVolume, Mute, Unmute: control volume of output and enable
> muting
> - CreateStream, ReleaseStream, SetStreamSampleRate: Control sample
> rate of stream (but not sample format since Signed 16-bit PCM is
> enough)
> Marvin, how do you suggest we make the events then? We need some way
> of notifying the caller that the stream has concluded. We could make
> the driver create the event and pass it back to the caller as an
> event, but you'd still have dangling pointers (this is C, after all).
> We could just make a IsPlaying() function and WaitForCompletion()
> function and allow the driver to do the event handling -- would that
> work?
>
> On 4/16/21, Andrew Fish <afish@apple.com> wrote:
>>
>>
>>> On Apr 16, 2021, at 4:34 AM, Leif Lindholm <leif@nuviainc.com> wrote:
>>>
>>> Hi Ethin,
>>>
>>> I think we also want to have a SetMode function, even if we don't get
>>> around to implement proper support for it as part of GSoC (although I
>>> expect at least for virtio, that should be pretty straightforward).
>>>
>>
>> Leif,
>>
>> I’m think if we have an API to load the buffer and a 2nd API to play the
>> buffer an optional 3rd API could configure the streams.
>>
>>> It's quite likely that speech for UI would be stored as 8kHz (or
>>> 20kHz) in some systems, whereas the example for playing a tune in GRUB
>>> would more likely be a 44.1 kHz mp3/wav/ogg/flac.
>>>
>>> For the GSoC project, I think it would be quite reasonable to
>>> pre-generate pure PCM streams for testing rather than decoding
>>> anything on the fly.
>>>
>>> Porting/writing decoders is really a separate task from enabling the
>>> output. I would much rather see USB *and* HDA support able to play pcm
>>> streams before worrying about decoding.
>>>
>>
>> I agree it might turn out it is easier to have the text to speech code
>> just
>> encode a PCM directly.
>>
>> Thanks,
>>
>> Andrew Fish
>>
>>> /
>>>    Leif
>>>
>>> On Fri, Apr 16, 2021 at 00:33:06 -0500, Ethin Probst wrote:
>>>> Thanks for that explanation (I missed Mike's message). Earlier I sent
>>>> a summary of those things that we can agree on: mainly, that we have
>>>> mute, volume control, a load buffer, (maybe) an unload buffer, and a
>>>> start/stop stream function. Now that I fully understand the
>>>> ramifications of this I don't mind settling for a specific format and
>>>> sample rate, and signed 16-bit PCM audio is, I think, the most widely
>>>> used one out there, besides 64-bit floating point samples, which I've
>>>> only seen used in DAWs, and that's something we don't need.
>>>> Are you sure you want the firmware itself to handle the decoding of
>>>> WAV audio? I can make a library class for that, but I'll definitely
>>>> need help with the security aspect.
>>>>
>>>> On 4/16/21, Andrew Fish via groups.io <afish=apple.com@groups.io>
>>>> wrote:
>>>>>
>>>>>
>>>>>> On Apr 15, 2021, at 5:59 PM, Michael Brown <mcb30@ipxe.org> wrote:
>>>>>>
>>>>>> On 16/04/2021 00:42, Ethin Probst wrote:
>>>>>>> Forcing a particular channel mapping, sample rate and sample format
>>>>>>> on
>>>>>>> everyone would complicate application code. From an application
>>>>>>> point
>>>>>>> of view, one would, with that type of protocol, need to do the
>>>>>>> following:
>>>>>>> 1) Load an audio file in any audio file format from any storage
>>>>>>> mechanism.
>>>>>>> 2) Decode the audio file format to extract the samples and audio
>>>>>>> metadata.
>>>>>>> 3) Resample the (now decoded) audio samples and convert (quantize)
>>>>>>> the
>>>>>>> audio samples into signed 16-bit PCM audio.
>>>>>>> 4) forward the samples onto the EFI audio protocol.
>>>>>>
>>>>>> You have made an incorrect assumption that there exists a requirement
>>>>>> to
>>>>>> be able to play audio files in arbitrary formats.  This requirement
>>>>>> does
>>>>>> not exist.
>>>>>>
>>>>>> With a protocol-mandated fixed baseline set of audio parameters
>>>>>> (sample
>>>>>> rate etc), what would happen in practice is that the audio files
>>>>>> would
>>>>>> be
>>>>>> encoded in that format at *build* time, using tools entirely external
>>>>>> to
>>>>>> UEFI.  The application code is then trivially simple: it just does
>>>>>> "load
>>>>>> blob, pass blob to audio protocol".
>>>>>>
>>>>>
>>>>>
>>>>> Ethin,
>>>>>
>>>>> Given the goal is an industry standard we value interoperability more
>>>>> that
>>>>> flexibility.
>>>>>
>>>>> How about another use case. Lets say the Linux OS loader (Grub) wants
>>>>> to
>>>>> have an accessible UI so it decides to sore sound files on the EFI
>>>>> System
>>>>> Partition and use our new fancy UEFI Audio Protocol to add audio to
>>>>> the
>>>>> OS
>>>>> loader GUI. So that version of Grub needs to work on 1,000 of
>>>>> different
>>>>> PCs
>>>>> and a wide range of UEFI Audio driver implementations. It is a much
>>>>> easier
>>>>> world if Wave PCM 16 bit just works every place. You could add a lot
>>>>> of
>>>>> complexity and try to encode the audio on the fly, maybe even in Linux
>>>>> proper but that falls down if you are booting from read only media
>>>>> like
>>>>> a
>>>>> DVD or backup tape (yes people still do that in server land).
>>>>>
>>>>> The other problem with flexibility is you just made the test matrix
>>>>> very
>>>>> large for every driver that needs to get implemented. For something as
>>>>> complex as Intel HDA how you hook up the hardware and what CODECs you
>>>>> use
>>>>> may impact the quality of the playback for a given board. Your EFI is
>>>>> likely
>>>>> going to pick a single encoding at that will get tested all the time
>>>>> if
>>>>> your
>>>>> system has audio, but all 50 other things you support not so much. So
>>>>> that
>>>>> will required testing, and some one with audiophile ears (or an AI
>>>>> program)
>>>>> to test all the combinations. I’m not kidding I get BZs on the quality
>>>>> of
>>>>> the boot bong on our systems.
>>>>>
>>>>>
>>>>>>> typedef struct EFI_SIMPLE_AUDIO_PROTOCOL {
>>>>>>>  EFI_SIMPLE_AUDIO_PROTOCOL_RESET Reset;
>>>>>>>  EFI_SIMPLE_AUDIO_PROTOCOL_START Start;
>>>>>>>  EFI_SIMPLE_AUDIO_PROTOCOL_STOP Stop;
>>>>>>> } EFI_SIMPLE_AUDIO_PROTOCOL;
>>>>>>
>>>>>> This is now starting to look like something that belongs in boot-time
>>>>>> firmware.  :)
>>>>>>
>>>>>
>>>>> I think that got a little too simple I’d go back and look at the
>>>>> example
>>>>> I
>>>>> posted to the thread but add an API to load the buffer, and then play
>>>>> the
>>>>> buffer (that way we can an API in the future to twiddle knobs). That
>>>>> API
>>>>> also implements the async EFI interface. Trust me the 1st thing that
>>>>> is
>>>>> going to happen when we add audio is some one is going to complain in
>>>>> xyz
>>>>> state we should mute audio, or we should honer audio volume and mute
>>>>> settings from setup, or from values set in the OS. Or some one is
>>>>> going
>>>>> to
>>>>> want the volume keys on the keyboard to work in EFI.
>>>>>
>>>>> Also if you need to pick apart the Wave PCM 16 byte file to feed it
>>>>> into
>>>>> the
>>>>> audio hardware that probably means we should have a library that does
>>>>> that
>>>>> work, so other Audio drivers can share that code. Also having a
>>>>> library
>>>>> makes it easier to write a unit test. We need to be security conscious
>>>>> as we
>>>>> need to treat the Audo file as attacker controlled data.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Andrew Fish
>>>>>
>>>>>> Michael
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Signed,
>>>> Ethin D. Probst
>>>
>>>
>>> 
>>>
>>>
>>
>>
>
>
> --
> Signed,
> Ethin D. Probst
>


-- 
Signed,
Ethin D. Probst

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Andrew Fish]

[-- Attachment #1: Type: text/plain, Size: 9972 bytes --]



> On Apr 16, 2021, at 10:45 AM, Ethin Probst <harlydavidsen@gmail.com> wrote:
> 
> Yes, three APIs (maybe like this) would work well:
> - Start, Stop: begin playback of a stream
> - SetVolume, GetVolume, Mute, Unmute: control volume of output and enable muting
> - CreateStream, ReleaseStream, SetStreamSampleRate: Control sample
> rate of stream (but not sample format since Signed 16-bit PCM is
> enough)
> Marvin, how do you suggest we make the events then? We need some way
> of notifying the caller that the stream has concluded. We could make
> the driver create the event and pass it back to the caller as an
> event, but you'd still have dangling pointers (this is C, after all).
> We could just make a IsPlaying() function and WaitForCompletion()
> function and allow the driver to do the event handling -- would that
> work?
> 

Ethin,

I can adapt my example from earlier in the thread for how to do async EFI APIs. 

/**
  The struct of Audio Token.
**/
typedef struct {

  ///
  /// Event will be signaled when the read audo has been played.
  /// If only synchronous playback is supported the Event must still get signaled. 
  ///
  EFI_EVENT               Event;

  ///
  /// Defines whether or not the signaled event encountered an error.
  ///
  EFI_STATUS              TransactionStatus;
} CODE_FIRST_HDA_AUDIO_TOKEN;

/**
  Play synchronous or asynchronous audio. If Token is passed in the audio is played
  asynchronously, if Token is NULL then this call blocks until the Audio is complete. 

  @param[in]      This         A pointer to the CODE_FIRST_HDA_AUDIO_PROTOCOL instance.
  @param[in, out] Token        A pointer to the token associated with the transaction.
                               If NULL this functions blocks until audio play back is complete.

  @retval EFI_SUCCESS           The audio started playing. 
  @retval EFI_OUT_OF_RESOURCES  The request could not be completed due to a lack of resources.
  @retval EFI_INVALID_PARAMETER One or more parameters are invalid.

**/
typedef
EFI_STATUS
(EFIAPI *CODE_FIRST_HDA_AUDIO_PROTOCOL_PLAY_STREAM)(
  IN     CODE_FIRST_HDA_AUDIO_PROTOCOL   *This,
  IN OUT CODE_FIRST_HDA_AUDIO_TOKEN      *Token     OPTIONAL
  );


You can fake out the asynchronous interface in your synchronous flow by ….


if (Token != NULL) {
  Token->TransactionStatus = Status;  // return value from sync call
  gBS->SignalEvent (Token->Event);
}

This just gives the caller the experience that the event was signaled before the call returned, which is legal for an async API. 

The caller allocates a CODE_FIRST_HDA_AUDIO_TOKEN and creates an Event that has an associated callback function. Then calls gAudio->PlayStream (gAudio, Token); and the callers callback function fires when the audio stream completes. 

Thanks,

Andrew Fish

> On 4/16/21, Andrew Fish <afish@apple.com> wrote:
>> 
>> 
>>> On Apr 16, 2021, at 4:34 AM, Leif Lindholm <leif@nuviainc.com> wrote:
>>> 
>>> Hi Ethin,
>>> 
>>> I think we also want to have a SetMode function, even if we don't get
>>> around to implement proper support for it as part of GSoC (although I
>>> expect at least for virtio, that should be pretty straightforward).
>>> 
>> 
>> Leif,
>> 
>> I’m think if we have an API to load the buffer and a 2nd API to play the
>> buffer an optional 3rd API could configure the streams.
>> 
>>> It's quite likely that speech for UI would be stored as 8kHz (or
>>> 20kHz) in some systems, whereas the example for playing a tune in GRUB
>>> would more likely be a 44.1 kHz mp3/wav/ogg/flac.
>>> 
>>> For the GSoC project, I think it would be quite reasonable to
>>> pre-generate pure PCM streams for testing rather than decoding
>>> anything on the fly.
>>> 
>>> Porting/writing decoders is really a separate task from enabling the
>>> output. I would much rather see USB *and* HDA support able to play pcm
>>> streams before worrying about decoding.
>>> 
>> 
>> I agree it might turn out it is easier to have the text to speech code just
>> encode a PCM directly.
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
>>> /
>>>   Leif
>>> 
>>> On Fri, Apr 16, 2021 at 00:33:06 -0500, Ethin Probst wrote:
>>>> Thanks for that explanation (I missed Mike's message). Earlier I sent
>>>> a summary of those things that we can agree on: mainly, that we have
>>>> mute, volume control, a load buffer, (maybe) an unload buffer, and a
>>>> start/stop stream function. Now that I fully understand the
>>>> ramifications of this I don't mind settling for a specific format and
>>>> sample rate, and signed 16-bit PCM audio is, I think, the most widely
>>>> used one out there, besides 64-bit floating point samples, which I've
>>>> only seen used in DAWs, and that's something we don't need.
>>>> Are you sure you want the firmware itself to handle the decoding of
>>>> WAV audio? I can make a library class for that, but I'll definitely
>>>> need help with the security aspect.
>>>> 
>>>> On 4/16/21, Andrew Fish via groups.io <afish=apple.com@groups.io> wrote:
>>>>> 
>>>>> 
>>>>>> On Apr 15, 2021, at 5:59 PM, Michael Brown <mcb30@ipxe.org> wrote:
>>>>>> 
>>>>>> On 16/04/2021 00:42, Ethin Probst wrote:
>>>>>>> Forcing a particular channel mapping, sample rate and sample format
>>>>>>> on
>>>>>>> everyone would complicate application code. From an application point
>>>>>>> of view, one would, with that type of protocol, need to do the
>>>>>>> following:
>>>>>>> 1) Load an audio file in any audio file format from any storage
>>>>>>> mechanism.
>>>>>>> 2) Decode the audio file format to extract the samples and audio
>>>>>>> metadata.
>>>>>>> 3) Resample the (now decoded) audio samples and convert (quantize)
>>>>>>> the
>>>>>>> audio samples into signed 16-bit PCM audio.
>>>>>>> 4) forward the samples onto the EFI audio protocol.
>>>>>> 
>>>>>> You have made an incorrect assumption that there exists a requirement
>>>>>> to
>>>>>> be able to play audio files in arbitrary formats.  This requirement
>>>>>> does
>>>>>> not exist.
>>>>>> 
>>>>>> With a protocol-mandated fixed baseline set of audio parameters
>>>>>> (sample
>>>>>> rate etc), what would happen in practice is that the audio files would
>>>>>> be
>>>>>> encoded in that format at *build* time, using tools entirely external
>>>>>> to
>>>>>> UEFI.  The application code is then trivially simple: it just does
>>>>>> "load
>>>>>> blob, pass blob to audio protocol".
>>>>>> 
>>>>> 
>>>>> 
>>>>> Ethin,
>>>>> 
>>>>> Given the goal is an industry standard we value interoperability more
>>>>> that
>>>>> flexibility.
>>>>> 
>>>>> How about another use case. Lets say the Linux OS loader (Grub) wants
>>>>> to
>>>>> have an accessible UI so it decides to sore sound files on the EFI
>>>>> System
>>>>> Partition and use our new fancy UEFI Audio Protocol to add audio to the
>>>>> OS
>>>>> loader GUI. So that version of Grub needs to work on 1,000 of different
>>>>> PCs
>>>>> and a wide range of UEFI Audio driver implementations. It is a much
>>>>> easier
>>>>> world if Wave PCM 16 bit just works every place. You could add a lot of
>>>>> complexity and try to encode the audio on the fly, maybe even in Linux
>>>>> proper but that falls down if you are booting from read only media like
>>>>> a
>>>>> DVD or backup tape (yes people still do that in server land).
>>>>> 
>>>>> The other problem with flexibility is you just made the test matrix
>>>>> very
>>>>> large for every driver that needs to get implemented. For something as
>>>>> complex as Intel HDA how you hook up the hardware and what CODECs you
>>>>> use
>>>>> may impact the quality of the playback for a given board. Your EFI is
>>>>> likely
>>>>> going to pick a single encoding at that will get tested all the time if
>>>>> your
>>>>> system has audio, but all 50 other things you support not so much. So
>>>>> that
>>>>> will required testing, and some one with audiophile ears (or an AI
>>>>> program)
>>>>> to test all the combinations. I’m not kidding I get BZs on the quality
>>>>> of
>>>>> the boot bong on our systems.
>>>>> 
>>>>> 
>>>>>>> typedef struct EFI_SIMPLE_AUDIO_PROTOCOL {
>>>>>>> EFI_SIMPLE_AUDIO_PROTOCOL_RESET Reset;
>>>>>>> EFI_SIMPLE_AUDIO_PROTOCOL_START Start;
>>>>>>> EFI_SIMPLE_AUDIO_PROTOCOL_STOP Stop;
>>>>>>> } EFI_SIMPLE_AUDIO_PROTOCOL;
>>>>>> 
>>>>>> This is now starting to look like something that belongs in boot-time
>>>>>> firmware.  :)
>>>>>> 
>>>>> 
>>>>> I think that got a little too simple I’d go back and look at the example
>>>>> I
>>>>> posted to the thread but add an API to load the buffer, and then play
>>>>> the
>>>>> buffer (that way we can an API in the future to twiddle knobs). That
>>>>> API
>>>>> also implements the async EFI interface. Trust me the 1st thing that is
>>>>> going to happen when we add audio is some one is going to complain in
>>>>> xyz
>>>>> state we should mute audio, or we should honer audio volume and mute
>>>>> settings from setup, or from values set in the OS. Or some one is going
>>>>> to
>>>>> want the volume keys on the keyboard to work in EFI.
>>>>> 
>>>>> Also if you need to pick apart the Wave PCM 16 byte file to feed it into
>>>>> the
>>>>> audio hardware that probably means we should have a library that does
>>>>> that
>>>>> work, so other Audio drivers can share that code. Also having a library
>>>>> makes it easier to write a unit test. We need to be security conscious
>>>>> as we
>>>>> need to treat the Audo file as attacker controlled data.
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> Andrew Fish
>>>>> 
>>>>>> Michael
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> Signed,
>>>> Ethin D. Probst
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 
> 
> -- 
> Signed,
> Ethin D. Probst


[-- Attachment #2: Type: text/html, Size: 17124 bytes --]

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Andrew Fish]

> On Apr 16, 2021, at 10:55 AM, Ethin Probst <harlydavidsen@gmail.com> wrote:
> 
> Also, forgot to add this before sending: yes, speech synthesizers
> usually generate the PCM audio on the fly. They can write it to an
> output file, but if your just using it in a screen reader, then you
> end up streaming it to the audio device. This raises another issue I
> was pondering, but I (don't think) we need to handle that quite yet.
> The problem involves output generated by the HII, console, etc.: when
> we're using a speech synthesizer, it might be configured to speak at a
> faster or slower rate depending on the preferences of the user (we
> definitely want to let the user control these things because different
> people have different preferences on the speed of speech synthesizers:
> some can understand it at really fast rates and others can't, for
> example). The problem arises when we want to forward output from the
> screen (say, the simple text output protocol). Assume that a user is
> running the EFI shell as an example, which, if I'm not mistaken, uses
> this protocol. The shell calls
> EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.OutputString(). We probably then want
> this function to forward the string passed in onto the speech
> synthesizer, assuming that accessibility features are enabled (I'm
> assuming we'd want to make that a toggle). The problem is that one can
> call EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.OutputString() many times. During
> all these calls, text is being sent to the synthesizer, its generating
> samples, and forwarding those samples onto the audio output protocol.
> The problem is: how do we ensure that these samples don't overlap or
> cause other problems (e.g.: interrupt streams that are still being
> processed)? As I said, these are things we don't need to necessarily
> consider now, but this is a problem we'll need to tackle in the
> future.
> 

I’m not sure converting EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL to audio directly would work from a practical point of view. If you look at the Hii based setup and lot of text and a lot of text based graphics characters get dumped into a screen with not particular order. For the UEFI Shell there is a lot of cursor control and the prompt could get redrawn at arbitrary times. Not sure how well that maps to pure text to speech. Also in a text based GUI you are just changing the attributes of what is selected as you redraw it. Thus for Hii I was thinking it may make more sense to just have the Hii forms browser pick the spots to do text to speech. 

I’ve also thought about mechanisms that would let the OS encode auto associated with the boot options so the Hii UI could use that. But I’m guessing speak on select in the UI might be more useful than raw EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL to text. You can always chose to make the Audio playback synchronous, or block certain UI progress on audio completion. 

Thanks,

Andrew Fish

PS The edk2 has a ConSpliter so adding and extra EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL would be easy, I’m just not sure it would work out well. 

> On 4/16/21, Ethin Probst <harlydavidsen@gmail.com> wrote:
>> Yes, three APIs (maybe like this) would work well:
>> - Start, Stop: begin playback of a stream
>> - SetVolume, GetVolume, Mute, Unmute: control volume of output and enable
>> muting
>> - CreateStream, ReleaseStream, SetStreamSampleRate: Control sample
>> rate of stream (but not sample format since Signed 16-bit PCM is
>> enough)
>> Marvin, how do you suggest we make the events then? We need some way
>> of notifying the caller that the stream has concluded. We could make
>> the driver create the event and pass it back to the caller as an
>> event, but you'd still have dangling pointers (this is C, after all).
>> We could just make a IsPlaying() function and WaitForCompletion()
>> function and allow the driver to do the event handling -- would that
>> work?
>> 
>> On 4/16/21, Andrew Fish <afish@apple.com> wrote:
>>> 
>>> 
>>>> On Apr 16, 2021, at 4:34 AM, Leif Lindholm <leif@nuviainc.com> wrote:
>>>> 
>>>> Hi Ethin,
>>>> 
>>>> I think we also want to have a SetMode function, even if we don't get
>>>> around to implement proper support for it as part of GSoC (although I
>>>> expect at least for virtio, that should be pretty straightforward).
>>>> 
>>> 
>>> Leif,
>>> 
>>> I’m think if we have an API to load the buffer and a 2nd API to play the
>>> buffer an optional 3rd API could configure the streams.
>>> 
>>>> It's quite likely that speech for UI would be stored as 8kHz (or
>>>> 20kHz) in some systems, whereas the example for playing a tune in GRUB
>>>> would more likely be a 44.1 kHz mp3/wav/ogg/flac.
>>>> 
>>>> For the GSoC project, I think it would be quite reasonable to
>>>> pre-generate pure PCM streams for testing rather than decoding
>>>> anything on the fly.
>>>> 
>>>> Porting/writing decoders is really a separate task from enabling the
>>>> output. I would much rather see USB *and* HDA support able to play pcm
>>>> streams before worrying about decoding.
>>>> 
>>> 
>>> I agree it might turn out it is easier to have the text to speech code
>>> just
>>> encode a PCM directly.
>>> 
>>> Thanks,
>>> 
>>> Andrew Fish
>>> 
>>>> /
>>>>   Leif
>>>> 
>>>> On Fri, Apr 16, 2021 at 00:33:06 -0500, Ethin Probst wrote:
>>>>> Thanks for that explanation (I missed Mike's message). Earlier I sent
>>>>> a summary of those things that we can agree on: mainly, that we have
>>>>> mute, volume control, a load buffer, (maybe) an unload buffer, and a
>>>>> start/stop stream function. Now that I fully understand the
>>>>> ramifications of this I don't mind settling for a specific format and
>>>>> sample rate, and signed 16-bit PCM audio is, I think, the most widely
>>>>> used one out there, besides 64-bit floating point samples, which I've
>>>>> only seen used in DAWs, and that's something we don't need.
>>>>> Are you sure you want the firmware itself to handle the decoding of
>>>>> WAV audio? I can make a library class for that, but I'll definitely
>>>>> need help with the security aspect.
>>>>> 
>>>>> On 4/16/21, Andrew Fish via groups.io <afish=apple.com@groups.io>
>>>>> wrote:
>>>>>> 
>>>>>> 
>>>>>>> On Apr 15, 2021, at 5:59 PM, Michael Brown <mcb30@ipxe.org> wrote:
>>>>>>> 
>>>>>>> On 16/04/2021 00:42, Ethin Probst wrote:
>>>>>>>> Forcing a particular channel mapping, sample rate and sample format
>>>>>>>> on
>>>>>>>> everyone would complicate application code. From an application
>>>>>>>> point
>>>>>>>> of view, one would, with that type of protocol, need to do the
>>>>>>>> following:
>>>>>>>> 1) Load an audio file in any audio file format from any storage
>>>>>>>> mechanism.
>>>>>>>> 2) Decode the audio file format to extract the samples and audio
>>>>>>>> metadata.
>>>>>>>> 3) Resample the (now decoded) audio samples and convert (quantize)
>>>>>>>> the
>>>>>>>> audio samples into signed 16-bit PCM audio.
>>>>>>>> 4) forward the samples onto the EFI audio protocol.
>>>>>>> 
>>>>>>> You have made an incorrect assumption that there exists a requirement
>>>>>>> to
>>>>>>> be able to play audio files in arbitrary formats.  This requirement
>>>>>>> does
>>>>>>> not exist.
>>>>>>> 
>>>>>>> With a protocol-mandated fixed baseline set of audio parameters
>>>>>>> (sample
>>>>>>> rate etc), what would happen in practice is that the audio files
>>>>>>> would
>>>>>>> be
>>>>>>> encoded in that format at *build* time, using tools entirely external
>>>>>>> to
>>>>>>> UEFI.  The application code is then trivially simple: it just does
>>>>>>> "load
>>>>>>> blob, pass blob to audio protocol".
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Ethin,
>>>>>> 
>>>>>> Given the goal is an industry standard we value interoperability more
>>>>>> that
>>>>>> flexibility.
>>>>>> 
>>>>>> How about another use case. Lets say the Linux OS loader (Grub) wants
>>>>>> to
>>>>>> have an accessible UI so it decides to sore sound files on the EFI
>>>>>> System
>>>>>> Partition and use our new fancy UEFI Audio Protocol to add audio to
>>>>>> the
>>>>>> OS
>>>>>> loader GUI. So that version of Grub needs to work on 1,000 of
>>>>>> different
>>>>>> PCs
>>>>>> and a wide range of UEFI Audio driver implementations. It is a much
>>>>>> easier
>>>>>> world if Wave PCM 16 bit just works every place. You could add a lot
>>>>>> of
>>>>>> complexity and try to encode the audio on the fly, maybe even in Linux
>>>>>> proper but that falls down if you are booting from read only media
>>>>>> like
>>>>>> a
>>>>>> DVD or backup tape (yes people still do that in server land).
>>>>>> 
>>>>>> The other problem with flexibility is you just made the test matrix
>>>>>> very
>>>>>> large for every driver that needs to get implemented. For something as
>>>>>> complex as Intel HDA how you hook up the hardware and what CODECs you
>>>>>> use
>>>>>> may impact the quality of the playback for a given board. Your EFI is
>>>>>> likely
>>>>>> going to pick a single encoding at that will get tested all the time
>>>>>> if
>>>>>> your
>>>>>> system has audio, but all 50 other things you support not so much. So
>>>>>> that
>>>>>> will required testing, and some one with audiophile ears (or an AI
>>>>>> program)
>>>>>> to test all the combinations. I’m not kidding I get BZs on the quality
>>>>>> of
>>>>>> the boot bong on our systems.
>>>>>> 
>>>>>> 
>>>>>>>> typedef struct EFI_SIMPLE_AUDIO_PROTOCOL {
>>>>>>>> EFI_SIMPLE_AUDIO_PROTOCOL_RESET Reset;
>>>>>>>> EFI_SIMPLE_AUDIO_PROTOCOL_START Start;
>>>>>>>> EFI_SIMPLE_AUDIO_PROTOCOL_STOP Stop;
>>>>>>>> } EFI_SIMPLE_AUDIO_PROTOCOL;
>>>>>>> 
>>>>>>> This is now starting to look like something that belongs in boot-time
>>>>>>> firmware.  :)
>>>>>>> 
>>>>>> 
>>>>>> I think that got a little too simple I’d go back and look at the
>>>>>> example
>>>>>> I
>>>>>> posted to the thread but add an API to load the buffer, and then play
>>>>>> the
>>>>>> buffer (that way we can an API in the future to twiddle knobs). That
>>>>>> API
>>>>>> also implements the async EFI interface. Trust me the 1st thing that
>>>>>> is
>>>>>> going to happen when we add audio is some one is going to complain in
>>>>>> xyz
>>>>>> state we should mute audio, or we should honer audio volume and mute
>>>>>> settings from setup, or from values set in the OS. Or some one is
>>>>>> going
>>>>>> to
>>>>>> want the volume keys on the keyboard to work in EFI.
>>>>>> 
>>>>>> Also if you need to pick apart the Wave PCM 16 byte file to feed it
>>>>>> into
>>>>>> the
>>>>>> audio hardware that probably means we should have a library that does
>>>>>> that
>>>>>> work, so other Audio drivers can share that code. Also having a
>>>>>> library
>>>>>> makes it easier to write a unit test. We need to be security conscious
>>>>>> as we
>>>>>> need to treat the Audo file as attacker controlled data.
>>>>>> 
>>>>>> Thanks,
>>>>>> 
>>>>>> Andrew Fish
>>>>>> 
>>>>>>> Michael
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Signed,
>>>>> Ethin D. Probst
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
>> --
>> Signed,
>> Ethin D. Probst
>> 
> 
> 
> -- 
> Signed,
> Ethin D. Probst
> 
> 
> 
> 
> 

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Ethin Probst]

Andrew,
Thanks for that example -- that makes things a lot easier to
understand now. I think, anyway. As for the simple text output
protocol, I was just using that as an example; I understand that the
HII infrastructure draws graphical characters, as does the simple text
output protocol, and the screen is redrawn quite often. I was just
using that as an example of the problems that we might face. I'd
prefer that the protocols themselves be made accessible instead of
requiring applications to do it; the advantage would be that very
little work, if any, would need to be done to make an application
accessible, and nothing would necessarily need to be rebuilt for
accessibility to be implemented. All someone would have to do is
update the firmware, enable accessibility features, and they
immediately get an accessible user interface, with no changes required
to user-facing applications such as bootloaders, secure boot
utilities, shells, and setup utilities. But that's a long way off, and
for now, we should focus primarily on the audio output protocol
instead of focusing on details that are still abstract.
Is the audio interface I proposed in a couple emails previously
sufficient and something that we can all agree on? We might also want
a GetVersion() function to return the revision number so that users of
it know what revision they're working with in case we decide to add
functions to it later on.
As always, I've updated my gist, and as before, the new version can be
found here: https://gist.github.com/ethindp/56066e0561b901c1e276e82ff469436d

On 4/16/21, Andrew Fish <afish@apple.com> wrote:
>
>
>> On Apr 16, 2021, at 10:55 AM, Ethin Probst <harlydavidsen@gmail.com>
>> wrote:
>>
>> Also, forgot to add this before sending: yes, speech synthesizers
>> usually generate the PCM audio on the fly. They can write it to an
>> output file, but if your just using it in a screen reader, then you
>> end up streaming it to the audio device. This raises another issue I
>> was pondering, but I (don't think) we need to handle that quite yet.
>> The problem involves output generated by the HII, console, etc.: when
>> we're using a speech synthesizer, it might be configured to speak at a
>> faster or slower rate depending on the preferences of the user (we
>> definitely want to let the user control these things because different
>> people have different preferences on the speed of speech synthesizers:
>> some can understand it at really fast rates and others can't, for
>> example). The problem arises when we want to forward output from the
>> screen (say, the simple text output protocol). Assume that a user is
>> running the EFI shell as an example, which, if I'm not mistaken, uses
>> this protocol. The shell calls
>> EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.OutputString(). We probably then want
>> this function to forward the string passed in onto the speech
>> synthesizer, assuming that accessibility features are enabled (I'm
>> assuming we'd want to make that a toggle). The problem is that one can
>> call EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.OutputString() many times. During
>> all these calls, text is being sent to the synthesizer, its generating
>> samples, and forwarding those samples onto the audio output protocol.
>> The problem is: how do we ensure that these samples don't overlap or
>> cause other problems (e.g.: interrupt streams that are still being
>> processed)? As I said, these are things we don't need to necessarily
>> consider now, but this is a problem we'll need to tackle in the
>> future.
>>
>
> I’m not sure converting EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL to audio directly
> would work from a practical point of view. If you look at the Hii based
> setup and lot of text and a lot of text based graphics characters get dumped
> into a screen with not particular order. For the UEFI Shell there is a lot
> of cursor control and the prompt could get redrawn at arbitrary times. Not
> sure how well that maps to pure text to speech. Also in a text based GUI you
> are just changing the attributes of what is selected as you redraw it. Thus
> for Hii I was thinking it may make more sense to just have the Hii forms
> browser pick the spots to do text to speech.
>
> I’ve also thought about mechanisms that would let the OS encode auto
> associated with the boot options so the Hii UI could use that. But I’m
> guessing speak on select in the UI might be more useful than raw
> EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL to text. You can always chose to make the
> Audio playback synchronous, or block certain UI progress on audio
> completion.
>
> Thanks,
>
> Andrew Fish
>
> PS The edk2 has a ConSpliter so adding and extra
> EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL would be easy, I’m just not sure it would
> work out well.
>
>> On 4/16/21, Ethin Probst <harlydavidsen@gmail.com> wrote:
>>> Yes, three APIs (maybe like this) would work well:
>>> - Start, Stop: begin playback of a stream
>>> - SetVolume, GetVolume, Mute, Unmute: control volume of output and
>>> enable
>>> muting
>>> - CreateStream, ReleaseStream, SetStreamSampleRate: Control sample
>>> rate of stream (but not sample format since Signed 16-bit PCM is
>>> enough)
>>> Marvin, how do you suggest we make the events then? We need some way
>>> of notifying the caller that the stream has concluded. We could make
>>> the driver create the event and pass it back to the caller as an
>>> event, but you'd still have dangling pointers (this is C, after all).
>>> We could just make a IsPlaying() function and WaitForCompletion()
>>> function and allow the driver to do the event handling -- would that
>>> work?
>>>
>>> On 4/16/21, Andrew Fish <afish@apple.com> wrote:
>>>>
>>>>
>>>>> On Apr 16, 2021, at 4:34 AM, Leif Lindholm <leif@nuviainc.com> wrote:
>>>>>
>>>>> Hi Ethin,
>>>>>
>>>>> I think we also want to have a SetMode function, even if we don't get
>>>>> around to implement proper support for it as part of GSoC (although I
>>>>> expect at least for virtio, that should be pretty straightforward).
>>>>>
>>>>
>>>> Leif,
>>>>
>>>> I’m think if we have an API to load the buffer and a 2nd API to play
>>>> the
>>>> buffer an optional 3rd API could configure the streams.
>>>>
>>>>> It's quite likely that speech for UI would be stored as 8kHz (or
>>>>> 20kHz) in some systems, whereas the example for playing a tune in GRUB
>>>>> would more likely be a 44.1 kHz mp3/wav/ogg/flac.
>>>>>
>>>>> For the GSoC project, I think it would be quite reasonable to
>>>>> pre-generate pure PCM streams for testing rather than decoding
>>>>> anything on the fly.
>>>>>
>>>>> Porting/writing decoders is really a separate task from enabling the
>>>>> output. I would much rather see USB *and* HDA support able to play pcm
>>>>> streams before worrying about decoding.
>>>>>
>>>>
>>>> I agree it might turn out it is easier to have the text to speech code
>>>> just
>>>> encode a PCM directly.
>>>>
>>>> Thanks,
>>>>
>>>> Andrew Fish
>>>>
>>>>> /
>>>>>   Leif
>>>>>
>>>>> On Fri, Apr 16, 2021 at 00:33:06 -0500, Ethin Probst wrote:
>>>>>> Thanks for that explanation (I missed Mike's message). Earlier I sent
>>>>>> a summary of those things that we can agree on: mainly, that we have
>>>>>> mute, volume control, a load buffer, (maybe) an unload buffer, and a
>>>>>> start/stop stream function. Now that I fully understand the
>>>>>> ramifications of this I don't mind settling for a specific format and
>>>>>> sample rate, and signed 16-bit PCM audio is, I think, the most widely
>>>>>> used one out there, besides 64-bit floating point samples, which I've
>>>>>> only seen used in DAWs, and that's something we don't need.
>>>>>> Are you sure you want the firmware itself to handle the decoding of
>>>>>> WAV audio? I can make a library class for that, but I'll definitely
>>>>>> need help with the security aspect.
>>>>>>
>>>>>> On 4/16/21, Andrew Fish via groups.io <afish=apple.com@groups.io>
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>> On Apr 15, 2021, at 5:59 PM, Michael Brown <mcb30@ipxe.org> wrote:
>>>>>>>>
>>>>>>>> On 16/04/2021 00:42, Ethin Probst wrote:
>>>>>>>>> Forcing a particular channel mapping, sample rate and sample
>>>>>>>>> format
>>>>>>>>> on
>>>>>>>>> everyone would complicate application code. From an application
>>>>>>>>> point
>>>>>>>>> of view, one would, with that type of protocol, need to do the
>>>>>>>>> following:
>>>>>>>>> 1) Load an audio file in any audio file format from any storage
>>>>>>>>> mechanism.
>>>>>>>>> 2) Decode the audio file format to extract the samples and audio
>>>>>>>>> metadata.
>>>>>>>>> 3) Resample the (now decoded) audio samples and convert (quantize)
>>>>>>>>> the
>>>>>>>>> audio samples into signed 16-bit PCM audio.
>>>>>>>>> 4) forward the samples onto the EFI audio protocol.
>>>>>>>>
>>>>>>>> You have made an incorrect assumption that there exists a
>>>>>>>> requirement
>>>>>>>> to
>>>>>>>> be able to play audio files in arbitrary formats.  This requirement
>>>>>>>> does
>>>>>>>> not exist.
>>>>>>>>
>>>>>>>> With a protocol-mandated fixed baseline set of audio parameters
>>>>>>>> (sample
>>>>>>>> rate etc), what would happen in practice is that the audio files
>>>>>>>> would
>>>>>>>> be
>>>>>>>> encoded in that format at *build* time, using tools entirely
>>>>>>>> external
>>>>>>>> to
>>>>>>>> UEFI.  The application code is then trivially simple: it just does
>>>>>>>> "load
>>>>>>>> blob, pass blob to audio protocol".
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Ethin,
>>>>>>>
>>>>>>> Given the goal is an industry standard we value interoperability
>>>>>>> more
>>>>>>> that
>>>>>>> flexibility.
>>>>>>>
>>>>>>> How about another use case. Lets say the Linux OS loader (Grub)
>>>>>>> wants
>>>>>>> to
>>>>>>> have an accessible UI so it decides to sore sound files on the EFI
>>>>>>> System
>>>>>>> Partition and use our new fancy UEFI Audio Protocol to add audio to
>>>>>>> the
>>>>>>> OS
>>>>>>> loader GUI. So that version of Grub needs to work on 1,000 of
>>>>>>> different
>>>>>>> PCs
>>>>>>> and a wide range of UEFI Audio driver implementations. It is a much
>>>>>>> easier
>>>>>>> world if Wave PCM 16 bit just works every place. You could add a lot
>>>>>>> of
>>>>>>> complexity and try to encode the audio on the fly, maybe even in
>>>>>>> Linux
>>>>>>> proper but that falls down if you are booting from read only media
>>>>>>> like
>>>>>>> a
>>>>>>> DVD or backup tape (yes people still do that in server land).
>>>>>>>
>>>>>>> The other problem with flexibility is you just made the test matrix
>>>>>>> very
>>>>>>> large for every driver that needs to get implemented. For something
>>>>>>> as
>>>>>>> complex as Intel HDA how you hook up the hardware and what CODECs
>>>>>>> you
>>>>>>> use
>>>>>>> may impact the quality of the playback for a given board. Your EFI
>>>>>>> is
>>>>>>> likely
>>>>>>> going to pick a single encoding at that will get tested all the time
>>>>>>> if
>>>>>>> your
>>>>>>> system has audio, but all 50 other things you support not so much.
>>>>>>> So
>>>>>>> that
>>>>>>> will required testing, and some one with audiophile ears (or an AI
>>>>>>> program)
>>>>>>> to test all the combinations. I’m not kidding I get BZs on the
>>>>>>> quality
>>>>>>> of
>>>>>>> the boot bong on our systems.
>>>>>>>
>>>>>>>
>>>>>>>>> typedef struct EFI_SIMPLE_AUDIO_PROTOCOL {
>>>>>>>>> EFI_SIMPLE_AUDIO_PROTOCOL_RESET Reset;
>>>>>>>>> EFI_SIMPLE_AUDIO_PROTOCOL_START Start;
>>>>>>>>> EFI_SIMPLE_AUDIO_PROTOCOL_STOP Stop;
>>>>>>>>> } EFI_SIMPLE_AUDIO_PROTOCOL;
>>>>>>>>
>>>>>>>> This is now starting to look like something that belongs in
>>>>>>>> boot-time
>>>>>>>> firmware.  :)
>>>>>>>>
>>>>>>>
>>>>>>> I think that got a little too simple I’d go back and look at the
>>>>>>> example
>>>>>>> I
>>>>>>> posted to the thread but add an API to load the buffer, and then
>>>>>>> play
>>>>>>> the
>>>>>>> buffer (that way we can an API in the future to twiddle knobs). That
>>>>>>> API
>>>>>>> also implements the async EFI interface. Trust me the 1st thing that
>>>>>>> is
>>>>>>> going to happen when we add audio is some one is going to complain
>>>>>>> in
>>>>>>> xyz
>>>>>>> state we should mute audio, or we should honer audio volume and mute
>>>>>>> settings from setup, or from values set in the OS. Or some one is
>>>>>>> going
>>>>>>> to
>>>>>>> want the volume keys on the keyboard to work in EFI.
>>>>>>>
>>>>>>> Also if you need to pick apart the Wave PCM 16 byte file to feed it
>>>>>>> into
>>>>>>> the
>>>>>>> audio hardware that probably means we should have a library that
>>>>>>> does
>>>>>>> that
>>>>>>> work, so other Audio drivers can share that code. Also having a
>>>>>>> library
>>>>>>> makes it easier to write a unit test. We need to be security
>>>>>>> conscious
>>>>>>> as we
>>>>>>> need to treat the Audo file as attacker controlled data.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Andrew Fish
>>>>>>>
>>>>>>>> Michael
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Signed,
>>>>>> Ethin D. Probst
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Signed,
>>> Ethin D. Probst
>>>
>>
>>
>> --
>> Signed,
>> Ethin D. Probst
>>
>>
>> 
>>
>>
>
>


-- 
Signed,
Ethin D. Probst

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Marvin Häuser]

On 16.04.21 19:45, Ethin Probst wrote:
> Yes, three APIs (maybe like this) would work well:
> - Start, Stop: begin playback of a stream
> - SetVolume, GetVolume, Mute, Unmute: control volume of output and enable muting
> - CreateStream, ReleaseStream, SetStreamSampleRate: Control sample
> rate of stream (but not sample format since Signed 16-bit PCM is
> enough)
> Marvin, how do you suggest we make the events then? We need some way
> of notifying the caller that the stream has concluded. We could make
> the driver create the event and pass it back to the caller as an
> event, but you'd still have dangling pointers (this is C, after all).
> We could just make a IsPlaying() function and WaitForCompletion()
> function and allow the driver to do the event handling -- would that
> work?

I do not know enough about the possible use-cases to tell. Aside from 
the two functions you already mentioned, you could also take in an 
(optional) notification function.
Which possible use-cases does determining playback end have? If it's too 
much effort, just use EFI_EVENT I guess, just the less code can mess it 
up, the better.

If I remember correctly you mentioned the UEFI Talkbox before, if that 
is more convenient for you, I'm there as mhaeuser.

Best regards,
Marvin

>
> On 4/16/21, Andrew Fish <afish@apple.com> wrote:
>>
>>> On Apr 16, 2021, at 4:34 AM, Leif Lindholm <leif@nuviainc.com> wrote:
>>>
>>> Hi Ethin,
>>>
>>> I think we also want to have a SetMode function, even if we don't get
>>> around to implement proper support for it as part of GSoC (although I
>>> expect at least for virtio, that should be pretty straightforward).
>>>
>> Leif,
>>
>> I’m think if we have an API to load the buffer and a 2nd API to play the
>> buffer an optional 3rd API could configure the streams.
>>
>>> It's quite likely that speech for UI would be stored as 8kHz (or
>>> 20kHz) in some systems, whereas the example for playing a tune in GRUB
>>> would more likely be a 44.1 kHz mp3/wav/ogg/flac.
>>>
>>> For the GSoC project, I think it would be quite reasonable to
>>> pre-generate pure PCM streams for testing rather than decoding
>>> anything on the fly.
>>>
>>> Porting/writing decoders is really a separate task from enabling the
>>> output. I would much rather see USB *and* HDA support able to play pcm
>>> streams before worrying about decoding.
>>>
>> I agree it might turn out it is easier to have the text to speech code just
>> encode a PCM directly.
>>
>> Thanks,
>>
>> Andrew Fish
>>
>>> /
>>>     Leif
>>>
>>> On Fri, Apr 16, 2021 at 00:33:06 -0500, Ethin Probst wrote:
>>>> Thanks for that explanation (I missed Mike's message). Earlier I sent
>>>> a summary of those things that we can agree on: mainly, that we have
>>>> mute, volume control, a load buffer, (maybe) an unload buffer, and a
>>>> start/stop stream function. Now that I fully understand the
>>>> ramifications of this I don't mind settling for a specific format and
>>>> sample rate, and signed 16-bit PCM audio is, I think, the most widely
>>>> used one out there, besides 64-bit floating point samples, which I've
>>>> only seen used in DAWs, and that's something we don't need.
>>>> Are you sure you want the firmware itself to handle the decoding of
>>>> WAV audio? I can make a library class for that, but I'll definitely
>>>> need help with the security aspect.
>>>>
>>>> On 4/16/21, Andrew Fish via groups.io <afish=apple.com@groups.io> wrote:
>>>>>
>>>>>> On Apr 15, 2021, at 5:59 PM, Michael Brown <mcb30@ipxe.org> wrote:
>>>>>>
>>>>>> On 16/04/2021 00:42, Ethin Probst wrote:
>>>>>>> Forcing a particular channel mapping, sample rate and sample format
>>>>>>> on
>>>>>>> everyone would complicate application code. From an application point
>>>>>>> of view, one would, with that type of protocol, need to do the
>>>>>>> following:
>>>>>>> 1) Load an audio file in any audio file format from any storage
>>>>>>> mechanism.
>>>>>>> 2) Decode the audio file format to extract the samples and audio
>>>>>>> metadata.
>>>>>>> 3) Resample the (now decoded) audio samples and convert (quantize)
>>>>>>> the
>>>>>>> audio samples into signed 16-bit PCM audio.
>>>>>>> 4) forward the samples onto the EFI audio protocol.
>>>>>> You have made an incorrect assumption that there exists a requirement
>>>>>> to
>>>>>> be able to play audio files in arbitrary formats.  This requirement
>>>>>> does
>>>>>> not exist.
>>>>>>
>>>>>> With a protocol-mandated fixed baseline set of audio parameters
>>>>>> (sample
>>>>>> rate etc), what would happen in practice is that the audio files would
>>>>>> be
>>>>>> encoded in that format at *build* time, using tools entirely external
>>>>>> to
>>>>>> UEFI.  The application code is then trivially simple: it just does
>>>>>> "load
>>>>>> blob, pass blob to audio protocol".
>>>>>>
>>>>>
>>>>> Ethin,
>>>>>
>>>>> Given the goal is an industry standard we value interoperability more
>>>>> that
>>>>> flexibility.
>>>>>
>>>>> How about another use case. Lets say the Linux OS loader (Grub) wants
>>>>> to
>>>>> have an accessible UI so it decides to sore sound files on the EFI
>>>>> System
>>>>> Partition and use our new fancy UEFI Audio Protocol to add audio to the
>>>>> OS
>>>>> loader GUI. So that version of Grub needs to work on 1,000 of different
>>>>> PCs
>>>>> and a wide range of UEFI Audio driver implementations. It is a much
>>>>> easier
>>>>> world if Wave PCM 16 bit just works every place. You could add a lot of
>>>>> complexity and try to encode the audio on the fly, maybe even in Linux
>>>>> proper but that falls down if you are booting from read only media like
>>>>> a
>>>>> DVD or backup tape (yes people still do that in server land).
>>>>>
>>>>> The other problem with flexibility is you just made the test matrix
>>>>> very
>>>>> large for every driver that needs to get implemented. For something as
>>>>> complex as Intel HDA how you hook up the hardware and what CODECs you
>>>>> use
>>>>> may impact the quality of the playback for a given board. Your EFI is
>>>>> likely
>>>>> going to pick a single encoding at that will get tested all the time if
>>>>> your
>>>>> system has audio, but all 50 other things you support not so much. So
>>>>> that
>>>>> will required testing, and some one with audiophile ears (or an AI
>>>>> program)
>>>>> to test all the combinations. I’m not kidding I get BZs on the quality
>>>>> of
>>>>> the boot bong on our systems.
>>>>>
>>>>>
>>>>>>> typedef struct EFI_SIMPLE_AUDIO_PROTOCOL {
>>>>>>>   EFI_SIMPLE_AUDIO_PROTOCOL_RESET Reset;
>>>>>>>   EFI_SIMPLE_AUDIO_PROTOCOL_START Start;
>>>>>>>   EFI_SIMPLE_AUDIO_PROTOCOL_STOP Stop;
>>>>>>> } EFI_SIMPLE_AUDIO_PROTOCOL;
>>>>>> This is now starting to look like something that belongs in boot-time
>>>>>> firmware.  :)
>>>>>>
>>>>> I think that got a little too simple I’d go back and look at the example
>>>>> I
>>>>> posted to the thread but add an API to load the buffer, and then play
>>>>> the
>>>>> buffer (that way we can an API in the future to twiddle knobs). That
>>>>> API
>>>>> also implements the async EFI interface. Trust me the 1st thing that is
>>>>> going to happen when we add audio is some one is going to complain in
>>>>> xyz
>>>>> state we should mute audio, or we should honer audio volume and mute
>>>>> settings from setup, or from values set in the OS. Or some one is going
>>>>> to
>>>>> want the volume keys on the keyboard to work in EFI.
>>>>>
>>>>> Also if you need to pick apart the Wave PCM 16 byte file to feed it into
>>>>> the
>>>>> audio hardware that probably means we should have a library that does
>>>>> that
>>>>> work, so other Audio drivers can share that code. Also having a library
>>>>> makes it easier to write a unit test. We need to be security conscious
>>>>> as we
>>>>> need to treat the Audo file as attacker controlled data.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Andrew Fish
>>>>>
>>>>>> Michael
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Signed,
>>>> Ethin D. Probst
>>>
>>>
>>>
>>>
>>
>

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Andrew Fish]

[-- Attachment #1: Type: text/plain, Size: 9387 bytes --]



> On Apr 17, 2021, at 9:51 AM, Marvin Häuser <mhaeuser@posteo.de> wrote:
> 
> On 16.04.21 19:45, Ethin Probst wrote:
>> Yes, three APIs (maybe like this) would work well:
>> - Start, Stop: begin playback of a stream
>> - SetVolume, GetVolume, Mute, Unmute: control volume of output and enable muting
>> - CreateStream, ReleaseStream, SetStreamSampleRate: Control sample
>> rate of stream (but not sample format since Signed 16-bit PCM is
>> enough)
>> Marvin, how do you suggest we make the events then? We need some way
>> of notifying the caller that the stream has concluded. We could make
>> the driver create the event and pass it back to the caller as an
>> event, but you'd still have dangling pointers (this is C, after all).
>> We could just make a IsPlaying() function and WaitForCompletion()
>> function and allow the driver to do the event handling -- would that
>> work?
> 
> I do not know enough about the possible use-cases to tell. Aside from the two functions you already mentioned, you could also take in an (optional) notification function.
> Which possible use-cases does determining playback end have? If it's too much effort, just use EFI_EVENT I guess, just the less code can mess it up, the better.
> 

In UEFI EFI_EVENT works much better. There is a gBS-WaitForEvent() function that lets a caller wait on an event. That is basically what the UEFI Shell is doing at the Shell prompt. A GUI in UEFI/C is basically an event loop. 

Fun fact: I ended up adding gIdleLoopEventGuid to the MdeModulePkg so the DXE Core could signal gIdleLoopEventGuid if you are sitting in gBS-WaitForEvent() and no event is signaled. Basically in EFI nothing is going to happen until the next timer tick so the gIdleLoopEventGuid lets you idle the CPU until the next timer tick. I was forced to do this as the 1st MacBook Air had a bad habit of thermal tripping when sitting at the UEFI Shell prompt. After all another name for a loop in C code running on bare metal is a power virus. 

Thanks,

Andrew Fish. 

> If I remember correctly you mentioned the UEFI Talkbox before, if that is more convenient for you, I'm there as mhaeuser.
> 
> Best regards,
> Marvin
> 
>> 
>> On 4/16/21, Andrew Fish <afish@apple.com> wrote:
>>> 
>>>> On Apr 16, 2021, at 4:34 AM, Leif Lindholm <leif@nuviainc.com> wrote:
>>>> 
>>>> Hi Ethin,
>>>> 
>>>> I think we also want to have a SetMode function, even if we don't get
>>>> around to implement proper support for it as part of GSoC (although I
>>>> expect at least for virtio, that should be pretty straightforward).
>>>> 
>>> Leif,
>>> 
>>> I’m think if we have an API to load the buffer and a 2nd API to play the
>>> buffer an optional 3rd API could configure the streams.
>>> 
>>>> It's quite likely that speech for UI would be stored as 8kHz (or
>>>> 20kHz) in some systems, whereas the example for playing a tune in GRUB
>>>> would more likely be a 44.1 kHz mp3/wav/ogg/flac.
>>>> 
>>>> For the GSoC project, I think it would be quite reasonable to
>>>> pre-generate pure PCM streams for testing rather than decoding
>>>> anything on the fly.
>>>> 
>>>> Porting/writing decoders is really a separate task from enabling the
>>>> output. I would much rather see USB *and* HDA support able to play pcm
>>>> streams before worrying about decoding.
>>>> 
>>> I agree it might turn out it is easier to have the text to speech code just
>>> encode a PCM directly.
>>> 
>>> Thanks,
>>> 
>>> Andrew Fish
>>> 
>>>> /
>>>>    Leif
>>>> 
>>>> On Fri, Apr 16, 2021 at 00:33:06 -0500, Ethin Probst wrote:
>>>>> Thanks for that explanation (I missed Mike's message). Earlier I sent
>>>>> a summary of those things that we can agree on: mainly, that we have
>>>>> mute, volume control, a load buffer, (maybe) an unload buffer, and a
>>>>> start/stop stream function. Now that I fully understand the
>>>>> ramifications of this I don't mind settling for a specific format and
>>>>> sample rate, and signed 16-bit PCM audio is, I think, the most widely
>>>>> used one out there, besides 64-bit floating point samples, which I've
>>>>> only seen used in DAWs, and that's something we don't need.
>>>>> Are you sure you want the firmware itself to handle the decoding of
>>>>> WAV audio? I can make a library class for that, but I'll definitely
>>>>> need help with the security aspect.
>>>>> 
>>>>> On 4/16/21, Andrew Fish via groups.io <afish=apple.com@groups.io> wrote:
>>>>>> 
>>>>>>> On Apr 15, 2021, at 5:59 PM, Michael Brown <mcb30@ipxe.org> wrote:
>>>>>>> 
>>>>>>> On 16/04/2021 00:42, Ethin Probst wrote:
>>>>>>>> Forcing a particular channel mapping, sample rate and sample format
>>>>>>>> on
>>>>>>>> everyone would complicate application code. From an application point
>>>>>>>> of view, one would, with that type of protocol, need to do the
>>>>>>>> following:
>>>>>>>> 1) Load an audio file in any audio file format from any storage
>>>>>>>> mechanism.
>>>>>>>> 2) Decode the audio file format to extract the samples and audio
>>>>>>>> metadata.
>>>>>>>> 3) Resample the (now decoded) audio samples and convert (quantize)
>>>>>>>> the
>>>>>>>> audio samples into signed 16-bit PCM audio.
>>>>>>>> 4) forward the samples onto the EFI audio protocol.
>>>>>>> You have made an incorrect assumption that there exists a requirement
>>>>>>> to
>>>>>>> be able to play audio files in arbitrary formats.  This requirement
>>>>>>> does
>>>>>>> not exist.
>>>>>>> 
>>>>>>> With a protocol-mandated fixed baseline set of audio parameters
>>>>>>> (sample
>>>>>>> rate etc), what would happen in practice is that the audio files would
>>>>>>> be
>>>>>>> encoded in that format at *build* time, using tools entirely external
>>>>>>> to
>>>>>>> UEFI.  The application code is then trivially simple: it just does
>>>>>>> "load
>>>>>>> blob, pass blob to audio protocol".
>>>>>>> 
>>>>>> 
>>>>>> Ethin,
>>>>>> 
>>>>>> Given the goal is an industry standard we value interoperability more
>>>>>> that
>>>>>> flexibility.
>>>>>> 
>>>>>> How about another use case. Lets say the Linux OS loader (Grub) wants
>>>>>> to
>>>>>> have an accessible UI so it decides to sore sound files on the EFI
>>>>>> System
>>>>>> Partition and use our new fancy UEFI Audio Protocol to add audio to the
>>>>>> OS
>>>>>> loader GUI. So that version of Grub needs to work on 1,000 of different
>>>>>> PCs
>>>>>> and a wide range of UEFI Audio driver implementations. It is a much
>>>>>> easier
>>>>>> world if Wave PCM 16 bit just works every place. You could add a lot of
>>>>>> complexity and try to encode the audio on the fly, maybe even in Linux
>>>>>> proper but that falls down if you are booting from read only media like
>>>>>> a
>>>>>> DVD or backup tape (yes people still do that in server land).
>>>>>> 
>>>>>> The other problem with flexibility is you just made the test matrix
>>>>>> very
>>>>>> large for every driver that needs to get implemented. For something as
>>>>>> complex as Intel HDA how you hook up the hardware and what CODECs you
>>>>>> use
>>>>>> may impact the quality of the playback for a given board. Your EFI is
>>>>>> likely
>>>>>> going to pick a single encoding at that will get tested all the time if
>>>>>> your
>>>>>> system has audio, but all 50 other things you support not so much. So
>>>>>> that
>>>>>> will required testing, and some one with audiophile ears (or an AI
>>>>>> program)
>>>>>> to test all the combinations. I’m not kidding I get BZs on the quality
>>>>>> of
>>>>>> the boot bong on our systems.
>>>>>> 
>>>>>> 
>>>>>>>> typedef struct EFI_SIMPLE_AUDIO_PROTOCOL {
>>>>>>>>  EFI_SIMPLE_AUDIO_PROTOCOL_RESET Reset;
>>>>>>>>  EFI_SIMPLE_AUDIO_PROTOCOL_START Start;
>>>>>>>>  EFI_SIMPLE_AUDIO_PROTOCOL_STOP Stop;
>>>>>>>> } EFI_SIMPLE_AUDIO_PROTOCOL;
>>>>>>> This is now starting to look like something that belongs in boot-time
>>>>>>> firmware.  :)
>>>>>>> 
>>>>>> I think that got a little too simple I’d go back and look at the example
>>>>>> I
>>>>>> posted to the thread but add an API to load the buffer, and then play
>>>>>> the
>>>>>> buffer (that way we can an API in the future to twiddle knobs). That
>>>>>> API
>>>>>> also implements the async EFI interface. Trust me the 1st thing that is
>>>>>> going to happen when we add audio is some one is going to complain in
>>>>>> xyz
>>>>>> state we should mute audio, or we should honer audio volume and mute
>>>>>> settings from setup, or from values set in the OS. Or some one is going
>>>>>> to
>>>>>> want the volume keys on the keyboard to work in EFI.
>>>>>> 
>>>>>> Also if you need to pick apart the Wave PCM 16 byte file to feed it into
>>>>>> the
>>>>>> audio hardware that probably means we should have a library that does
>>>>>> that
>>>>>> work, so other Audio drivers can share that code. Also having a library
>>>>>> makes it easier to write a unit test. We need to be security conscious
>>>>>> as we
>>>>>> need to treat the Audo file as attacker controlled data.
>>>>>> 
>>>>>> Thanks,
>>>>>> 
>>>>>> Andrew Fish
>>>>>> 
>>>>>>> Michael
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> --
>>>>> Signed,
>>>>> Ethin D. Probst
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>> 
> 
> 
> 
> 


[-- Attachment #2: Type: text/html, Size: 19566 bytes --]

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Marvin Häuser]

On 17.04.21 19:31, Andrew Fish via groups.io wrote:
>
>
>> On Apr 17, 2021, at 9:51 AM, Marvin Häuser <mhaeuser@posteo.de 
>> <mailto:mhaeuser@posteo.de>> wrote:
>>
>> On 16.04.21 19:45, Ethin Probst wrote:
>>> Yes, three APIs (maybe like this) would work well:
>>> - Start, Stop: begin playback of a stream
>>> - SetVolume, GetVolume, Mute, Unmute: control volume of output and 
>>> enable muting
>>> - CreateStream, ReleaseStream, SetStreamSampleRate: Control sample
>>> rate of stream (but not sample format since Signed 16-bit PCM is
>>> enough)
>>> Marvin, how do you suggest we make the events then? We need some way
>>> of notifying the caller that the stream has concluded. We could make
>>> the driver create the event and pass it back to the caller as an
>>> event, but you'd still have dangling pointers (this is C, after all).
>>> We could just make a IsPlaying() function and WaitForCompletion()
>>> function and allow the driver to do the event handling -- would that
>>> work?
>>
>> I do not know enough about the possible use-cases to tell. Aside from 
>> the two functions you already mentioned, you could also take in an 
>> (optional) notification function.
>> Which possible use-cases does determining playback end have? If it's 
>> too much effort, just use EFI_EVENT I guess, just the less code can 
>> mess it up, the better.
>>
>
> In UEFI EFI_EVENT works much better. There is a gBS-WaitForEvent() 
> function that lets a caller wait on an event. That is basically what 
> the UEFI Shell is doing at the Shell prompt. A GUI in UEFI/C is 
> basically an event loop.
>
> Fun fact: I ended up adding gIdleLoopEventGuid to the MdeModulePkg so 
> the DXE Core could signal gIdleLoopEventGuid if you are sitting in 
> gBS-WaitForEvent() and no event is signaled. Basically in EFI nothing 
> is going to happen until the next timer tick so the gIdleLoopEventGuid 
> lets you idle the CPU until the next timer tick. I was forced to do 
> this as the 1st MacBook Air had a bad habit of thermal tripping when 
> sitting at the UEFI Shell prompt. After all another name for a loop in 
> C code running on bare metal is a power virus.

Mac EFI is one of the best implementations we know of, frankly. I'm 
traumatised by Aptio 4 and alike, where (some issues are OEM-specific I 
think) you can have timer events signalling after ExitBS, there is event 
clutter on IO polling to the point where everything lags no matter what 
you do, and even in "smooth" scenarios there may be nothing worth the 
description "granularity" (events scheduled to run every 10 ms may run 
every 50 ms). Events are the last resort for us, if there really is no 
other way. My first GUI implementation worked without events at all for 
this reason, but as our workarounds got better, we did start using them 
for keyboard and mouse polling.

Timers do not apply here, but what does apply is resource management. 
Using EFI_EVENT directly means (to the outside) the introduction of a 
new resource to maintain, for each caller separately. On the other side, 
there is no resource to misuse or leak if none such is exposed. Yet, if 
you argue with APIs like WaitForEvent, something has to signal it. In a 
simple environment this would mean, some timer event is running and may 
signal the event the main code waits for, where above's concern actually 
do apply. :) Again, the recommendation assumes the use-cases are simple 
enough to easily avoid them.

I think it would be best to sketch use-cases for audio and design the 
solutions closely to the requirements. Why do we need to know when audio 
finished? What will happen when we queue audio twice? There are many 
layers (UX, interface, implementation details) of questions to coming up 
with a pleasant and stable design.

Best regards,
Marvin

>
> Thanks,
>
> Andrew Fish.
>
>> If I remember correctly you mentioned the UEFI Talkbox before, if 
>> that is more convenient for you, I'm there as mhaeuser.
>>
>> Best regards,
>> Marvin
>>
>>>
>>> On 4/16/21, Andrew Fish <afish@apple.com <mailto:afish@apple.com>> 
>>> wrote:
>>>>
>>>>> On Apr 16, 2021, at 4:34 AM, Leif Lindholm <leif@nuviainc.com 
>>>>> <mailto:leif@nuviainc.com>> wrote:
>>>>>
>>>>> Hi Ethin,
>>>>>
>>>>> I think we also want to have a SetMode function, even if we don't get
>>>>> around to implement proper support for it as part of GSoC (although I
>>>>> expect at least for virtio, that should be pretty straightforward).
>>>>>
>>>> Leif,
>>>>
>>>> I’m think if we have an API to load the buffer and a 2nd API to 
>>>> play the
>>>> buffer an optional 3rd API could configure the streams.
>>>>
>>>>> It's quite likely that speech for UI would be stored as 8kHz (or
>>>>> 20kHz) in some systems, whereas the example for playing a tune in GRUB
>>>>> would more likely be a 44.1 kHz mp3/wav/ogg/flac.
>>>>>
>>>>> For the GSoC project, I think it would be quite reasonable to
>>>>> pre-generate pure PCM streams for testing rather than decoding
>>>>> anything on the fly.
>>>>>
>>>>> Porting/writing decoders is really a separate task from enabling the
>>>>> output. I would much rather see USB *and* HDA support able to play pcm
>>>>> streams before worrying about decoding.
>>>>>
>>>> I agree it might turn out it is easier to have the text to speech 
>>>> code just
>>>> encode a PCM directly.
>>>>
>>>> Thanks,
>>>>
>>>> Andrew Fish
>>>>
>>>>> /
>>>>>    Leif
>>>>>
>>>>> On Fri, Apr 16, 2021 at 00:33:06 -0500, Ethin Probst wrote:
>>>>>> Thanks for that explanation (I missed Mike's message). Earlier I sent
>>>>>> a summary of those things that we can agree on: mainly, that we have
>>>>>> mute, volume control, a load buffer, (maybe) an unload buffer, and a
>>>>>> start/stop stream function. Now that I fully understand the
>>>>>> ramifications of this I don't mind settling for a specific format and
>>>>>> sample rate, and signed 16-bit PCM audio is, I think, the most widely
>>>>>> used one out there, besides 64-bit floating point samples, which I've
>>>>>> only seen used in DAWs, and that's something we don't need.
>>>>>> Are you sure you want the firmware itself to handle the decoding of
>>>>>> WAV audio? I can make a library class for that, but I'll definitely
>>>>>> need help with the security aspect.
>>>>>>
>>>>>> On 4/16/21, Andrew Fish via groups.io <http://groups.io> 
>>>>>> <afish=apple.com@groups.io <mailto:afish=apple.com@groups.io>> wrote:
>>>>>>>
>>>>>>>> On Apr 15, 2021, at 5:59 PM, Michael Brown <mcb30@ipxe.org 
>>>>>>>> <mailto:mcb30@ipxe.org>> wrote:
>>>>>>>>
>>>>>>>> On 16/04/2021 00:42, Ethin Probst wrote:
>>>>>>>>> Forcing a particular channel mapping, sample rate and sample 
>>>>>>>>> format
>>>>>>>>> on
>>>>>>>>> everyone would complicate application code. From an 
>>>>>>>>> application point
>>>>>>>>> of view, one would, with that type of protocol, need to do the
>>>>>>>>> following:
>>>>>>>>> 1) Load an audio file in any audio file format from any storage
>>>>>>>>> mechanism.
>>>>>>>>> 2) Decode the audio file format to extract the samples and audio
>>>>>>>>> metadata.
>>>>>>>>> 3) Resample the (now decoded) audio samples and convert (quantize)
>>>>>>>>> the
>>>>>>>>> audio samples into signed 16-bit PCM audio.
>>>>>>>>> 4) forward the samples onto the EFI audio protocol.
>>>>>>>> You have made an incorrect assumption that there exists a 
>>>>>>>> requirement
>>>>>>>> to
>>>>>>>> be able to play audio files in arbitrary formats.  This requirement
>>>>>>>> does
>>>>>>>> not exist.
>>>>>>>>
>>>>>>>> With a protocol-mandated fixed baseline set of audio parameters
>>>>>>>> (sample
>>>>>>>> rate etc), what would happen in practice is that the audio 
>>>>>>>> files would
>>>>>>>> be
>>>>>>>> encoded in that format at *build* time, using tools entirely 
>>>>>>>> external
>>>>>>>> to
>>>>>>>> UEFI.  The application code is then trivially simple: it just does
>>>>>>>> "load
>>>>>>>> blob, pass blob to audio protocol".
>>>>>>>>
>>>>>>>
>>>>>>> Ethin,
>>>>>>>
>>>>>>> Given the goal is an industry standard we value interoperability 
>>>>>>> more
>>>>>>> that
>>>>>>> flexibility.
>>>>>>>
>>>>>>> How about another use case. Lets say the Linux OS loader (Grub) 
>>>>>>> wants
>>>>>>> to
>>>>>>> have an accessible UI so it decides to sore sound files on the EFI
>>>>>>> System
>>>>>>> Partition and use our new fancy UEFI Audio Protocol to add audio 
>>>>>>> to the
>>>>>>> OS
>>>>>>> loader GUI. So that version of Grub needs to work on 1,000 of 
>>>>>>> different
>>>>>>> PCs
>>>>>>> and a wide range of UEFI Audio driver implementations. It is a much
>>>>>>> easier
>>>>>>> world if Wave PCM 16 bit just works every place. You could add a 
>>>>>>> lot of
>>>>>>> complexity and try to encode the audio on the fly, maybe even in 
>>>>>>> Linux
>>>>>>> proper but that falls down if you are booting from read only 
>>>>>>> media like
>>>>>>> a
>>>>>>> DVD or backup tape (yes people still do that in server land).
>>>>>>>
>>>>>>> The other problem with flexibility is you just made the test matrix
>>>>>>> very
>>>>>>> large for every driver that needs to get implemented. For 
>>>>>>> something as
>>>>>>> complex as Intel HDA how you hook up the hardware and what 
>>>>>>> CODECs you
>>>>>>> use
>>>>>>> may impact the quality of the playback for a given board. Your 
>>>>>>> EFI is
>>>>>>> likely
>>>>>>> going to pick a single encoding at that will get tested all the 
>>>>>>> time if
>>>>>>> your
>>>>>>> system has audio, but all 50 other things you support not so 
>>>>>>> much. So
>>>>>>> that
>>>>>>> will required testing, and some one with audiophile ears (or an AI
>>>>>>> program)
>>>>>>> to test all the combinations. I’m not kidding I get BZs on the 
>>>>>>> quality
>>>>>>> of
>>>>>>> the boot bong on our systems.
>>>>>>>
>>>>>>>
>>>>>>>>> typedef struct EFI_SIMPLE_AUDIO_PROTOCOL {
>>>>>>>>>  EFI_SIMPLE_AUDIO_PROTOCOL_RESET Reset;
>>>>>>>>>  EFI_SIMPLE_AUDIO_PROTOCOL_START Start;
>>>>>>>>>  EFI_SIMPLE_AUDIO_PROTOCOL_STOP Stop;
>>>>>>>>> } EFI_SIMPLE_AUDIO_PROTOCOL;
>>>>>>>> This is now starting to look like something that belongs in 
>>>>>>>> boot-time
>>>>>>>> firmware.  :)
>>>>>>>>
>>>>>>> I think that got a little too simple I’d go back and look at the 
>>>>>>> example
>>>>>>> I
>>>>>>> posted to the thread but add an API to load the buffer, and then 
>>>>>>> play
>>>>>>> the
>>>>>>> buffer (that way we can an API in the future to twiddle knobs). That
>>>>>>> API
>>>>>>> also implements the async EFI interface. Trust me the 1st thing 
>>>>>>> that is
>>>>>>> going to happen when we add audio is some one is going to 
>>>>>>> complain in
>>>>>>> xyz
>>>>>>> state we should mute audio, or we should honer audio volume and mute
>>>>>>> settings from setup, or from values set in the OS. Or some one 
>>>>>>> is going
>>>>>>> to
>>>>>>> want the volume keys on the keyboard to work in EFI.
>>>>>>>
>>>>>>> Also if you need to pick apart the Wave PCM 16 byte file to feed 
>>>>>>> it into
>>>>>>> the
>>>>>>> audio hardware that probably means we should have a library that 
>>>>>>> does
>>>>>>> that
>>>>>>> work, so other Audio drivers can share that code. Also having a 
>>>>>>> library
>>>>>>> makes it easier to write a unit test. We need to be security 
>>>>>>> conscious
>>>>>>> as we
>>>>>>> need to treat the Audo file as attacker controlled data.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Andrew Fish
>>>>>>>
>>>>>>>> Michael
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Signed,
>>>>>> Ethin D. Probst
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>>
>
> 

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Ethin Probst]

>I think it would be best to sketch use-cases for audio and design the solutions closely to the requirements. Why do we need to know when audio finished? What will happen when we queue audio twice? There are many layers (UX, interface, implementation details) of questions to coming up with a pleasant and stable design.
I would be happy to discuss this with you on the UEFI talkbox. I'm
draeand on there.
As for your questions:

1. The only reason I recommend using an event to signal audio
completion is because I do not want this protocol to be blocking at
all. (So, perhaps removing the token entirely is a good idea.) The
VirtIO audio device says nothing about synchronization, but I imagine
its asynchronous because every audio specification I've seen out there
is asynchronous. Similarly, every audio API in existence -- at least,
every low-level OS-specific one -- is asynchronous/non-blocking.
(Usually, audio processing is handled on a separate thread.) However,
UEFI has no concept of threads or processes. Though we could use the
MP PI package to spin up a separate processor, that would fail on
uniprocessor, unicore systems. Audio processing needs a high enough
priority that it gets first in the list of tasks served while
simultaneously not getting a priority that's so high that it blocks
everything else. This is primarily because of the way an audio
subsystem is designed and the way an audio device functions: the audio
subsystem needs to know, immediately, when the audio buffer has ran
out of samples and needs more, and it needs to react immediately to
refill the buffer if required, especially when streaming large amounts
of audio (e.g.: music). Similarly, the audio subsystem needs the
ability to react as soon as is viable when playback is requested,
because any significant delay will be noticeable by the end-user. In
more complex systems like FMOD or OpenAL, the audio processing thread
also needs a high priority to ensure that audio effects, positioning
information, dithering, etc., can be configured immediately because
the user will notice if any glitches or delays occur. The UEFI audio
protocols obviously will be nowhere near as complex, or as advanced,
because no one will need audio effects in a preboot environment.
Granted, its possible to make small audio effects, for example delays,
even if the protocol doesn't have functions to do that, but if an
end-user wants to go absolutely crazy with the audio samples and mix
in a really nice-sounding reverb or audio filter before sending the
samples to the audio engine, well, that's what they want to do and
that's out of our hands as driver/protocol developers. But I digress.
UEFI only has four TPLs, and so what we hopefully want is an engine
that is able to manage sample buffering and transmission, but also
doesn't block the application that's using the protocol. For some
things, blocking might be acceptable, but for speech synthesis or the
playing of startup sounds, this would not be an acceptable result and
would make the protocol pretty much worthless in the majority of
scenarios. So that's why I had an event to signal audio completion --
it was (perhaps) a cheap hack around the cooperatively-scheduled task
architecture of UEFI. (At least, I think its cooperative multitasking,
correct me if I'm wrong.)
2. The VirtIO specification does not specify what occurs in the event
that a request is received to play a stream that's already being
played. However, it does provide enough information for extrapolation.
Every request that's sent to a VirtIO sound device must come with two
things: a stream ID and a buffer of samples. The sample data must
immediately follow the request. Therefore, for VirtIO in particular,
the device will simply stop playing the old set of samples and play
the new set instead. This goes along with what I've seen in other
specifications like the HDA one: unless the device in question
supports more than one stream, it is impossible to play two sounds on
a single stream simultaneously, and an HDA controller (for example) is
not going to perform any mixing; mixing is done purely in software.
Similarly, if a device does support multiple streams, it is
unspecified whether the device will play two or more streams
simultaneously or whether it will pause/abort the playback of one
while it plays another. Therefore, I believe (though cannot confirm)
that OSes like Windows simply use a single stream, even if the device
supports multiple streams, and just makes the applications believe
that unlimited streams are possible.

I apologize for this really long-winded email, and I hope no one minds. :-)

On 4/17/21, Marvin Häuser <mhaeuser@posteo.de> wrote:
> On 17.04.21 19:31, Andrew Fish via groups.io wrote:
>>
>>
>>> On Apr 17, 2021, at 9:51 AM, Marvin Häuser <mhaeuser@posteo.de
>>> <mailto:mhaeuser@posteo.de>> wrote:
>>>
>>> On 16.04.21 19:45, Ethin Probst wrote:
>>>> Yes, three APIs (maybe like this) would work well:
>>>> - Start, Stop: begin playback of a stream
>>>> - SetVolume, GetVolume, Mute, Unmute: control volume of output and
>>>> enable muting
>>>> - CreateStream, ReleaseStream, SetStreamSampleRate: Control sample
>>>> rate of stream (but not sample format since Signed 16-bit PCM is
>>>> enough)
>>>> Marvin, how do you suggest we make the events then? We need some way
>>>> of notifying the caller that the stream has concluded. We could make
>>>> the driver create the event and pass it back to the caller as an
>>>> event, but you'd still have dangling pointers (this is C, after all).
>>>> We could just make a IsPlaying() function and WaitForCompletion()
>>>> function and allow the driver to do the event handling -- would that
>>>> work?
>>>
>>> I do not know enough about the possible use-cases to tell. Aside from
>>> the two functions you already mentioned, you could also take in an
>>> (optional) notification function.
>>> Which possible use-cases does determining playback end have? If it's
>>> too much effort, just use EFI_EVENT I guess, just the less code can
>>> mess it up, the better.
>>>
>>
>> In UEFI EFI_EVENT works much better. There is a gBS-WaitForEvent()
>> function that lets a caller wait on an event. That is basically what
>> the UEFI Shell is doing at the Shell prompt. A GUI in UEFI/C is
>> basically an event loop.
>>
>> Fun fact: I ended up adding gIdleLoopEventGuid to the MdeModulePkg so
>> the DXE Core could signal gIdleLoopEventGuid if you are sitting in
>> gBS-WaitForEvent() and no event is signaled. Basically in EFI nothing
>> is going to happen until the next timer tick so the gIdleLoopEventGuid
>> lets you idle the CPU until the next timer tick. I was forced to do
>> this as the 1st MacBook Air had a bad habit of thermal tripping when
>> sitting at the UEFI Shell prompt. After all another name for a loop in
>> C code running on bare metal is a power virus.
>
> Mac EFI is one of the best implementations we know of, frankly. I'm
> traumatised by Aptio 4 and alike, where (some issues are OEM-specific I
> think) you can have timer events signalling after ExitBS, there is event
> clutter on IO polling to the point where everything lags no matter what
> you do, and even in "smooth" scenarios there may be nothing worth the
> description "granularity" (events scheduled to run every 10 ms may run
> every 50 ms). Events are the last resort for us, if there really is no
> other way. My first GUI implementation worked without events at all for
> this reason, but as our workarounds got better, we did start using them
> for keyboard and mouse polling.
>
> Timers do not apply here, but what does apply is resource management.
> Using EFI_EVENT directly means (to the outside) the introduction of a
> new resource to maintain, for each caller separately. On the other side,
> there is no resource to misuse or leak if none such is exposed. Yet, if
> you argue with APIs like WaitForEvent, something has to signal it. In a
> simple environment this would mean, some timer event is running and may
> signal the event the main code waits for, where above's concern actually
> do apply. :) Again, the recommendation assumes the use-cases are simple
> enough to easily avoid them.
>
> I think it would be best to sketch use-cases for audio and design the
> solutions closely to the requirements. Why do we need to know when audio
> finished? What will happen when we queue audio twice? There are many
> layers (UX, interface, implementation details) of questions to coming up
> with a pleasant and stable design.
>
> Best regards,
> Marvin
>
>>
>> Thanks,
>>
>> Andrew Fish.
>>
>>> If I remember correctly you mentioned the UEFI Talkbox before, if
>>> that is more convenient for you, I'm there as mhaeuser.
>>>
>>> Best regards,
>>> Marvin
>>>
>>>>
>>>> On 4/16/21, Andrew Fish <afish@apple.com <mailto:afish@apple.com>>
>>>> wrote:
>>>>>
>>>>>> On Apr 16, 2021, at 4:34 AM, Leif Lindholm <leif@nuviainc.com
>>>>>> <mailto:leif@nuviainc.com>> wrote:
>>>>>>
>>>>>> Hi Ethin,
>>>>>>
>>>>>> I think we also want to have a SetMode function, even if we don't get
>>>>>> around to implement proper support for it as part of GSoC (although I
>>>>>> expect at least for virtio, that should be pretty straightforward).
>>>>>>
>>>>> Leif,
>>>>>
>>>>> I’m think if we have an API to load the buffer and a 2nd API to
>>>>> play the
>>>>> buffer an optional 3rd API could configure the streams.
>>>>>
>>>>>> It's quite likely that speech for UI would be stored as 8kHz (or
>>>>>> 20kHz) in some systems, whereas the example for playing a tune in
>>>>>> GRUB
>>>>>> would more likely be a 44.1 kHz mp3/wav/ogg/flac.
>>>>>>
>>>>>> For the GSoC project, I think it would be quite reasonable to
>>>>>> pre-generate pure PCM streams for testing rather than decoding
>>>>>> anything on the fly.
>>>>>>
>>>>>> Porting/writing decoders is really a separate task from enabling the
>>>>>> output. I would much rather see USB *and* HDA support able to play
>>>>>> pcm
>>>>>> streams before worrying about decoding.
>>>>>>
>>>>> I agree it might turn out it is easier to have the text to speech
>>>>> code just
>>>>> encode a PCM directly.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Andrew Fish
>>>>>
>>>>>> /
>>>>>>    Leif
>>>>>>
>>>>>> On Fri, Apr 16, 2021 at 00:33:06 -0500, Ethin Probst wrote:
>>>>>>> Thanks for that explanation (I missed Mike's message). Earlier I
>>>>>>> sent
>>>>>>> a summary of those things that we can agree on: mainly, that we have
>>>>>>> mute, volume control, a load buffer, (maybe) an unload buffer, and a
>>>>>>> start/stop stream function. Now that I fully understand the
>>>>>>> ramifications of this I don't mind settling for a specific format
>>>>>>> and
>>>>>>> sample rate, and signed 16-bit PCM audio is, I think, the most
>>>>>>> widely
>>>>>>> used one out there, besides 64-bit floating point samples, which
>>>>>>> I've
>>>>>>> only seen used in DAWs, and that's something we don't need.
>>>>>>> Are you sure you want the firmware itself to handle the decoding of
>>>>>>> WAV audio? I can make a library class for that, but I'll definitely
>>>>>>> need help with the security aspect.
>>>>>>>
>>>>>>> On 4/16/21, Andrew Fish via groups.io <http://groups.io>
>>>>>>> <afish=apple.com@groups.io <mailto:afish=apple.com@groups.io>>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On Apr 15, 2021, at 5:59 PM, Michael Brown <mcb30@ipxe.org
>>>>>>>>> <mailto:mcb30@ipxe.org>> wrote:
>>>>>>>>>
>>>>>>>>> On 16/04/2021 00:42, Ethin Probst wrote:
>>>>>>>>>> Forcing a particular channel mapping, sample rate and sample
>>>>>>>>>> format
>>>>>>>>>> on
>>>>>>>>>> everyone would complicate application code. From an
>>>>>>>>>> application point
>>>>>>>>>> of view, one would, with that type of protocol, need to do the
>>>>>>>>>> following:
>>>>>>>>>> 1) Load an audio file in any audio file format from any storage
>>>>>>>>>> mechanism.
>>>>>>>>>> 2) Decode the audio file format to extract the samples and audio
>>>>>>>>>> metadata.
>>>>>>>>>> 3) Resample the (now decoded) audio samples and convert
>>>>>>>>>> (quantize)
>>>>>>>>>> the
>>>>>>>>>> audio samples into signed 16-bit PCM audio.
>>>>>>>>>> 4) forward the samples onto the EFI audio protocol.
>>>>>>>>> You have made an incorrect assumption that there exists a
>>>>>>>>> requirement
>>>>>>>>> to
>>>>>>>>> be able to play audio files in arbitrary formats.  This
>>>>>>>>> requirement
>>>>>>>>> does
>>>>>>>>> not exist.
>>>>>>>>>
>>>>>>>>> With a protocol-mandated fixed baseline set of audio parameters
>>>>>>>>> (sample
>>>>>>>>> rate etc), what would happen in practice is that the audio
>>>>>>>>> files would
>>>>>>>>> be
>>>>>>>>> encoded in that format at *build* time, using tools entirely
>>>>>>>>> external
>>>>>>>>> to
>>>>>>>>> UEFI.  The application code is then trivially simple: it just does
>>>>>>>>> "load
>>>>>>>>> blob, pass blob to audio protocol".
>>>>>>>>>
>>>>>>>>
>>>>>>>> Ethin,
>>>>>>>>
>>>>>>>> Given the goal is an industry standard we value interoperability
>>>>>>>> more
>>>>>>>> that
>>>>>>>> flexibility.
>>>>>>>>
>>>>>>>> How about another use case. Lets say the Linux OS loader (Grub)
>>>>>>>> wants
>>>>>>>> to
>>>>>>>> have an accessible UI so it decides to sore sound files on the EFI
>>>>>>>> System
>>>>>>>> Partition and use our new fancy UEFI Audio Protocol to add audio
>>>>>>>> to the
>>>>>>>> OS
>>>>>>>> loader GUI. So that version of Grub needs to work on 1,000 of
>>>>>>>> different
>>>>>>>> PCs
>>>>>>>> and a wide range of UEFI Audio driver implementations. It is a much
>>>>>>>> easier
>>>>>>>> world if Wave PCM 16 bit just works every place. You could add a
>>>>>>>> lot of
>>>>>>>> complexity and try to encode the audio on the fly, maybe even in
>>>>>>>> Linux
>>>>>>>> proper but that falls down if you are booting from read only
>>>>>>>> media like
>>>>>>>> a
>>>>>>>> DVD or backup tape (yes people still do that in server land).
>>>>>>>>
>>>>>>>> The other problem with flexibility is you just made the test matrix
>>>>>>>> very
>>>>>>>> large for every driver that needs to get implemented. For
>>>>>>>> something as
>>>>>>>> complex as Intel HDA how you hook up the hardware and what
>>>>>>>> CODECs you
>>>>>>>> use
>>>>>>>> may impact the quality of the playback for a given board. Your
>>>>>>>> EFI is
>>>>>>>> likely
>>>>>>>> going to pick a single encoding at that will get tested all the
>>>>>>>> time if
>>>>>>>> your
>>>>>>>> system has audio, but all 50 other things you support not so
>>>>>>>> much. So
>>>>>>>> that
>>>>>>>> will required testing, and some one with audiophile ears (or an AI
>>>>>>>> program)
>>>>>>>> to test all the combinations. I’m not kidding I get BZs on the
>>>>>>>> quality
>>>>>>>> of
>>>>>>>> the boot bong on our systems.
>>>>>>>>
>>>>>>>>
>>>>>>>>>> typedef struct EFI_SIMPLE_AUDIO_PROTOCOL {
>>>>>>>>>>  EFI_SIMPLE_AUDIO_PROTOCOL_RESET Reset;
>>>>>>>>>>  EFI_SIMPLE_AUDIO_PROTOCOL_START Start;
>>>>>>>>>>  EFI_SIMPLE_AUDIO_PROTOCOL_STOP Stop;
>>>>>>>>>> } EFI_SIMPLE_AUDIO_PROTOCOL;
>>>>>>>>> This is now starting to look like something that belongs in
>>>>>>>>> boot-time
>>>>>>>>> firmware.  :)
>>>>>>>>>
>>>>>>>> I think that got a little too simple I’d go back and look at the
>>>>>>>> example
>>>>>>>> I
>>>>>>>> posted to the thread but add an API to load the buffer, and then
>>>>>>>> play
>>>>>>>> the
>>>>>>>> buffer (that way we can an API in the future to twiddle knobs).
>>>>>>>> That
>>>>>>>> API
>>>>>>>> also implements the async EFI interface. Trust me the 1st thing
>>>>>>>> that is
>>>>>>>> going to happen when we add audio is some one is going to
>>>>>>>> complain in
>>>>>>>> xyz
>>>>>>>> state we should mute audio, or we should honer audio volume and
>>>>>>>> mute
>>>>>>>> settings from setup, or from values set in the OS. Or some one
>>>>>>>> is going
>>>>>>>> to
>>>>>>>> want the volume keys on the keyboard to work in EFI.
>>>>>>>>
>>>>>>>> Also if you need to pick apart the Wave PCM 16 byte file to feed
>>>>>>>> it into
>>>>>>>> the
>>>>>>>> audio hardware that probably means we should have a library that
>>>>>>>> does
>>>>>>>> that
>>>>>>>> work, so other Audio drivers can share that code. Also having a
>>>>>>>> library
>>>>>>>> makes it easier to write a unit test. We need to be security
>>>>>>>> conscious
>>>>>>>> as we
>>>>>>>> need to treat the Audo file as attacker controlled data.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Andrew Fish
>>>>>>>>
>>>>>>>>> Michael
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Signed,
>>>>>>> Ethin D. Probst
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>> 
>
>


-- 
Signed,
Ethin D. Probst

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Andrew Fish]

[-- Attachment #1: Type: text/plain, Size: 18782 bytes --]



> On Apr 18, 2021, at 1:55 AM, Ethin Probst <harlydavidsen@gmail.com> wrote:
> 
>> I think it would be best to sketch use-cases for audio and design the solutions closely to the requirements. Why do we need to know when audio finished? What will happen when we queue audio twice? There are many layers (UX, interface, implementation details) of questions to coming up with a pleasant and stable design.

We are not using EFI to listen to music in the background. Any audio being played is part of a UI element and there might be synchronization requirements. 

For example playing a boot bong on boot you want that to be asynchronous as you don’t want to delay boot to play the sound, but you may want to chose to gate some UI elements on the boot bong completing. If you are building a menu UI that is accessible you may need to synchronize playback with UI update, but you may not want to make the slow sound playback blocking as you can get other UI work done in parallel. 

The overhead for a caller making an async call is not much [1], but not having the capability could really restrict the API for its intended use. I’d also point out we picked the same pattern as the async BlockIO and there is something to said for having consistency in the UEFI Spec and have similar APIs work in similar ways. 

[1] Overhead for making an asynchronous call. 
AUDIO_TOKEN AudioToken;
gBS->CreateEvent  (EVT_NOTIFY_SIGNAL, TPL_CALLBACK, NULL, NULL, &AudioToken.Event);

Thanks,

Andrew Fish

> I would be happy to discuss this with you on the UEFI talkbox. I'm
> draeand on there.
> As for your questions:
> 
> 1. The only reason I recommend using an event to signal audio
> completion is because I do not want this protocol to be blocking at
> all. (So, perhaps removing the token entirely is a good idea.) The
> VirtIO audio device says nothing about synchronization, but I imagine
> its asynchronous because every audio specification I've seen out there
> is asynchronous. Similarly, every audio API in existence -- at least,
> every low-level OS-specific one -- is asynchronous/non-blocking.
> (Usually, audio processing is handled on a separate thread.) However,
> UEFI has no concept of threads or processes. Though we could use the
> MP PI package to spin up a separate processor, that would fail on
> uniprocessor, unicore systems. Audio processing needs a high enough
> priority that it gets first in the list of tasks served while
> simultaneously not getting a priority that's so high that it blocks
> everything else. This is primarily because of the way an audio
> subsystem is designed and the way an audio device functions: the audio
> subsystem needs to know, immediately, when the audio buffer has ran
> out of samples and needs more, and it needs to react immediately to
> refill the buffer if required, especially when streaming large amounts
> of audio (e.g.: music). Similarly, the audio subsystem needs the
> ability to react as soon as is viable when playback is requested,
> because any significant delay will be noticeable by the end-user. In
> more complex systems like FMOD or OpenAL, the audio processing thread
> also needs a high priority to ensure that audio effects, positioning
> information, dithering, etc., can be configured immediately because
> the user will notice if any glitches or delays occur. The UEFI audio
> protocols obviously will be nowhere near as complex, or as advanced,
> because no one will need audio effects in a preboot environment.
> Granted, its possible to make small audio effects, for example delays,
> even if the protocol doesn't have functions to do that, but if an
> end-user wants to go absolutely crazy with the audio samples and mix
> in a really nice-sounding reverb or audio filter before sending the
> samples to the audio engine, well, that's what they want to do and
> that's out of our hands as driver/protocol developers. But I digress.
> UEFI only has four TPLs, and so what we hopefully want is an engine
> that is able to manage sample buffering and transmission, but also
> doesn't block the application that's using the protocol. For some
> things, blocking might be acceptable, but for speech synthesis or the
> playing of startup sounds, this would not be an acceptable result and
> would make the protocol pretty much worthless in the majority of
> scenarios. So that's why I had an event to signal audio completion --
> it was (perhaps) a cheap hack around the cooperatively-scheduled task
> architecture of UEFI. (At least, I think its cooperative multitasking,
> correct me if I'm wrong.)
> 2. The VirtIO specification does not specify what occurs in the event
> that a request is received to play a stream that's already being
> played. However, it does provide enough information for extrapolation.
> Every request that's sent to a VirtIO sound device must come with two
> things: a stream ID and a buffer of samples. The sample data must
> immediately follow the request. Therefore, for VirtIO in particular,
> the device will simply stop playing the old set of samples and play
> the new set instead. This goes along with what I've seen in other
> specifications like the HDA one: unless the device in question
> supports more than one stream, it is impossible to play two sounds on
> a single stream simultaneously, and an HDA controller (for example) is
> not going to perform any mixing; mixing is done purely in software.
> Similarly, if a device does support multiple streams, it is
> unspecified whether the device will play two or more streams
> simultaneously or whether it will pause/abort the playback of one
> while it plays another. Therefore, I believe (though cannot confirm)
> that OSes like Windows simply use a single stream, even if the device
> supports multiple streams, and just makes the applications believe
> that unlimited streams are possible.
> 
> I apologize for this really long-winded email, and I hope no one minds. :-)
> 
> On 4/17/21, Marvin Häuser <mhaeuser@posteo.de <mailto:mhaeuser@posteo.de>> wrote:
>> On 17.04.21 19:31, Andrew Fish via groups.io wrote:
>>> 
>>> 
>>>> On Apr 17, 2021, at 9:51 AM, Marvin Häuser <mhaeuser@posteo.de
>>>> <mailto:mhaeuser@posteo.de>> wrote:
>>>> 
>>>> On 16.04.21 19:45, Ethin Probst wrote:
>>>>> Yes, three APIs (maybe like this) would work well:
>>>>> - Start, Stop: begin playback of a stream
>>>>> - SetVolume, GetVolume, Mute, Unmute: control volume of output and
>>>>> enable muting
>>>>> - CreateStream, ReleaseStream, SetStreamSampleRate: Control sample
>>>>> rate of stream (but not sample format since Signed 16-bit PCM is
>>>>> enough)
>>>>> Marvin, how do you suggest we make the events then? We need some way
>>>>> of notifying the caller that the stream has concluded. We could make
>>>>> the driver create the event and pass it back to the caller as an
>>>>> event, but you'd still have dangling pointers (this is C, after all).
>>>>> We could just make a IsPlaying() function and WaitForCompletion()
>>>>> function and allow the driver to do the event handling -- would that
>>>>> work?
>>>> 
>>>> I do not know enough about the possible use-cases to tell. Aside from
>>>> the two functions you already mentioned, you could also take in an
>>>> (optional) notification function.
>>>> Which possible use-cases does determining playback end have? If it's
>>>> too much effort, just use EFI_EVENT I guess, just the less code can
>>>> mess it up, the better.
>>>> 
>>> 
>>> In UEFI EFI_EVENT works much better. There is a gBS-WaitForEvent()
>>> function that lets a caller wait on an event. That is basically what
>>> the UEFI Shell is doing at the Shell prompt. A GUI in UEFI/C is
>>> basically an event loop.
>>> 
>>> Fun fact: I ended up adding gIdleLoopEventGuid to the MdeModulePkg so
>>> the DXE Core could signal gIdleLoopEventGuid if you are sitting in
>>> gBS-WaitForEvent() and no event is signaled. Basically in EFI nothing
>>> is going to happen until the next timer tick so the gIdleLoopEventGuid
>>> lets you idle the CPU until the next timer tick. I was forced to do
>>> this as the 1st MacBook Air had a bad habit of thermal tripping when
>>> sitting at the UEFI Shell prompt. After all another name for a loop in
>>> C code running on bare metal is a power virus.
>> 
>> Mac EFI is one of the best implementations we know of, frankly. I'm
>> traumatised by Aptio 4 and alike, where (some issues are OEM-specific I
>> think) you can have timer events signalling after ExitBS, there is event
>> clutter on IO polling to the point where everything lags no matter what
>> you do, and even in "smooth" scenarios there may be nothing worth the
>> description "granularity" (events scheduled to run every 10 ms may run
>> every 50 ms). Events are the last resort for us, if there really is no
>> other way. My first GUI implementation worked without events at all for
>> this reason, but as our workarounds got better, we did start using them
>> for keyboard and mouse polling.
>> 
>> Timers do not apply here, but what does apply is resource management.
>> Using EFI_EVENT directly means (to the outside) the introduction of a
>> new resource to maintain, for each caller separately. On the other side,
>> there is no resource to misuse or leak if none such is exposed. Yet, if
>> you argue with APIs like WaitForEvent, something has to signal it. In a
>> simple environment this would mean, some timer event is running and may
>> signal the event the main code waits for, where above's concern actually
>> do apply. :) Again, the recommendation assumes the use-cases are simple
>> enough to easily avoid them.
>> 
>> I think it would be best to sketch use-cases for audio and design the
>> solutions closely to the requirements. Why do we need to know when audio
>> finished? What will happen when we queue audio twice? There are many
>> layers (UX, interface, implementation details) of questions to coming up
>> with a pleasant and stable design.
>> 
>> Best regards,
>> Marvin
>> 
>>> 
>>> Thanks,
>>> 
>>> Andrew Fish.
>>> 
>>>> If I remember correctly you mentioned the UEFI Talkbox before, if
>>>> that is more convenient for you, I'm there as mhaeuser.
>>>> 
>>>> Best regards,
>>>> Marvin
>>>> 
>>>>> 
>>>>> On 4/16/21, Andrew Fish <afish@apple.com <mailto:afish@apple.com>>
>>>>> wrote:
>>>>>> 
>>>>>>> On Apr 16, 2021, at 4:34 AM, Leif Lindholm <leif@nuviainc.com
>>>>>>> <mailto:leif@nuviainc.com>> wrote:
>>>>>>> 
>>>>>>> Hi Ethin,
>>>>>>> 
>>>>>>> I think we also want to have a SetMode function, even if we don't get
>>>>>>> around to implement proper support for it as part of GSoC (although I
>>>>>>> expect at least for virtio, that should be pretty straightforward).
>>>>>>> 
>>>>>> Leif,
>>>>>> 
>>>>>> I’m think if we have an API to load the buffer and a 2nd API to
>>>>>> play the
>>>>>> buffer an optional 3rd API could configure the streams.
>>>>>> 
>>>>>>> It's quite likely that speech for UI would be stored as 8kHz (or
>>>>>>> 20kHz) in some systems, whereas the example for playing a tune in
>>>>>>> GRUB
>>>>>>> would more likely be a 44.1 kHz mp3/wav/ogg/flac.
>>>>>>> 
>>>>>>> For the GSoC project, I think it would be quite reasonable to
>>>>>>> pre-generate pure PCM streams for testing rather than decoding
>>>>>>> anything on the fly.
>>>>>>> 
>>>>>>> Porting/writing decoders is really a separate task from enabling the
>>>>>>> output. I would much rather see USB *and* HDA support able to play
>>>>>>> pcm
>>>>>>> streams before worrying about decoding.
>>>>>>> 
>>>>>> I agree it might turn out it is easier to have the text to speech
>>>>>> code just
>>>>>> encode a PCM directly.
>>>>>> 
>>>>>> Thanks,
>>>>>> 
>>>>>> Andrew Fish
>>>>>> 
>>>>>>> /
>>>>>>>    Leif
>>>>>>> 
>>>>>>> On Fri, Apr 16, 2021 at 00:33:06 -0500, Ethin Probst wrote:
>>>>>>>> Thanks for that explanation (I missed Mike's message). Earlier I
>>>>>>>> sent
>>>>>>>> a summary of those things that we can agree on: mainly, that we have
>>>>>>>> mute, volume control, a load buffer, (maybe) an unload buffer, and a
>>>>>>>> start/stop stream function. Now that I fully understand the
>>>>>>>> ramifications of this I don't mind settling for a specific format
>>>>>>>> and
>>>>>>>> sample rate, and signed 16-bit PCM audio is, I think, the most
>>>>>>>> widely
>>>>>>>> used one out there, besides 64-bit floating point samples, which
>>>>>>>> I've
>>>>>>>> only seen used in DAWs, and that's something we don't need.
>>>>>>>> Are you sure you want the firmware itself to handle the decoding of
>>>>>>>> WAV audio? I can make a library class for that, but I'll definitely
>>>>>>>> need help with the security aspect.
>>>>>>>> 
>>>>>>>> On 4/16/21, Andrew Fish via groups.io <http://groups.io>
>>>>>>>> <afish=apple.com@groups.io <mailto:afish=apple.com@groups.io>>
>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> On Apr 15, 2021, at 5:59 PM, Michael Brown <mcb30@ipxe.org
>>>>>>>>>> <mailto:mcb30@ipxe.org>> wrote:
>>>>>>>>>> 
>>>>>>>>>> On 16/04/2021 00:42, Ethin Probst wrote:
>>>>>>>>>>> Forcing a particular channel mapping, sample rate and sample
>>>>>>>>>>> format
>>>>>>>>>>> on
>>>>>>>>>>> everyone would complicate application code. From an
>>>>>>>>>>> application point
>>>>>>>>>>> of view, one would, with that type of protocol, need to do the
>>>>>>>>>>> following:
>>>>>>>>>>> 1) Load an audio file in any audio file format from any storage
>>>>>>>>>>> mechanism.
>>>>>>>>>>> 2) Decode the audio file format to extract the samples and audio
>>>>>>>>>>> metadata.
>>>>>>>>>>> 3) Resample the (now decoded) audio samples and convert
>>>>>>>>>>> (quantize)
>>>>>>>>>>> the
>>>>>>>>>>> audio samples into signed 16-bit PCM audio.
>>>>>>>>>>> 4) forward the samples onto the EFI audio protocol.
>>>>>>>>>> You have made an incorrect assumption that there exists a
>>>>>>>>>> requirement
>>>>>>>>>> to
>>>>>>>>>> be able to play audio files in arbitrary formats.  This
>>>>>>>>>> requirement
>>>>>>>>>> does
>>>>>>>>>> not exist.
>>>>>>>>>> 
>>>>>>>>>> With a protocol-mandated fixed baseline set of audio parameters
>>>>>>>>>> (sample
>>>>>>>>>> rate etc), what would happen in practice is that the audio
>>>>>>>>>> files would
>>>>>>>>>> be
>>>>>>>>>> encoded in that format at *build* time, using tools entirely
>>>>>>>>>> external
>>>>>>>>>> to
>>>>>>>>>> UEFI.  The application code is then trivially simple: it just does
>>>>>>>>>> "load
>>>>>>>>>> blob, pass blob to audio protocol".
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Ethin,
>>>>>>>>> 
>>>>>>>>> Given the goal is an industry standard we value interoperability
>>>>>>>>> more
>>>>>>>>> that
>>>>>>>>> flexibility.
>>>>>>>>> 
>>>>>>>>> How about another use case. Lets say the Linux OS loader (Grub)
>>>>>>>>> wants
>>>>>>>>> to
>>>>>>>>> have an accessible UI so it decides to sore sound files on the EFI
>>>>>>>>> System
>>>>>>>>> Partition and use our new fancy UEFI Audio Protocol to add audio
>>>>>>>>> to the
>>>>>>>>> OS
>>>>>>>>> loader GUI. So that version of Grub needs to work on 1,000 of
>>>>>>>>> different
>>>>>>>>> PCs
>>>>>>>>> and a wide range of UEFI Audio driver implementations. It is a much
>>>>>>>>> easier
>>>>>>>>> world if Wave PCM 16 bit just works every place. You could add a
>>>>>>>>> lot of
>>>>>>>>> complexity and try to encode the audio on the fly, maybe even in
>>>>>>>>> Linux
>>>>>>>>> proper but that falls down if you are booting from read only
>>>>>>>>> media like
>>>>>>>>> a
>>>>>>>>> DVD or backup tape (yes people still do that in server land).
>>>>>>>>> 
>>>>>>>>> The other problem with flexibility is you just made the test matrix
>>>>>>>>> very
>>>>>>>>> large for every driver that needs to get implemented. For
>>>>>>>>> something as
>>>>>>>>> complex as Intel HDA how you hook up the hardware and what
>>>>>>>>> CODECs you
>>>>>>>>> use
>>>>>>>>> may impact the quality of the playback for a given board. Your
>>>>>>>>> EFI is
>>>>>>>>> likely
>>>>>>>>> going to pick a single encoding at that will get tested all the
>>>>>>>>> time if
>>>>>>>>> your
>>>>>>>>> system has audio, but all 50 other things you support not so
>>>>>>>>> much. So
>>>>>>>>> that
>>>>>>>>> will required testing, and some one with audiophile ears (or an AI
>>>>>>>>> program)
>>>>>>>>> to test all the combinations. I’m not kidding I get BZs on the
>>>>>>>>> quality
>>>>>>>>> of
>>>>>>>>> the boot bong on our systems.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>>> typedef struct EFI_SIMPLE_AUDIO_PROTOCOL {
>>>>>>>>>>>  EFI_SIMPLE_AUDIO_PROTOCOL_RESET Reset;
>>>>>>>>>>>  EFI_SIMPLE_AUDIO_PROTOCOL_START Start;
>>>>>>>>>>>  EFI_SIMPLE_AUDIO_PROTOCOL_STOP Stop;
>>>>>>>>>>> } EFI_SIMPLE_AUDIO_PROTOCOL;
>>>>>>>>>> This is now starting to look like something that belongs in
>>>>>>>>>> boot-time
>>>>>>>>>> firmware.  :)
>>>>>>>>>> 
>>>>>>>>> I think that got a little too simple I’d go back and look at the
>>>>>>>>> example
>>>>>>>>> I
>>>>>>>>> posted to the thread but add an API to load the buffer, and then
>>>>>>>>> play
>>>>>>>>> the
>>>>>>>>> buffer (that way we can an API in the future to twiddle knobs).
>>>>>>>>> That
>>>>>>>>> API
>>>>>>>>> also implements the async EFI interface. Trust me the 1st thing
>>>>>>>>> that is
>>>>>>>>> going to happen when we add audio is some one is going to
>>>>>>>>> complain in
>>>>>>>>> xyz
>>>>>>>>> state we should mute audio, or we should honer audio volume and
>>>>>>>>> mute
>>>>>>>>> settings from setup, or from values set in the OS. Or some one
>>>>>>>>> is going
>>>>>>>>> to
>>>>>>>>> want the volume keys on the keyboard to work in EFI.
>>>>>>>>> 
>>>>>>>>> Also if you need to pick apart the Wave PCM 16 byte file to feed
>>>>>>>>> it into
>>>>>>>>> the
>>>>>>>>> audio hardware that probably means we should have a library that
>>>>>>>>> does
>>>>>>>>> that
>>>>>>>>> work, so other Audio drivers can share that code. Also having a
>>>>>>>>> library
>>>>>>>>> makes it easier to write a unit test. We need to be security
>>>>>>>>> conscious
>>>>>>>>> as we
>>>>>>>>> need to treat the Audo file as attacker controlled data.
>>>>>>>>> 
>>>>>>>>> Thanks,
>>>>>>>>> 
>>>>>>>>> Andrew Fish
>>>>>>>>> 
>>>>>>>>>> Michael
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> --
>>>>>>>> Signed,
>>>>>>>> Ethin D. Probst
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
> 
> 
> -- 
> Signed,
> Ethin D. Probst


[-- Attachment #2: Type: text/html, Size: 75006 bytes --]

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Marvin Häuser]

On 18.04.21 17:22, Andrew Fish via groups.io wrote:
>
>
>> On Apr 18, 2021, at 1:55 AM, Ethin Probst <harlydavidsen@gmail.com 
>> <mailto:harlydavidsen@gmail.com>> wrote:
>>
>>> I think it would be best to sketch use-cases for audio and design 
>>> the solutions closely to the requirements. Why do we need to know 
>>> when audio finished? What will happen when we queue audio twice? 
>>> There are many layers (UX, interface, implementation details) of 
>>> questions to coming up with a pleasant and stable design.
>
> We are not using EFI to listen to music in the background. Any audio 
> being played is part of a UI element and there might be 
> synchronization requirements.

Maybe I communicated that wrong, I'm not asking because I don't know 
what audio is used for, I am saying ideally there is a written-down list 
of usage requirements before the protocol is designed, because that is 
what the design targets. The details should follow the needs.

>
> For example playing a boot bong on boot you want that to be 
> asynchronous as you don’t want to delay boot to play the sound, but 
> you may want to chose to gate some UI elements on the boot bong 
> completing. If you are building a menu UI that is accessible you may 
> need to synchronize playback with UI update, but you may not want to 
> make the slow sound playback blocking as you can get other UI work 
> done in parallel.
>
> The overhead for a caller making an async call is not much [1], but 
> not having the capability could really restrict the API for its 
> intended use. I’d also point out we picked the same pattern as the 
> async BlockIO and there is something to said for having consistency in 
> the UEFI Spec and have similar APIs work in similar ways.

I'm not saying there should be *no* async playback, I am saying it may 
be worth considering implementing it differently from caller-owned 
events. I'm not concerned with overhead, I'm concerned with points of 
failure (e.g. leaks).

I very briefly discussed some things with Ethin and it seems like the 
default EDK II timer interval of 10 ms may be problematic, but I am not 
sure. Just leaving it here as something to keep it mind.

Best regards,
Marvin

>
> [1] Overhead for making an asynchronous call.
> AUDIO_TOKEN AudioToken;
> gBS->CreateEvent  (EVT_NOTIFY_SIGNAL, TPL_CALLBACK, NULL, NULL, 
> &AudioToken.Event);
>
> Thanks,
>
> Andrew Fish
>
>> I would be happy to discuss this with you on the UEFI talkbox. I'm
>> draeand on there.
>> As for your questions:
>>
>> 1. The only reason I recommend using an event to signal audio
>> completion is because I do not want this protocol to be blocking at
>> all. (So, perhaps removing the token entirely is a good idea.) The
>> VirtIO audio device says nothing about synchronization, but I imagine
>> its asynchronous because every audio specification I've seen out there
>> is asynchronous. Similarly, every audio API in existence -- at least,
>> every low-level OS-specific one -- is asynchronous/non-blocking.
>> (Usually, audio processing is handled on a separate thread.) However,
>> UEFI has no concept of threads or processes. Though we could use the
>> MP PI package to spin up a separate processor, that would fail on
>> uniprocessor, unicore systems. Audio processing needs a high enough
>> priority that it gets first in the list of tasks served while
>> simultaneously not getting a priority that's so high that it blocks
>> everything else. This is primarily because of the way an audio
>> subsystem is designed and the way an audio device functions: the audio
>> subsystem needs to know, immediately, when the audio buffer has ran
>> out of samples and needs more, and it needs to react immediately to
>> refill the buffer if required, especially when streaming large amounts
>> of audio (e.g.: music). Similarly, the audio subsystem needs the
>> ability to react as soon as is viable when playback is requested,
>> because any significant delay will be noticeable by the end-user. In
>> more complex systems like FMOD or OpenAL, the audio processing thread
>> also needs a high priority to ensure that audio effects, positioning
>> information, dithering, etc., can be configured immediately because
>> the user will notice if any glitches or delays occur. The UEFI audio
>> protocols obviously will be nowhere near as complex, or as advanced,
>> because no one will need audio effects in a preboot environment.
>> Granted, its possible to make small audio effects, for example delays,
>> even if the protocol doesn't have functions to do that, but if an
>> end-user wants to go absolutely crazy with the audio samples and mix
>> in a really nice-sounding reverb or audio filter before sending the
>> samples to the audio engine, well, that's what they want to do and
>> that's out of our hands as driver/protocol developers. But I digress.
>> UEFI only has four TPLs, and so what we hopefully want is an engine
>> that is able to manage sample buffering and transmission, but also
>> doesn't block the application that's using the protocol. For some
>> things, blocking might be acceptable, but for speech synthesis or the
>> playing of startup sounds, this would not be an acceptable result and
>> would make the protocol pretty much worthless in the majority of
>> scenarios. So that's why I had an event to signal audio completion --
>> it was (perhaps) a cheap hack around the cooperatively-scheduled task
>> architecture of UEFI. (At least, I think its cooperative multitasking,
>> correct me if I'm wrong.)
>> 2. The VirtIO specification does not specify what occurs in the event
>> that a request is received to play a stream that's already being
>> played. However, it does provide enough information for extrapolation.
>> Every request that's sent to a VirtIO sound device must come with two
>> things: a stream ID and a buffer of samples. The sample data must
>> immediately follow the request. Therefore, for VirtIO in particular,
>> the device will simply stop playing the old set of samples and play
>> the new set instead. This goes along with what I've seen in other
>> specifications like the HDA one: unless the device in question
>> supports more than one stream, it is impossible to play two sounds on
>> a single stream simultaneously, and an HDA controller (for example) is
>> not going to perform any mixing; mixing is done purely in software.
>> Similarly, if a device does support multiple streams, it is
>> unspecified whether the device will play two or more streams
>> simultaneously or whether it will pause/abort the playback of one
>> while it plays another. Therefore, I believe (though cannot confirm)
>> that OSes like Windows simply use a single stream, even if the device
>> supports multiple streams, and just makes the applications believe
>> that unlimited streams are possible.
>>
>> I apologize for this really long-winded email, and I hope no one 
>> minds. :-)
>>
>> On 4/17/21, Marvin Häuser <mhaeuser@posteo.de 
>> <mailto:mhaeuser@posteo.de>> wrote:
>>> On 17.04.21 19:31, Andrew Fish via groups.io <http://groups.io> wrote:
>>>>
>>>>
>>>>> On Apr 17, 2021, at 9:51 AM, Marvin Häuser <mhaeuser@posteo.de 
>>>>> <mailto:mhaeuser@posteo.de>
>>>>> <mailto:mhaeuser@posteo.de <mailto:mhaeuser@posteo.de>>> wrote:
>>>>>
>>>>> On 16.04.21 19:45, Ethin Probst wrote:
>>>>>> Yes, three APIs (maybe like this) would work well:
>>>>>> - Start, Stop: begin playback of a stream
>>>>>> - SetVolume, GetVolume, Mute, Unmute: control volume of output and
>>>>>> enable muting
>>>>>> - CreateStream, ReleaseStream, SetStreamSampleRate: Control sample
>>>>>> rate of stream (but not sample format since Signed 16-bit PCM is
>>>>>> enough)
>>>>>> Marvin, how do you suggest we make the events then? We need some way
>>>>>> of notifying the caller that the stream has concluded. We could make
>>>>>> the driver create the event and pass it back to the caller as an
>>>>>> event, but you'd still have dangling pointers (this is C, after all).
>>>>>> We could just make a IsPlaying() function and WaitForCompletion()
>>>>>> function and allow the driver to do the event handling -- would that
>>>>>> work?
>>>>>
>>>>> I do not know enough about the possible use-cases to tell. Aside from
>>>>> the two functions you already mentioned, you could also take in an
>>>>> (optional) notification function.
>>>>> Which possible use-cases does determining playback end have? If it's
>>>>> too much effort, just use EFI_EVENT I guess, just the less code can
>>>>> mess it up, the better.
>>>>>
>>>>
>>>> In UEFI EFI_EVENT works much better. There is a gBS-WaitForEvent()
>>>> function that lets a caller wait on an event. That is basically what
>>>> the UEFI Shell is doing at the Shell prompt. A GUI in UEFI/C is
>>>> basically an event loop.
>>>>
>>>> Fun fact: I ended up adding gIdleLoopEventGuid to the MdeModulePkg so
>>>> the DXE Core could signal gIdleLoopEventGuid if you are sitting in
>>>> gBS-WaitForEvent() and no event is signaled. Basically in EFI nothing
>>>> is going to happen until the next timer tick so the gIdleLoopEventGuid
>>>> lets you idle the CPU until the next timer tick. I was forced to do
>>>> this as the 1st MacBook Air had a bad habit of thermal tripping when
>>>> sitting at the UEFI Shell prompt. After all another name for a loop in
>>>> C code running on bare metal is a power virus.
>>>
>>> Mac EFI is one of the best implementations we know of, frankly. I'm
>>> traumatised by Aptio 4 and alike, where (some issues are OEM-specific I
>>> think) you can have timer events signalling after ExitBS, there is event
>>> clutter on IO polling to the point where everything lags no matter what
>>> you do, and even in "smooth" scenarios there may be nothing worth the
>>> description "granularity" (events scheduled to run every 10 ms may run
>>> every 50 ms). Events are the last resort for us, if there really is no
>>> other way. My first GUI implementation worked without events at all for
>>> this reason, but as our workarounds got better, we did start using them
>>> for keyboard and mouse polling.
>>>
>>> Timers do not apply here, but what does apply is resource management.
>>> Using EFI_EVENT directly means (to the outside) the introduction of a
>>> new resource to maintain, for each caller separately. On the other side,
>>> there is no resource to misuse or leak if none such is exposed. Yet, if
>>> you argue with APIs like WaitForEvent, something has to signal it. In a
>>> simple environment this would mean, some timer event is running and may
>>> signal the event the main code waits for, where above's concern actually
>>> do apply. :) Again, the recommendation assumes the use-cases are simple
>>> enough to easily avoid them.
>>>
>>> I think it would be best to sketch use-cases for audio and design the
>>> solutions closely to the requirements. Why do we need to know when audio
>>> finished? What will happen when we queue audio twice? There are many
>>> layers (UX, interface, implementation details) of questions to coming up
>>> with a pleasant and stable design.
>>>
>>> Best regards,
>>> Marvin
>>>
>>>>
>>>> Thanks,
>>>>
>>>> Andrew Fish.
>>>>
>>>>> If I remember correctly you mentioned the UEFI Talkbox before, if
>>>>> that is more convenient for you, I'm there as mhaeuser.
>>>>>
>>>>> Best regards,
>>>>> Marvin
>>>>>
>>>>>>
>>>>>> On 4/16/21, Andrew Fish <afish@apple.com <mailto:afish@apple.com> 
>>>>>> <mailto:afish@apple.com <mailto:afish@apple.com>>>
>>>>>> wrote:
>>>>>>>
>>>>>>>> On Apr 16, 2021, at 4:34 AM, Leif Lindholm <leif@nuviainc.com 
>>>>>>>> <mailto:leif@nuviainc.com>
>>>>>>>> <mailto:leif@nuviainc.com <mailto:leif@nuviainc.com>>> wrote:
>>>>>>>>
>>>>>>>> Hi Ethin,
>>>>>>>>
>>>>>>>> I think we also want to have a SetMode function, even if we 
>>>>>>>> don't get
>>>>>>>> around to implement proper support for it as part of GSoC 
>>>>>>>> (although I
>>>>>>>> expect at least for virtio, that should be pretty straightforward).
>>>>>>>>
>>>>>>> Leif,
>>>>>>>
>>>>>>> I’m think if we have an API to load the buffer and a 2nd API to
>>>>>>> play the
>>>>>>> buffer an optional 3rd API could configure the streams.
>>>>>>>
>>>>>>>> It's quite likely that speech for UI would be stored as 8kHz (or
>>>>>>>> 20kHz) in some systems, whereas the example for playing a tune in
>>>>>>>> GRUB
>>>>>>>> would more likely be a 44.1 kHz mp3/wav/ogg/flac.
>>>>>>>>
>>>>>>>> For the GSoC project, I think it would be quite reasonable to
>>>>>>>> pre-generate pure PCM streams for testing rather than decoding
>>>>>>>> anything on the fly.
>>>>>>>>
>>>>>>>> Porting/writing decoders is really a separate task from 
>>>>>>>> enabling the
>>>>>>>> output. I would much rather see USB *and* HDA support able to play
>>>>>>>> pcm
>>>>>>>> streams before worrying about decoding.
>>>>>>>>
>>>>>>> I agree it might turn out it is easier to have the text to speech
>>>>>>> code just
>>>>>>> encode a PCM directly.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Andrew Fish
>>>>>>>
>>>>>>>> /
>>>>>>>>    Leif
>>>>>>>>
>>>>>>>> On Fri, Apr 16, 2021 at 00:33:06 -0500, Ethin Probst wrote:
>>>>>>>>> Thanks for that explanation (I missed Mike's message). Earlier I
>>>>>>>>> sent
>>>>>>>>> a summary of those things that we can agree on: mainly, that 
>>>>>>>>> we have
>>>>>>>>> mute, volume control, a load buffer, (maybe) an unload buffer, 
>>>>>>>>> and a
>>>>>>>>> start/stop stream function. Now that I fully understand the
>>>>>>>>> ramifications of this I don't mind settling for a specific format
>>>>>>>>> and
>>>>>>>>> sample rate, and signed 16-bit PCM audio is, I think, the most
>>>>>>>>> widely
>>>>>>>>> used one out there, besides 64-bit floating point samples, which
>>>>>>>>> I've
>>>>>>>>> only seen used in DAWs, and that's something we don't need.
>>>>>>>>> Are you sure you want the firmware itself to handle the 
>>>>>>>>> decoding of
>>>>>>>>> WAV audio? I can make a library class for that, but I'll 
>>>>>>>>> definitely
>>>>>>>>> need help with the security aspect.
>>>>>>>>>
>>>>>>>>> On 4/16/21, Andrew Fish via groups.io <http://groups.io> 
>>>>>>>>> <http://groups.io <http://groups.io>>
>>>>>>>>> <afish=apple.com@groups.io <mailto:afish=apple.com@groups.io> 
>>>>>>>>> <mailto:afish=apple.com@groups.io 
>>>>>>>>> <mailto:afish=apple.com@groups.io>>>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> On Apr 15, 2021, at 5:59 PM, Michael Brown <mcb30@ipxe.org 
>>>>>>>>>>> <mailto:mcb30@ipxe.org>
>>>>>>>>>>> <mailto:mcb30@ipxe.org <mailto:mcb30@ipxe.org>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 16/04/2021 00:42, Ethin Probst wrote:
>>>>>>>>>>>> Forcing a particular channel mapping, sample rate and sample
>>>>>>>>>>>> format
>>>>>>>>>>>> on
>>>>>>>>>>>> everyone would complicate application code. From an
>>>>>>>>>>>> application point
>>>>>>>>>>>> of view, one would, with that type of protocol, need to do the
>>>>>>>>>>>> following:
>>>>>>>>>>>> 1) Load an audio file in any audio file format from any storage
>>>>>>>>>>>> mechanism.
>>>>>>>>>>>> 2) Decode the audio file format to extract the samples and 
>>>>>>>>>>>> audio
>>>>>>>>>>>> metadata.
>>>>>>>>>>>> 3) Resample the (now decoded) audio samples and convert
>>>>>>>>>>>> (quantize)
>>>>>>>>>>>> the
>>>>>>>>>>>> audio samples into signed 16-bit PCM audio.
>>>>>>>>>>>> 4) forward the samples onto the EFI audio protocol.
>>>>>>>>>>> You have made an incorrect assumption that there exists a
>>>>>>>>>>> requirement
>>>>>>>>>>> to
>>>>>>>>>>> be able to play audio files in arbitrary formats.  This
>>>>>>>>>>> requirement
>>>>>>>>>>> does
>>>>>>>>>>> not exist.
>>>>>>>>>>>
>>>>>>>>>>> With a protocol-mandated fixed baseline set of audio parameters
>>>>>>>>>>> (sample
>>>>>>>>>>> rate etc), what would happen in practice is that the audio
>>>>>>>>>>> files would
>>>>>>>>>>> be
>>>>>>>>>>> encoded in that format at *build* time, using tools entirely
>>>>>>>>>>> external
>>>>>>>>>>> to
>>>>>>>>>>> UEFI.  The application code is then trivially simple: it 
>>>>>>>>>>> just does
>>>>>>>>>>> "load
>>>>>>>>>>> blob, pass blob to audio protocol".
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Ethin,
>>>>>>>>>>
>>>>>>>>>> Given the goal is an industry standard we value interoperability
>>>>>>>>>> more
>>>>>>>>>> that
>>>>>>>>>> flexibility.
>>>>>>>>>>
>>>>>>>>>> How about another use case. Lets say the Linux OS loader (Grub)
>>>>>>>>>> wants
>>>>>>>>>> to
>>>>>>>>>> have an accessible UI so it decides to sore sound files on 
>>>>>>>>>> the EFI
>>>>>>>>>> System
>>>>>>>>>> Partition and use our new fancy UEFI Audio Protocol to add audio
>>>>>>>>>> to the
>>>>>>>>>> OS
>>>>>>>>>> loader GUI. So that version of Grub needs to work on 1,000 of
>>>>>>>>>> different
>>>>>>>>>> PCs
>>>>>>>>>> and a wide range of UEFI Audio driver implementations. It is 
>>>>>>>>>> a much
>>>>>>>>>> easier
>>>>>>>>>> world if Wave PCM 16 bit just works every place. You could add a
>>>>>>>>>> lot of
>>>>>>>>>> complexity and try to encode the audio on the fly, maybe even in
>>>>>>>>>> Linux
>>>>>>>>>> proper but that falls down if you are booting from read only
>>>>>>>>>> media like
>>>>>>>>>> a
>>>>>>>>>> DVD or backup tape (yes people still do that in server land).
>>>>>>>>>>
>>>>>>>>>> The other problem with flexibility is you just made the test 
>>>>>>>>>> matrix
>>>>>>>>>> very
>>>>>>>>>> large for every driver that needs to get implemented. For
>>>>>>>>>> something as
>>>>>>>>>> complex as Intel HDA how you hook up the hardware and what
>>>>>>>>>> CODECs you
>>>>>>>>>> use
>>>>>>>>>> may impact the quality of the playback for a given board. Your
>>>>>>>>>> EFI is
>>>>>>>>>> likely
>>>>>>>>>> going to pick a single encoding at that will get tested all the
>>>>>>>>>> time if
>>>>>>>>>> your
>>>>>>>>>> system has audio, but all 50 other things you support not so
>>>>>>>>>> much. So
>>>>>>>>>> that
>>>>>>>>>> will required testing, and some one with audiophile ears (or 
>>>>>>>>>> an AI
>>>>>>>>>> program)
>>>>>>>>>> to test all the combinations. I’m not kidding I get BZs on the
>>>>>>>>>> quality
>>>>>>>>>> of
>>>>>>>>>> the boot bong on our systems.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> typedef struct EFI_SIMPLE_AUDIO_PROTOCOL {
>>>>>>>>>>>>  EFI_SIMPLE_AUDIO_PROTOCOL_RESET Reset;
>>>>>>>>>>>>  EFI_SIMPLE_AUDIO_PROTOCOL_START Start;
>>>>>>>>>>>>  EFI_SIMPLE_AUDIO_PROTOCOL_STOP Stop;
>>>>>>>>>>>> } EFI_SIMPLE_AUDIO_PROTOCOL;
>>>>>>>>>>> This is now starting to look like something that belongs in
>>>>>>>>>>> boot-time
>>>>>>>>>>> firmware.  :)
>>>>>>>>>>>
>>>>>>>>>> I think that got a little too simple I’d go back and look at the
>>>>>>>>>> example
>>>>>>>>>> I
>>>>>>>>>> posted to the thread but add an API to load the buffer, and then
>>>>>>>>>> play
>>>>>>>>>> the
>>>>>>>>>> buffer (that way we can an API in the future to twiddle knobs).
>>>>>>>>>> That
>>>>>>>>>> API
>>>>>>>>>> also implements the async EFI interface. Trust me the 1st thing
>>>>>>>>>> that is
>>>>>>>>>> going to happen when we add audio is some one is going to
>>>>>>>>>> complain in
>>>>>>>>>> xyz
>>>>>>>>>> state we should mute audio, or we should honer audio volume and
>>>>>>>>>> mute
>>>>>>>>>> settings from setup, or from values set in the OS. Or some one
>>>>>>>>>> is going
>>>>>>>>>> to
>>>>>>>>>> want the volume keys on the keyboard to work in EFI.
>>>>>>>>>>
>>>>>>>>>> Also if you need to pick apart the Wave PCM 16 byte file to feed
>>>>>>>>>> it into
>>>>>>>>>> the
>>>>>>>>>> audio hardware that probably means we should have a library that
>>>>>>>>>> does
>>>>>>>>>> that
>>>>>>>>>> work, so other Audio drivers can share that code. Also having a
>>>>>>>>>> library
>>>>>>>>>> makes it easier to write a unit test. We need to be security
>>>>>>>>>> conscious
>>>>>>>>>> as we
>>>>>>>>>> need to treat the Audo file as attacker controlled data.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Andrew Fish
>>>>>>>>>>
>>>>>>>>>>> Michael
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Signed,
>>>>>>>>> Ethin D. Probst
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>>
>> --
>> Signed,
>> Ethin D. Probst
>
> 

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Marvin Häuser]

On 18.04.21 21:11, Marvin Häuser wrote:
> On 18.04.21 17:22, Andrew Fish via groups.io wrote:
>>
>>
>>> On Apr 18, 2021, at 1:55 AM, Ethin Probst <harlydavidsen@gmail.com 
>>> <mailto:harlydavidsen@gmail.com>> wrote:
>>>
>>>> I think it would be best to sketch use-cases for audio and design 
>>>> the solutions closely to the requirements. Why do we need to know 
>>>> when audio finished? What will happen when we queue audio twice? 
>>>> There are many layers (UX, interface, implementation details) of 
>>>> questions to coming up with a pleasant and stable design.
>>
>> We are not using EFI to listen to music in the background. Any audio 
>> being played is part of a UI element and there might be 
>> synchronization requirements.
>
> Maybe I communicated that wrong, I'm not asking because I don't know 
> what audio is used for, I am saying ideally there is a written-down 
> list of usage requirements before the protocol is designed, because 
> that is what the design targets. The details should follow the needs.
>
>>
>> For example playing a boot bong on boot you want that to be 
>> asynchronous as you don’t want to delay boot to play the sound, but 
>> you may want to chose to gate some UI elements on the boot bong 
>> completing. If you are building a menu UI that is accessible you may 
>> need to synchronize playback with UI update, but you may not want to 
>> make the slow sound playback blocking as you can get other UI work 
>> done in parallel.
>>
>> The overhead for a caller making an async call is not much [1], but 
>> not having the capability could really restrict the API for its 
>> intended use. I’d also point out we picked the same pattern as the 
>> async BlockIO and there is something to said for having consistency 
>> in the UEFI Spec and have similar APIs work in similar ways.

Sorry a lot of the spam, but I somehow missed the "consistency" point. 
Sorry, but there seems to be no real consistency. Block I/O and network 
things generally use the token event method (what is suggested here), 
while USB, Bluetooth, and such generally pass a callback function 
directly (not necessarily what I suggest, as I don't know the full 
requirements, but certainly one way).

Best regards,
Marvin

>
> I'm not saying there should be *no* async playback, I am saying it may 
> be worth considering implementing it differently from caller-owned 
> events. I'm not concerned with overhead, I'm concerned with points of 
> failure (e.g. leaks).
>
> I very briefly discussed some things with Ethin and it seems like the 
> default EDK II timer interval of 10 ms may be problematic, but I am 
> not sure. Just leaving it here as something to keep it mind.
>
> Best regards,
> Marvin
>
>>
>> [1] Overhead for making an asynchronous call.
>> AUDIO_TOKEN AudioToken;
>> gBS->CreateEvent  (EVT_NOTIFY_SIGNAL, TPL_CALLBACK, NULL, NULL, 
>> &AudioToken.Event);
>>
>> Thanks,
>>
>> Andrew Fish
>>
>>> I would be happy to discuss this with you on the UEFI talkbox. I'm
>>> draeand on there.
>>> As for your questions:
>>>
>>> 1. The only reason I recommend using an event to signal audio
>>> completion is because I do not want this protocol to be blocking at
>>> all. (So, perhaps removing the token entirely is a good idea.) The
>>> VirtIO audio device says nothing about synchronization, but I imagine
>>> its asynchronous because every audio specification I've seen out there
>>> is asynchronous. Similarly, every audio API in existence -- at least,
>>> every low-level OS-specific one -- is asynchronous/non-blocking.
>>> (Usually, audio processing is handled on a separate thread.) However,
>>> UEFI has no concept of threads or processes. Though we could use the
>>> MP PI package to spin up a separate processor, that would fail on
>>> uniprocessor, unicore systems. Audio processing needs a high enough
>>> priority that it gets first in the list of tasks served while
>>> simultaneously not getting a priority that's so high that it blocks
>>> everything else. This is primarily because of the way an audio
>>> subsystem is designed and the way an audio device functions: the audio
>>> subsystem needs to know, immediately, when the audio buffer has ran
>>> out of samples and needs more, and it needs to react immediately to
>>> refill the buffer if required, especially when streaming large amounts
>>> of audio (e.g.: music). Similarly, the audio subsystem needs the
>>> ability to react as soon as is viable when playback is requested,
>>> because any significant delay will be noticeable by the end-user. In
>>> more complex systems like FMOD or OpenAL, the audio processing thread
>>> also needs a high priority to ensure that audio effects, positioning
>>> information, dithering, etc., can be configured immediately because
>>> the user will notice if any glitches or delays occur. The UEFI audio
>>> protocols obviously will be nowhere near as complex, or as advanced,
>>> because no one will need audio effects in a preboot environment.
>>> Granted, its possible to make small audio effects, for example delays,
>>> even if the protocol doesn't have functions to do that, but if an
>>> end-user wants to go absolutely crazy with the audio samples and mix
>>> in a really nice-sounding reverb or audio filter before sending the
>>> samples to the audio engine, well, that's what they want to do and
>>> that's out of our hands as driver/protocol developers. But I digress.
>>> UEFI only has four TPLs, and so what we hopefully want is an engine
>>> that is able to manage sample buffering and transmission, but also
>>> doesn't block the application that's using the protocol. For some
>>> things, blocking might be acceptable, but for speech synthesis or the
>>> playing of startup sounds, this would not be an acceptable result and
>>> would make the protocol pretty much worthless in the majority of
>>> scenarios. So that's why I had an event to signal audio completion --
>>> it was (perhaps) a cheap hack around the cooperatively-scheduled task
>>> architecture of UEFI. (At least, I think its cooperative multitasking,
>>> correct me if I'm wrong.)
>>> 2. The VirtIO specification does not specify what occurs in the event
>>> that a request is received to play a stream that's already being
>>> played. However, it does provide enough information for extrapolation.
>>> Every request that's sent to a VirtIO sound device must come with two
>>> things: a stream ID and a buffer of samples. The sample data must
>>> immediately follow the request. Therefore, for VirtIO in particular,
>>> the device will simply stop playing the old set of samples and play
>>> the new set instead. This goes along with what I've seen in other
>>> specifications like the HDA one: unless the device in question
>>> supports more than one stream, it is impossible to play two sounds on
>>> a single stream simultaneously, and an HDA controller (for example) is
>>> not going to perform any mixing; mixing is done purely in software.
>>> Similarly, if a device does support multiple streams, it is
>>> unspecified whether the device will play two or more streams
>>> simultaneously or whether it will pause/abort the playback of one
>>> while it plays another. Therefore, I believe (though cannot confirm)
>>> that OSes like Windows simply use a single stream, even if the device
>>> supports multiple streams, and just makes the applications believe
>>> that unlimited streams are possible.
>>>
>>> I apologize for this really long-winded email, and I hope no one 
>>> minds. :-)
>>>
>>> On 4/17/21, Marvin Häuser <mhaeuser@posteo.de 
>>> <mailto:mhaeuser@posteo.de>> wrote:
>>>> On 17.04.21 19:31, Andrew Fish via groups.io <http://groups.io> wrote:
>>>>>
>>>>>
>>>>>> On Apr 17, 2021, at 9:51 AM, Marvin Häuser <mhaeuser@posteo.de 
>>>>>> <mailto:mhaeuser@posteo.de>
>>>>>> <mailto:mhaeuser@posteo.de <mailto:mhaeuser@posteo.de>>> wrote:
>>>>>>
>>>>>> On 16.04.21 19:45, Ethin Probst wrote:
>>>>>>> Yes, three APIs (maybe like this) would work well:
>>>>>>> - Start, Stop: begin playback of a stream
>>>>>>> - SetVolume, GetVolume, Mute, Unmute: control volume of output and
>>>>>>> enable muting
>>>>>>> - CreateStream, ReleaseStream, SetStreamSampleRate: Control sample
>>>>>>> rate of stream (but not sample format since Signed 16-bit PCM is
>>>>>>> enough)
>>>>>>> Marvin, how do you suggest we make the events then? We need some 
>>>>>>> way
>>>>>>> of notifying the caller that the stream has concluded. We could 
>>>>>>> make
>>>>>>> the driver create the event and pass it back to the caller as an
>>>>>>> event, but you'd still have dangling pointers (this is C, after 
>>>>>>> all).
>>>>>>> We could just make a IsPlaying() function and WaitForCompletion()
>>>>>>> function and allow the driver to do the event handling -- would 
>>>>>>> that
>>>>>>> work?
>>>>>>
>>>>>> I do not know enough about the possible use-cases to tell. Aside 
>>>>>> from
>>>>>> the two functions you already mentioned, you could also take in an
>>>>>> (optional) notification function.
>>>>>> Which possible use-cases does determining playback end have? If it's
>>>>>> too much effort, just use EFI_EVENT I guess, just the less code can
>>>>>> mess it up, the better.
>>>>>>
>>>>>
>>>>> In UEFI EFI_EVENT works much better. There is a gBS-WaitForEvent()
>>>>> function that lets a caller wait on an event. That is basically what
>>>>> the UEFI Shell is doing at the Shell prompt. A GUI in UEFI/C is
>>>>> basically an event loop.
>>>>>
>>>>> Fun fact: I ended up adding gIdleLoopEventGuid to the MdeModulePkg so
>>>>> the DXE Core could signal gIdleLoopEventGuid if you are sitting in
>>>>> gBS-WaitForEvent() and no event is signaled. Basically in EFI nothing
>>>>> is going to happen until the next timer tick so the 
>>>>> gIdleLoopEventGuid
>>>>> lets you idle the CPU until the next timer tick. I was forced to do
>>>>> this as the 1st MacBook Air had a bad habit of thermal tripping when
>>>>> sitting at the UEFI Shell prompt. After all another name for a 
>>>>> loop in
>>>>> C code running on bare metal is a power virus.
>>>>
>>>> Mac EFI is one of the best implementations we know of, frankly. I'm
>>>> traumatised by Aptio 4 and alike, where (some issues are 
>>>> OEM-specific I
>>>> think) you can have timer events signalling after ExitBS, there is 
>>>> event
>>>> clutter on IO polling to the point where everything lags no matter 
>>>> what
>>>> you do, and even in "smooth" scenarios there may be nothing worth the
>>>> description "granularity" (events scheduled to run every 10 ms may run
>>>> every 50 ms). Events are the last resort for us, if there really is no
>>>> other way. My first GUI implementation worked without events at all 
>>>> for
>>>> this reason, but as our workarounds got better, we did start using 
>>>> them
>>>> for keyboard and mouse polling.
>>>>
>>>> Timers do not apply here, but what does apply is resource management.
>>>> Using EFI_EVENT directly means (to the outside) the introduction of a
>>>> new resource to maintain, for each caller separately. On the other 
>>>> side,
>>>> there is no resource to misuse or leak if none such is exposed. 
>>>> Yet, if
>>>> you argue with APIs like WaitForEvent, something has to signal it. 
>>>> In a
>>>> simple environment this would mean, some timer event is running and 
>>>> may
>>>> signal the event the main code waits for, where above's concern 
>>>> actually
>>>> do apply. :) Again, the recommendation assumes the use-cases are 
>>>> simple
>>>> enough to easily avoid them.
>>>>
>>>> I think it would be best to sketch use-cases for audio and design the
>>>> solutions closely to the requirements. Why do we need to know when 
>>>> audio
>>>> finished? What will happen when we queue audio twice? There are many
>>>> layers (UX, interface, implementation details) of questions to 
>>>> coming up
>>>> with a pleasant and stable design.
>>>>
>>>> Best regards,
>>>> Marvin
>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Andrew Fish.
>>>>>
>>>>>> If I remember correctly you mentioned the UEFI Talkbox before, if
>>>>>> that is more convenient for you, I'm there as mhaeuser.
>>>>>>
>>>>>> Best regards,
>>>>>> Marvin
>>>>>>
>>>>>>>
>>>>>>> On 4/16/21, Andrew Fish <afish@apple.com 
>>>>>>> <mailto:afish@apple.com> <mailto:afish@apple.com 
>>>>>>> <mailto:afish@apple.com>>>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On Apr 16, 2021, at 4:34 AM, Leif Lindholm <leif@nuviainc.com 
>>>>>>>>> <mailto:leif@nuviainc.com>
>>>>>>>>> <mailto:leif@nuviainc.com <mailto:leif@nuviainc.com>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi Ethin,
>>>>>>>>>
>>>>>>>>> I think we also want to have a SetMode function, even if we 
>>>>>>>>> don't get
>>>>>>>>> around to implement proper support for it as part of GSoC 
>>>>>>>>> (although I
>>>>>>>>> expect at least for virtio, that should be pretty 
>>>>>>>>> straightforward).
>>>>>>>>>
>>>>>>>> Leif,
>>>>>>>>
>>>>>>>> I’m think if we have an API to load the buffer and a 2nd API to
>>>>>>>> play the
>>>>>>>> buffer an optional 3rd API could configure the streams.
>>>>>>>>
>>>>>>>>> It's quite likely that speech for UI would be stored as 8kHz (or
>>>>>>>>> 20kHz) in some systems, whereas the example for playing a tune in
>>>>>>>>> GRUB
>>>>>>>>> would more likely be a 44.1 kHz mp3/wav/ogg/flac.
>>>>>>>>>
>>>>>>>>> For the GSoC project, I think it would be quite reasonable to
>>>>>>>>> pre-generate pure PCM streams for testing rather than decoding
>>>>>>>>> anything on the fly.
>>>>>>>>>
>>>>>>>>> Porting/writing decoders is really a separate task from 
>>>>>>>>> enabling the
>>>>>>>>> output. I would much rather see USB *and* HDA support able to 
>>>>>>>>> play
>>>>>>>>> pcm
>>>>>>>>> streams before worrying about decoding.
>>>>>>>>>
>>>>>>>> I agree it might turn out it is easier to have the text to speech
>>>>>>>> code just
>>>>>>>> encode a PCM directly.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Andrew Fish
>>>>>>>>
>>>>>>>>> /
>>>>>>>>>    Leif
>>>>>>>>>
>>>>>>>>> On Fri, Apr 16, 2021 at 00:33:06 -0500, Ethin Probst wrote:
>>>>>>>>>> Thanks for that explanation (I missed Mike's message). Earlier I
>>>>>>>>>> sent
>>>>>>>>>> a summary of those things that we can agree on: mainly, that 
>>>>>>>>>> we have
>>>>>>>>>> mute, volume control, a load buffer, (maybe) an unload 
>>>>>>>>>> buffer, and a
>>>>>>>>>> start/stop stream function. Now that I fully understand the
>>>>>>>>>> ramifications of this I don't mind settling for a specific 
>>>>>>>>>> format
>>>>>>>>>> and
>>>>>>>>>> sample rate, and signed 16-bit PCM audio is, I think, the most
>>>>>>>>>> widely
>>>>>>>>>> used one out there, besides 64-bit floating point samples, which
>>>>>>>>>> I've
>>>>>>>>>> only seen used in DAWs, and that's something we don't need.
>>>>>>>>>> Are you sure you want the firmware itself to handle the 
>>>>>>>>>> decoding of
>>>>>>>>>> WAV audio? I can make a library class for that, but I'll 
>>>>>>>>>> definitely
>>>>>>>>>> need help with the security aspect.
>>>>>>>>>>
>>>>>>>>>> On 4/16/21, Andrew Fish via groups.io <http://groups.io> 
>>>>>>>>>> <http://groups.io <http://groups.io>>
>>>>>>>>>> <afish=apple.com@groups.io <mailto:afish=apple.com@groups.io> 
>>>>>>>>>> <mailto:afish=apple.com@groups.io 
>>>>>>>>>> <mailto:afish=apple.com@groups.io>>>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On Apr 15, 2021, at 5:59 PM, Michael Brown <mcb30@ipxe.org 
>>>>>>>>>>>> <mailto:mcb30@ipxe.org>
>>>>>>>>>>>> <mailto:mcb30@ipxe.org <mailto:mcb30@ipxe.org>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On 16/04/2021 00:42, Ethin Probst wrote:
>>>>>>>>>>>>> Forcing a particular channel mapping, sample rate and sample
>>>>>>>>>>>>> format
>>>>>>>>>>>>> on
>>>>>>>>>>>>> everyone would complicate application code. From an
>>>>>>>>>>>>> application point
>>>>>>>>>>>>> of view, one would, with that type of protocol, need to do 
>>>>>>>>>>>>> the
>>>>>>>>>>>>> following:
>>>>>>>>>>>>> 1) Load an audio file in any audio file format from any 
>>>>>>>>>>>>> storage
>>>>>>>>>>>>> mechanism.
>>>>>>>>>>>>> 2) Decode the audio file format to extract the samples and 
>>>>>>>>>>>>> audio
>>>>>>>>>>>>> metadata.
>>>>>>>>>>>>> 3) Resample the (now decoded) audio samples and convert
>>>>>>>>>>>>> (quantize)
>>>>>>>>>>>>> the
>>>>>>>>>>>>> audio samples into signed 16-bit PCM audio.
>>>>>>>>>>>>> 4) forward the samples onto the EFI audio protocol.
>>>>>>>>>>>> You have made an incorrect assumption that there exists a
>>>>>>>>>>>> requirement
>>>>>>>>>>>> to
>>>>>>>>>>>> be able to play audio files in arbitrary formats.  This
>>>>>>>>>>>> requirement
>>>>>>>>>>>> does
>>>>>>>>>>>> not exist.
>>>>>>>>>>>>
>>>>>>>>>>>> With a protocol-mandated fixed baseline set of audio 
>>>>>>>>>>>> parameters
>>>>>>>>>>>> (sample
>>>>>>>>>>>> rate etc), what would happen in practice is that the audio
>>>>>>>>>>>> files would
>>>>>>>>>>>> be
>>>>>>>>>>>> encoded in that format at *build* time, using tools entirely
>>>>>>>>>>>> external
>>>>>>>>>>>> to
>>>>>>>>>>>> UEFI.  The application code is then trivially simple: it 
>>>>>>>>>>>> just does
>>>>>>>>>>>> "load
>>>>>>>>>>>> blob, pass blob to audio protocol".
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Ethin,
>>>>>>>>>>>
>>>>>>>>>>> Given the goal is an industry standard we value 
>>>>>>>>>>> interoperability
>>>>>>>>>>> more
>>>>>>>>>>> that
>>>>>>>>>>> flexibility.
>>>>>>>>>>>
>>>>>>>>>>> How about another use case. Lets say the Linux OS loader (Grub)
>>>>>>>>>>> wants
>>>>>>>>>>> to
>>>>>>>>>>> have an accessible UI so it decides to sore sound files on 
>>>>>>>>>>> the EFI
>>>>>>>>>>> System
>>>>>>>>>>> Partition and use our new fancy UEFI Audio Protocol to add 
>>>>>>>>>>> audio
>>>>>>>>>>> to the
>>>>>>>>>>> OS
>>>>>>>>>>> loader GUI. So that version of Grub needs to work on 1,000 of
>>>>>>>>>>> different
>>>>>>>>>>> PCs
>>>>>>>>>>> and a wide range of UEFI Audio driver implementations. It is 
>>>>>>>>>>> a much
>>>>>>>>>>> easier
>>>>>>>>>>> world if Wave PCM 16 bit just works every place. You could 
>>>>>>>>>>> add a
>>>>>>>>>>> lot of
>>>>>>>>>>> complexity and try to encode the audio on the fly, maybe 
>>>>>>>>>>> even in
>>>>>>>>>>> Linux
>>>>>>>>>>> proper but that falls down if you are booting from read only
>>>>>>>>>>> media like
>>>>>>>>>>> a
>>>>>>>>>>> DVD or backup tape (yes people still do that in server land).
>>>>>>>>>>>
>>>>>>>>>>> The other problem with flexibility is you just made the test 
>>>>>>>>>>> matrix
>>>>>>>>>>> very
>>>>>>>>>>> large for every driver that needs to get implemented. For
>>>>>>>>>>> something as
>>>>>>>>>>> complex as Intel HDA how you hook up the hardware and what
>>>>>>>>>>> CODECs you
>>>>>>>>>>> use
>>>>>>>>>>> may impact the quality of the playback for a given board. Your
>>>>>>>>>>> EFI is
>>>>>>>>>>> likely
>>>>>>>>>>> going to pick a single encoding at that will get tested all the
>>>>>>>>>>> time if
>>>>>>>>>>> your
>>>>>>>>>>> system has audio, but all 50 other things you support not so
>>>>>>>>>>> much. So
>>>>>>>>>>> that
>>>>>>>>>>> will required testing, and some one with audiophile ears (or 
>>>>>>>>>>> an AI
>>>>>>>>>>> program)
>>>>>>>>>>> to test all the combinations. I’m not kidding I get BZs on the
>>>>>>>>>>> quality
>>>>>>>>>>> of
>>>>>>>>>>> the boot bong on our systems.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> typedef struct EFI_SIMPLE_AUDIO_PROTOCOL {
>>>>>>>>>>>>>  EFI_SIMPLE_AUDIO_PROTOCOL_RESET Reset;
>>>>>>>>>>>>>  EFI_SIMPLE_AUDIO_PROTOCOL_START Start;
>>>>>>>>>>>>>  EFI_SIMPLE_AUDIO_PROTOCOL_STOP Stop;
>>>>>>>>>>>>> } EFI_SIMPLE_AUDIO_PROTOCOL;
>>>>>>>>>>>> This is now starting to look like something that belongs in
>>>>>>>>>>>> boot-time
>>>>>>>>>>>> firmware.  :)
>>>>>>>>>>>>
>>>>>>>>>>> I think that got a little too simple I’d go back and look at 
>>>>>>>>>>> the
>>>>>>>>>>> example
>>>>>>>>>>> I
>>>>>>>>>>> posted to the thread but add an API to load the buffer, and 
>>>>>>>>>>> then
>>>>>>>>>>> play
>>>>>>>>>>> the
>>>>>>>>>>> buffer (that way we can an API in the future to twiddle knobs).
>>>>>>>>>>> That
>>>>>>>>>>> API
>>>>>>>>>>> also implements the async EFI interface. Trust me the 1st thing
>>>>>>>>>>> that is
>>>>>>>>>>> going to happen when we add audio is some one is going to
>>>>>>>>>>> complain in
>>>>>>>>>>> xyz
>>>>>>>>>>> state we should mute audio, or we should honer audio volume and
>>>>>>>>>>> mute
>>>>>>>>>>> settings from setup, or from values set in the OS. Or some one
>>>>>>>>>>> is going
>>>>>>>>>>> to
>>>>>>>>>>> want the volume keys on the keyboard to work in EFI.
>>>>>>>>>>>
>>>>>>>>>>> Also if you need to pick apart the Wave PCM 16 byte file to 
>>>>>>>>>>> feed
>>>>>>>>>>> it into
>>>>>>>>>>> the
>>>>>>>>>>> audio hardware that probably means we should have a library 
>>>>>>>>>>> that
>>>>>>>>>>> does
>>>>>>>>>>> that
>>>>>>>>>>> work, so other Audio drivers can share that code. Also having a
>>>>>>>>>>> library
>>>>>>>>>>> makes it easier to write a unit test. We need to be security
>>>>>>>>>>> conscious
>>>>>>>>>>> as we
>>>>>>>>>>> need to treat the Audo file as attacker controlled data.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>
>>>>>>>>>>> Andrew Fish
>>>>>>>>>>>
>>>>>>>>>>>> Michael
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -- 
>>>>>>>>>> Signed,
>>>>>>>>>> Ethin D. Probst
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>>
>>> -- 
>>> Signed,
>>> Ethin D. Probst
>>
>> 
>

Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)

[Andrew Fish]

[-- Attachment #1: Type: text/plain, Size: 22647 bytes --]



> On Apr 18, 2021, at 12:22 PM, Marvin Häuser <mhaeuser@posteo.de> wrote:
> 
> On 18.04.21 21:11, Marvin Häuser wrote:
>> On 18.04.21 17:22, Andrew Fish via groups.io wrote:
>>> 
>>> 
>>>> On Apr 18, 2021, at 1:55 AM, Ethin Probst <harlydavidsen@gmail.com <mailto:harlydavidsen@gmail.com>> wrote:
>>>> 
>>>>> I think it would be best to sketch use-cases for audio and design the solutions closely to the requirements. Why do we need to know when audio finished? What will happen when we queue audio twice? There are many layers (UX, interface, implementation details) of questions to coming up with a pleasant and stable design.
>>> 
>>> We are not using EFI to listen to music in the background. Any audio being played is part of a UI element and there might be synchronization requirements.
>> 
>> Maybe I communicated that wrong, I'm not asking because I don't know what audio is used for, I am saying ideally there is a written-down list of usage requirements before the protocol is designed, because that is what the design targets. The details should follow the needs.
>> 
>>> 
>>> For example playing a boot bong on boot you want that to be asynchronous as you don’t want to delay boot to play the sound, but you may want to chose to gate some UI elements on the boot bong completing. If you are building a menu UI that is accessible you may need to synchronize playback with UI update, but you may not want to make the slow sound playback blocking as you can get other UI work done in parallel.
>>> 
>>> The overhead for a caller making an async call is not much [1], but not having the capability could really restrict the API for its intended use. I’d also point out we picked the same pattern as the async BlockIO and there is something to said for having consistency in the UEFI Spec and have similar APIs work in similar ways.
> 
> Sorry a lot of the spam, but I somehow missed the "consistency" point. Sorry, but there seems to be no real consistency. Block I/O and network things generally use the token event method (what is suggested here), while USB, Bluetooth, and such generally pass a callback function directly (not necessarily what I suggest, as I don't know the full requirements, but certainly one way).
> 

The networking interfaces are ancient, and it looks like the recent BT stack leans into that model. Also those callbacks are about returning data in the form of unknown packets which is not the problem we are trying to solve. 

The async Block IO is more of a model of notification of a queued event and I think that maps better into what we are doing. The MP Services protocol from the PI spec also uses an optional event to notify completion. At some point we realized with a callback, or just and event it was hard to return an error status so that is why we ended up with the token in Block IO 2 so a states could be returned after the completion event was signaled. 

There is also more flexibility with events as it lets define a GUID’ed event and broadcast this state to other entities if you want. 

Thanks,

Andrew Fish

> Best regards,
> Marvin
> 
>> 
>> I'm not saying there should be *no* async playback, I am saying it may be worth considering implementing it differently from caller-owned events. I'm not concerned with overhead, I'm concerned with points of failure (e.g. leaks).
>> 
>> I very briefly discussed some things with Ethin and it seems like the default EDK II timer interval of 10 ms may be problematic, but I am not sure. Just leaving it here as something to keep it mind.
>> 
>> Best regards,
>> Marvin
>> 
>>> 
>>> [1] Overhead for making an asynchronous call.
>>> AUDIO_TOKEN AudioToken;
>>> gBS->CreateEvent  (EVT_NOTIFY_SIGNAL, TPL_CALLBACK, NULL, NULL, &AudioToken.Event);
>>> 
>>> Thanks,
>>> 
>>> Andrew Fish
>>> 
>>>> I would be happy to discuss this with you on the UEFI talkbox. I'm
>>>> draeand on there.
>>>> As for your questions:
>>>> 
>>>> 1. The only reason I recommend using an event to signal audio
>>>> completion is because I do not want this protocol to be blocking at
>>>> all. (So, perhaps removing the token entirely is a good idea.) The
>>>> VirtIO audio device says nothing about synchronization, but I imagine
>>>> its asynchronous because every audio specification I've seen out there
>>>> is asynchronous. Similarly, every audio API in existence -- at least,
>>>> every low-level OS-specific one -- is asynchronous/non-blocking.
>>>> (Usually, audio processing is handled on a separate thread.) However,
>>>> UEFI has no concept of threads or processes. Though we could use the
>>>> MP PI package to spin up a separate processor, that would fail on
>>>> uniprocessor, unicore systems. Audio processing needs a high enough
>>>> priority that it gets first in the list of tasks served while
>>>> simultaneously not getting a priority that's so high that it blocks
>>>> everything else. This is primarily because of the way an audio
>>>> subsystem is designed and the way an audio device functions: the audio
>>>> subsystem needs to know, immediately, when the audio buffer has ran
>>>> out of samples and needs more, and it needs to react immediately to
>>>> refill the buffer if required, especially when streaming large amounts
>>>> of audio (e.g.: music). Similarly, the audio subsystem needs the
>>>> ability to react as soon as is viable when playback is requested,
>>>> because any significant delay will be noticeable by the end-user. In
>>>> more complex systems like FMOD or OpenAL, the audio processing thread
>>>> also needs a high priority to ensure that audio effects, positioning
>>>> information, dithering, etc., can be configured immediately because
>>>> the user will notice if any glitches or delays occur. The UEFI audio
>>>> protocols obviously will be nowhere near as complex, or as advanced,
>>>> because no one will need audio effects in a preboot environment.
>>>> Granted, its possible to make small audio effects, for example delays,
>>>> even if the protocol doesn't have functions to do that, but if an
>>>> end-user wants to go absolutely crazy with the audio samples and mix
>>>> in a really nice-sounding reverb or audio filter before sending the
>>>> samples to the audio engine, well, that's what they want to do and
>>>> that's out of our hands as driver/protocol developers. But I digress.
>>>> UEFI only has four TPLs, and so what we hopefully want is an engine
>>>> that is able to manage sample buffering and transmission, but also
>>>> doesn't block the application that's using the protocol. For some
>>>> things, blocking might be acceptable, but for speech synthesis or the
>>>> playing of startup sounds, this would not be an acceptable result and
>>>> would make the protocol pretty much worthless in the majority of
>>>> scenarios. So that's why I had an event to signal audio completion --
>>>> it was (perhaps) a cheap hack around the cooperatively-scheduled task
>>>> architecture of UEFI. (At least, I think its cooperative multitasking,
>>>> correct me if I'm wrong.)
>>>> 2. The VirtIO specification does not specify what occurs in the event
>>>> that a request is received to play a stream that's already being
>>>> played. However, it does provide enough information for extrapolation.
>>>> Every request that's sent to a VirtIO sound device must come with two
>>>> things: a stream ID and a buffer of samples. The sample data must
>>>> immediately follow the request. Therefore, for VirtIO in particular,
>>>> the device will simply stop playing the old set of samples and play
>>>> the new set instead. This goes along with what I've seen in other
>>>> specifications like the HDA one: unless the device in question
>>>> supports more than one stream, it is impossible to play two sounds on
>>>> a single stream simultaneously, and an HDA controller (for example) is
>>>> not going to perform any mixing; mixing is done purely in software.
>>>> Similarly, if a device does support multiple streams, it is
>>>> unspecified whether the device will play two or more streams
>>>> simultaneously or whether it will pause/abort the playback of one
>>>> while it plays another. Therefore, I believe (though cannot confirm)
>>>> that OSes like Windows simply use a single stream, even if the device
>>>> supports multiple streams, and just makes the applications believe
>>>> that unlimited streams are possible.
>>>> 
>>>> I apologize for this really long-winded email, and I hope no one minds. :-)
>>>> 
>>>> On 4/17/21, Marvin Häuser <mhaeuser@posteo.de <mailto:mhaeuser@posteo.de>> wrote:
>>>>> On 17.04.21 19:31, Andrew Fish via groups.io <http://groups.io> wrote:
>>>>>> 
>>>>>> 
>>>>>>> On Apr 17, 2021, at 9:51 AM, Marvin Häuser <mhaeuser@posteo.de <mailto:mhaeuser@posteo.de>
>>>>>>> <mailto:mhaeuser@posteo.de <mailto:mhaeuser@posteo.de>>> wrote:
>>>>>>> 
>>>>>>> On 16.04.21 19:45, Ethin Probst wrote:
>>>>>>>> Yes, three APIs (maybe like this) would work well:
>>>>>>>> - Start, Stop: begin playback of a stream
>>>>>>>> - SetVolume, GetVolume, Mute, Unmute: control volume of output and
>>>>>>>> enable muting
>>>>>>>> - CreateStream, ReleaseStream, SetStreamSampleRate: Control sample
>>>>>>>> rate of stream (but not sample format since Signed 16-bit PCM is
>>>>>>>> enough)
>>>>>>>> Marvin, how do you suggest we make the events then? We need some way
>>>>>>>> of notifying the caller that the stream has concluded. We could make
>>>>>>>> the driver create the event and pass it back to the caller as an
>>>>>>>> event, but you'd still have dangling pointers (this is C, after all).
>>>>>>>> We could just make a IsPlaying() function and WaitForCompletion()
>>>>>>>> function and allow the driver to do the event handling -- would that
>>>>>>>> work?
>>>>>>> 
>>>>>>> I do not know enough about the possible use-cases to tell. Aside from
>>>>>>> the two functions you already mentioned, you could also take in an
>>>>>>> (optional) notification function.
>>>>>>> Which possible use-cases does determining playback end have? If it's
>>>>>>> too much effort, just use EFI_EVENT I guess, just the less code can
>>>>>>> mess it up, the better.
>>>>>>> 
>>>>>> 
>>>>>> In UEFI EFI_EVENT works much better. There is a gBS-WaitForEvent()
>>>>>> function that lets a caller wait on an event. That is basically what
>>>>>> the UEFI Shell is doing at the Shell prompt. A GUI in UEFI/C is
>>>>>> basically an event loop.
>>>>>> 
>>>>>> Fun fact: I ended up adding gIdleLoopEventGuid to the MdeModulePkg so
>>>>>> the DXE Core could signal gIdleLoopEventGuid if you are sitting in
>>>>>> gBS-WaitForEvent() and no event is signaled. Basically in EFI nothing
>>>>>> is going to happen until the next timer tick so the gIdleLoopEventGuid
>>>>>> lets you idle the CPU until the next timer tick. I was forced to do
>>>>>> this as the 1st MacBook Air had a bad habit of thermal tripping when
>>>>>> sitting at the UEFI Shell prompt. After all another name for a loop in
>>>>>> C code running on bare metal is a power virus.
>>>>> 
>>>>> Mac EFI is one of the best implementations we know of, frankly. I'm
>>>>> traumatised by Aptio 4 and alike, where (some issues are OEM-specific I
>>>>> think) you can have timer events signalling after ExitBS, there is event
>>>>> clutter on IO polling to the point where everything lags no matter what
>>>>> you do, and even in "smooth" scenarios there may be nothing worth the
>>>>> description "granularity" (events scheduled to run every 10 ms may run
>>>>> every 50 ms). Events are the last resort for us, if there really is no
>>>>> other way. My first GUI implementation worked without events at all for
>>>>> this reason, but as our workarounds got better, we did start using them
>>>>> for keyboard and mouse polling.
>>>>> 
>>>>> Timers do not apply here, but what does apply is resource management.
>>>>> Using EFI_EVENT directly means (to the outside) the introduction of a
>>>>> new resource to maintain, for each caller separately. On the other side,
>>>>> there is no resource to misuse or leak if none such is exposed. Yet, if
>>>>> you argue with APIs like WaitForEvent, something has to signal it. In a
>>>>> simple environment this would mean, some timer event is running and may
>>>>> signal the event the main code waits for, where above's concern actually
>>>>> do apply. :) Again, the recommendation assumes the use-cases are simple
>>>>> enough to easily avoid them.
>>>>> 
>>>>> I think it would be best to sketch use-cases for audio and design the
>>>>> solutions closely to the requirements. Why do we need to know when audio
>>>>> finished? What will happen when we queue audio twice? There are many
>>>>> layers (UX, interface, implementation details) of questions to coming up
>>>>> with a pleasant and stable design.
>>>>> 
>>>>> Best regards,
>>>>> Marvin
>>>>> 
>>>>>> 
>>>>>> Thanks,
>>>>>> 
>>>>>> Andrew Fish.
>>>>>> 
>>>>>>> If I remember correctly you mentioned the UEFI Talkbox before, if
>>>>>>> that is more convenient for you, I'm there as mhaeuser.
>>>>>>> 
>>>>>>> Best regards,
>>>>>>> Marvin
>>>>>>> 
>>>>>>>> 
>>>>>>>> On 4/16/21, Andrew Fish <afish@apple.com <mailto:afish@apple.com> <mailto:afish@apple.com <mailto:afish@apple.com>>>
>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> On Apr 16, 2021, at 4:34 AM, Leif Lindholm <leif@nuviainc.com <mailto:leif@nuviainc.com>
>>>>>>>>>> <mailto:leif@nuviainc.com <mailto:leif@nuviainc.com>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> Hi Ethin,
>>>>>>>>>> 
>>>>>>>>>> I think we also want to have a SetMode function, even if we don't get
>>>>>>>>>> around to implement proper support for it as part of GSoC (although I
>>>>>>>>>> expect at least for virtio, that should be pretty straightforward).
>>>>>>>>>> 
>>>>>>>>> Leif,
>>>>>>>>> 
>>>>>>>>> I’m think if we have an API to load the buffer and a 2nd API to
>>>>>>>>> play the
>>>>>>>>> buffer an optional 3rd API could configure the streams.
>>>>>>>>> 
>>>>>>>>>> It's quite likely that speech for UI would be stored as 8kHz (or
>>>>>>>>>> 20kHz) in some systems, whereas the example for playing a tune in
>>>>>>>>>> GRUB
>>>>>>>>>> would more likely be a 44.1 kHz mp3/wav/ogg/flac.
>>>>>>>>>> 
>>>>>>>>>> For the GSoC project, I think it would be quite reasonable to
>>>>>>>>>> pre-generate pure PCM streams for testing rather than decoding
>>>>>>>>>> anything on the fly.
>>>>>>>>>> 
>>>>>>>>>> Porting/writing decoders is really a separate task from enabling the
>>>>>>>>>> output. I would much rather see USB *and* HDA support able to play
>>>>>>>>>> pcm
>>>>>>>>>> streams before worrying about decoding.
>>>>>>>>>> 
>>>>>>>>> I agree it might turn out it is easier to have the text to speech
>>>>>>>>> code just
>>>>>>>>> encode a PCM directly.
>>>>>>>>> 
>>>>>>>>> Thanks,
>>>>>>>>> 
>>>>>>>>> Andrew Fish
>>>>>>>>> 
>>>>>>>>>> /
>>>>>>>>>>    Leif
>>>>>>>>>> 
>>>>>>>>>> On Fri, Apr 16, 2021 at 00:33:06 -0500, Ethin Probst wrote:
>>>>>>>>>>> Thanks for that explanation (I missed Mike's message). Earlier I
>>>>>>>>>>> sent
>>>>>>>>>>> a summary of those things that we can agree on: mainly, that we have
>>>>>>>>>>> mute, volume control, a load buffer, (maybe) an unload buffer, and a
>>>>>>>>>>> start/stop stream function. Now that I fully understand the
>>>>>>>>>>> ramifications of this I don't mind settling for a specific format
>>>>>>>>>>> and
>>>>>>>>>>> sample rate, and signed 16-bit PCM audio is, I think, the most
>>>>>>>>>>> widely
>>>>>>>>>>> used one out there, besides 64-bit floating point samples, which
>>>>>>>>>>> I've
>>>>>>>>>>> only seen used in DAWs, and that's something we don't need.
>>>>>>>>>>> Are you sure you want the firmware itself to handle the decoding of
>>>>>>>>>>> WAV audio? I can make a library class for that, but I'll definitely
>>>>>>>>>>> need help with the security aspect.
>>>>>>>>>>> 
>>>>>>>>>>> On 4/16/21, Andrew Fish via groups.io <http://groups.io> <http://groups.io <http://groups.io>>
>>>>>>>>>>> <afish=apple.com@groups.io <mailto:afish=apple.com@groups.io> <mailto:afish=apple.com@groups.io <mailto:afish=apple.com@groups.io>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> On Apr 15, 2021, at 5:59 PM, Michael Brown <mcb30@ipxe.org <mailto:mcb30@ipxe.org>
>>>>>>>>>>>>> <mailto:mcb30@ipxe.org <mailto:mcb30@ipxe.org>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On 16/04/2021 00:42, Ethin Probst wrote:
>>>>>>>>>>>>>> Forcing a particular channel mapping, sample rate and sample
>>>>>>>>>>>>>> format
>>>>>>>>>>>>>> on
>>>>>>>>>>>>>> everyone would complicate application code. From an
>>>>>>>>>>>>>> application point
>>>>>>>>>>>>>> of view, one would, with that type of protocol, need to do the
>>>>>>>>>>>>>> following:
>>>>>>>>>>>>>> 1) Load an audio file in any audio file format from any storage
>>>>>>>>>>>>>> mechanism.
>>>>>>>>>>>>>> 2) Decode the audio file format to extract the samples and audio
>>>>>>>>>>>>>> metadata.
>>>>>>>>>>>>>> 3) Resample the (now decoded) audio samples and convert
>>>>>>>>>>>>>> (quantize)
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> audio samples into signed 16-bit PCM audio.
>>>>>>>>>>>>>> 4) forward the samples onto the EFI audio protocol.
>>>>>>>>>>>>> You have made an incorrect assumption that there exists a
>>>>>>>>>>>>> requirement
>>>>>>>>>>>>> to
>>>>>>>>>>>>> be able to play audio files in arbitrary formats.  This
>>>>>>>>>>>>> requirement
>>>>>>>>>>>>> does
>>>>>>>>>>>>> not exist.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> With a protocol-mandated fixed baseline set of audio parameters
>>>>>>>>>>>>> (sample
>>>>>>>>>>>>> rate etc), what would happen in practice is that the audio
>>>>>>>>>>>>> files would
>>>>>>>>>>>>> be
>>>>>>>>>>>>> encoded in that format at *build* time, using tools entirely
>>>>>>>>>>>>> external
>>>>>>>>>>>>> to
>>>>>>>>>>>>> UEFI.  The application code is then trivially simple: it just does
>>>>>>>>>>>>> "load
>>>>>>>>>>>>> blob, pass blob to audio protocol".
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Ethin,
>>>>>>>>>>>> 
>>>>>>>>>>>> Given the goal is an industry standard we value interoperability
>>>>>>>>>>>> more
>>>>>>>>>>>> that
>>>>>>>>>>>> flexibility.
>>>>>>>>>>>> 
>>>>>>>>>>>> How about another use case. Lets say the Linux OS loader (Grub)
>>>>>>>>>>>> wants
>>>>>>>>>>>> to
>>>>>>>>>>>> have an accessible UI so it decides to sore sound files on the EFI
>>>>>>>>>>>> System
>>>>>>>>>>>> Partition and use our new fancy UEFI Audio Protocol to add audio
>>>>>>>>>>>> to the
>>>>>>>>>>>> OS
>>>>>>>>>>>> loader GUI. So that version of Grub needs to work on 1,000 of
>>>>>>>>>>>> different
>>>>>>>>>>>> PCs
>>>>>>>>>>>> and a wide range of UEFI Audio driver implementations. It is a much
>>>>>>>>>>>> easier
>>>>>>>>>>>> world if Wave PCM 16 bit just works every place. You could add a
>>>>>>>>>>>> lot of
>>>>>>>>>>>> complexity and try to encode the audio on the fly, maybe even in
>>>>>>>>>>>> Linux
>>>>>>>>>>>> proper but that falls down if you are booting from read only
>>>>>>>>>>>> media like
>>>>>>>>>>>> a
>>>>>>>>>>>> DVD or backup tape (yes people still do that in server land).
>>>>>>>>>>>> 
>>>>>>>>>>>> The other problem with flexibility is you just made the test matrix
>>>>>>>>>>>> very
>>>>>>>>>>>> large for every driver that needs to get implemented. For
>>>>>>>>>>>> something as
>>>>>>>>>>>> complex as Intel HDA how you hook up the hardware and what
>>>>>>>>>>>> CODECs you
>>>>>>>>>>>> use
>>>>>>>>>>>> may impact the quality of the playback for a given board. Your
>>>>>>>>>>>> EFI is
>>>>>>>>>>>> likely
>>>>>>>>>>>> going to pick a single encoding at that will get tested all the
>>>>>>>>>>>> time if
>>>>>>>>>>>> your
>>>>>>>>>>>> system has audio, but all 50 other things you support not so
>>>>>>>>>>>> much. So
>>>>>>>>>>>> that
>>>>>>>>>>>> will required testing, and some one with audiophile ears (or an AI
>>>>>>>>>>>> program)
>>>>>>>>>>>> to test all the combinations. I’m not kidding I get BZs on the
>>>>>>>>>>>> quality
>>>>>>>>>>>> of
>>>>>>>>>>>> the boot bong on our systems.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>>> typedef struct EFI_SIMPLE_AUDIO_PROTOCOL {
>>>>>>>>>>>>>>  EFI_SIMPLE_AUDIO_PROTOCOL_RESET Reset;
>>>>>>>>>>>>>>  EFI_SIMPLE_AUDIO_PROTOCOL_START Start;
>>>>>>>>>>>>>>  EFI_SIMPLE_AUDIO_PROTOCOL_STOP Stop;
>>>>>>>>>>>>>> } EFI_SIMPLE_AUDIO_PROTOCOL;
>>>>>>>>>>>>> This is now starting to look like something that belongs in
>>>>>>>>>>>>> boot-time
>>>>>>>>>>>>> firmware.  :)
>>>>>>>>>>>>> 
>>>>>>>>>>>> I think that got a little too simple I’d go back and look at the
>>>>>>>>>>>> example
>>>>>>>>>>>> I
>>>>>>>>>>>> posted to the thread but add an API to load the buffer, and then
>>>>>>>>>>>> play
>>>>>>>>>>>> the
>>>>>>>>>>>> buffer (that way we can an API in the future to twiddle knobs).
>>>>>>>>>>>> That
>>>>>>>>>>>> API
>>>>>>>>>>>> also implements the async EFI interface. Trust me the 1st thing
>>>>>>>>>>>> that is
>>>>>>>>>>>> going to happen when we add audio is some one is going to
>>>>>>>>>>>> complain in
>>>>>>>>>>>> xyz
>>>>>>>>>>>> state we should mute audio, or we should honer audio volume and
>>>>>>>>>>>> mute
>>>>>>>>>>>> settings from setup, or from values set in the OS. Or some one
>>>>>>>>>>>> is going
>>>>>>>>>>>> to
>>>>>>>>>>>> want the volume keys on the keyboard to work in EFI.
>>>>>>>>>>>> 
>>>>>>>>>>>> Also if you need to pick apart the Wave PCM 16 byte file to feed
>>>>>>>>>>>> it into
>>>>>>>>>>>> the
>>>>>>>>>>>> audio hardware that probably means we should have a library that
>>>>>>>>>>>> does
>>>>>>>>>>>> that
>>>>>>>>>>>> work, so other Audio drivers can share that code. Also having a
>>>>>>>>>>>> library
>>>>>>>>>>>> makes it easier to write a unit test. We need to be security
>>>>>>>>>>>> conscious
>>>>>>>>>>>> as we
>>>>>>>>>>>> need to treat the Audo file as attacker controlled data.
>>>>>>>>>>>> 
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> 
>>>>>>>>>>>> Andrew Fish
>>>>>>>>>>>> 
>>>>>>>>>>>>> Michael
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> -- 
>>>>>>>>>>> Signed,
>>>>>>>>>>> Ethin D. Probst
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> Signed,
>>>> Ethin D. Probst
>>> 
>> 
> 
> 
> 
> 


[-- Attachment #2: Type: text/html, Size: 32931 bytes --]