aren't the Base*Libs there in case you want to override existing implementations or implement custom versions of them? I'm pretty sure that's the logic behind it -- its a hack of sorts to try to get O

Just inquiring if anyone noticed this. I can see how it'd get lost in the noise -- I just haven't heard anything since my initial feedback for my proposal. (Or if someone did see this I probably misse

So this message is a bit of a question and an information dump; if you want me to split this off into two separate discussions that's fine by me. First, I'm writing to inquire about the status of my p

Hi Nate, I've submitted my proposal. I ran into some accessibility problems with the "project technologies" part, so there might be random junk there that was added that I couldn't figure out how to g

Hi all, I'm writing because I'm considering applying once again for GSoC to continue my work on the audio output subsystem, specifically focusing on either HDA or USB audio. Last year I came incredibl

I think another problem that we need to consider is that to my knowledge, the MP services do not allow for thread scheduling at all. You can run a call back on multiple processors, but that won't incr

Hey all, I've come across a situation where I need linked lists but I don't know how to actually use the linked list functionality. Looking at the API and existing uses of it doesn't really help -- it

Hello all, A few days ago Leif determined that the USB DXE does not implement isochronous transfers. This will make USB Audio quite impossible as the audio data endpoint requires isochronous transfers

Tried this and I still get that invalid handle. Definitely confused where that's coming from.

Thanks, Andrew. So it appears as though only a single handle exists ("AF: DevicePath(..)/Pci(0x1D,0x0)/USB(0x0,0x0)) USBIO") but my app is getting two handles, one of which doesn't actually exist. I s

Okay, so I just tried dh -v 7EDE4C18 (that was the handle that I'm getting from `HandleBuffer()`) and it says "dh: Handle - '7EDE4C18' not found". So I'm definitely confused because that's what `Handl

I mean, possible... The code I'm using to initialize the handle buffer is this: ```C EFI_STATUS EFIAPI UefiMain(IN EFI_HANDLE imageHandle, IN EFI_SYSTEM_TABLE* st) { Print(L"Attempting to find USB IO

Hey all, So my UsbAudio.efi app has hit a bit of a roadblock. This code: ```C status = st->BootServices->OpenProtocol(handles[i], &gEfiUsbIoProtocolGuid, (void**)&UsbIo, imageHandle, NULL, EFI_OPEN_PR

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. Cu

Update: I just realized I'd made a typo -- the unknown request is actually a get_min request.

Thank you for all that information, both of you. I didn't realize that VirtIO sound would be so complicated. The specification seemed simple enough -- but, alas, all things seem simple until you actua

The first: I don't know how to retrieve the descriptors on the UEFI API. I've looked at the Chaos Key DXE, if memory serves, or the display port one -- one of the two. One of them contained a ReadDesc

Hi all, So Leif and I have been working on USB Audio but we've run into a snag. We've encountered a problem -- neither of us knows enough about USB to figure out how to get the class-specific AC inter

Thanks for that tip! Unfortunately, the EFI shell (or, more accurately, the way that the EFI console handles input) makes the way I use it a bit difficult. Since I use a screen reader, I use -nographi

Yeah, maybe. Now I just have to figure out where to even begin with USB audio. The specs aren't useful in determining where to begin -- or at least they aren't from my POV (though that might just be m