Update/current status on EFI AOP

Update/current status on EFI AOP

[Ethin Probst]

Hello all,

Since first evaluations are upon us in GSoC 2021, I thought I'd
provide an update on the EFI audio output protocol (AOP) and its
current status to ensure that we're all on the same page.

Currently, I've forked the EDK II project and that fork is available
at https://github.com/ethindp/edk2. That fork contains the
UsbAudio.efi EFI application, available under
MdeModulePkg/Applications/UsbAudio. This is my "driver template" and
"USB sandbox" of sorts, and has given me the tools to play around with
USB. Though I struggled at first, all of you were a great help, and I
also must give a shout out to the folks over at OSDev.org for their
assistance as well. Though the status the application is in is not
much as of yet, we're nearly there, at least on the application front.
We don't have working audio output yet, but that's primarily due to me
being (really) confused over the USB specs. Leif gave me a packet dump
to look at and, though that contained some vendor-specific requests,
it gave me a nice overview of what I need to do. Currently, the
application does the primary stage of at least understanding the
device:

* We allocate a reusable 64K buffer to read the configuration,
terminal, and unit descriptors.
* Using these descriptors, we can analyze the devices internal
connections and figure out what the device contains.

There are a few options we can take from this point:

1. We can get the various attributes of the device and each
terminal/unit descriptor, just as the packet dump does, and then set
the interface (alternate setting) and start streaming audio, following
the packet dump as closely as possible; or
2. We can take advantage of the USB basic audio device definition and
assume that the device automatically configures itself to
"comfortable" settings (though the term "comfortable" is left to
interpretation).

The app also takes advantage of UefiUsbLib, and I'm quite grateful
that that library exists, as it abstracts away most of the complex
request handling. I think that we will need to manually set up custom
requests for class-specific requests, however, as the UefiUsbLib
library doesn't appear to allow us to do this. I may be wrong about
this though -- I will look into it again (and maybe make that
possible).

Currently the app prints basic information about each audio device it
finds (controller, streaming or midi), like the USB ADC version,
lengths of descriptors, the number of interfaces in the bInCollection
field, and such. I mainly included this for debugging (for the longest
time it wasn't working and I needed to dig in the QEMU source for
inspiration). However, it does work now, so we can proceed to the good
stuff.

Like I said, the progress may be minimal, but we've definitely made
some and I don't think it will be long until we have at least
primitive audio output.

I've submitted my mentor evaluations already. I've appreciated working
with TianoCore thus far and I definitely will be doing so long after
GSoC is over. :)

-- 
Signed,
Ethin D. Probst