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 dri

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 fr

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 i

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 sho

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 c

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.

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 n

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). Her

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

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 initializ

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 Vir

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

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 lis

Nope, there isn't a necessity to make them in one, they can be separated into two. Your assuming that the audio device your implementing the volume/muting has volume control and muting functionality w

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

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 q

Oh, okay, thank you.

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

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

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, ReleaseStr