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
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.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this
:
>
> https://github.com/RafaelRMachado/Msc_UefiHda_PreOs_Accessibility
>
> Thanks
> Rafael
>
> Em seg, 29 de mar de 2021 20:24, Ethin Probst
> escreveu:
>
>> Hello everyone,
>>
>> This is the first time I've ever contributed to EDK2. As part of
27;ve missed as well.
On 3/30/21, Ethin Probst via 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,
"Andrew Fish via groups.io"
>
> Reply-To: "devel@edk2.groups.io" , "af...@apple.com"
>
> Date: Tuesday, March 30, 2021 at 10:54 PM
> To: edk2-devel-groups-io , "harlydavid...@gmail.com"
>
> Cc: Rafael Rodrigues Machado
> Subject:
ld 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
>> wrote:
>>
>> Hello there,
>>
>> Some good advice, and thank you! I might add it to the other virtIO*
&g
el-groups-io ,
>> "harlydavid...@gmail.com"
>> *Cc: *Rafael Rodrigues Machado
>> *Subject: *Re: [edk2-devel] VirtIO Sound Driver (GSoC 2021)
>>
>>
>>
>>
>>
>> On Mar 30, 2021, at 5:01 PM, Ethin Probst > <mailto:har
, 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 > <mailto:harlydavid...@gmail.com>> wrote:
>> I'll at
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 wrote:
>
>
>> On Apr 13, 2021, at 9:53 AM, Ethin Probst
>> wrote:
>>
>> Would it be
vice 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
wrote:
> Hi Andrew,
>
> The developer guide for EDK2 drivers is a godsend. Thank you very
> much, and tha
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 abstractio
mentation 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]
> http
uting shouldn't be too difficult though, I don't
think.
On 4/14/21, Andrew Fish wrote:
>
>
>> On Apr 14, 2021, at 9:01 PM, Ethin Probst
>> wrote:
>>
>> Hi Mike and Andrew,
>>
>> Thanks for your responses. I'm looking at the VirtIO block devi
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 wrote:
>
>
>> O
arting point?
On 4/15/21, Andrew Fish wrote:
>
>
>> On Apr 15, 2021, at 1:11 PM, Ethin Probst
>> wrote:
>>
>>> Is there any necessity for audio input and output to be implemented
>>> within the same protocol? Unlike a network device (which is
>>
ecause 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
wrote:
> Hi Andrew,
>
> What would that protocol interface
Oh, okay, thank you.
On 4/15/21, Michael Brown 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
#x27;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 wrote:
>
>
>> On Apr 15, 2021, at 6:03 PM, Michael Brown wrote:
>>
>> On 16/04/2021
ware 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 wrote:
>
>
>> On Apr 15, 2021, at 5:59 PM, Michael Brown wrote:
>>
>> On 16/04/2021 00:42
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
>
>> /
>>
otocol.
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
fu
on can be
found here: https://gist.github.com/ethindp/56066e0561b901c1e276e82ff469436d
On 4/16/21, Andrew Fish wrote:
>
>
>> On Apr 16, 2021, at 10:55 AM, Ethin Probst
>> wrote:
>>
>> Also, forgot to add this before sending: yes, speech synthesizers
>> usually
drew Fish via groups.io wrote:
>>
>>
>>> On Apr 17, 2021, at 9:51 AM, Marvin Häuser >> <mailto:mhaeu...@posteo.de>> wrote:
>>>
>>> On 16.04.21 19:45, Ethin Probst wrote:
>>>> Yes, three APIs (maybe like this) would work well:
>>
Greetings everyone!
I've been selected as a student coder for the audio output protocol
project with Ray Ni and Leif Lindholm as my mentors. This is my first
time doing GSoC and working on EDK II so this will be very enjoyable
and a wonderful learning opportunity for me. (It'll also give me
someth
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/
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_PROTOCOL_EXCLUSIVE);
if (EFI_ERROR(status)) {
Print(L"%r, skipping\n", status);
les, regardless of type -- e.g. initializing
pointers to 0/NULL. But I will definitely try that idea.
On 7/17/21, Andrew Fish wrote:
>
>
>> On Jul 17, 2021, at 9:41 AM, Ethin Probst
>> wrote:
>>
>> Hey all,
>>
>> So my UsbAudio.efi app has hit a bit
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
`HandleBuffer()` is getting me. Should I pre-allocate the buffer?
O
, Andrew Fish wrote:
>
>
>> On Jul 17, 2021, at 10:06 AM, Ethin Probst
>> wrote:
>>
>> 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&
e EXCLUSIVE after
> you find the device you want to manage.
>
> Thanks,
>
> Andrew Fish
>
>> On Jul 17, 2021, at 11:10 AM, Ethin Probst
>> wrote:
>>
>> Thanks, Andrew. So it appears as though only a single handle exists
>> ("AF: DevicePath(..)/P
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.
I was looking at the EHCI driver but I can't determine a couple things:
- Isochronous transfer
For my audio output protocol (I wonder if we should abbreviate it as
AOP?) I need to get access to VirtIO devices in PCIe configuration
space. However, I can't seem to find a way of telling QEMU to use this
device for audio output. Is there something I missed, or something
that does support this?
Yeah, I was talking about presenting a virtio-sound device to the guest.
On 6/7/21, Laszlo Ersek wrote:
> On 06/07/21 13:40, Michael Brown wrote:
>> On 07/06/2021 05:41, Ethin Probst wrote:
>>> For my audio output protocol (I wonder if we should abbreviate it as
>>> AO
in (unless there's another emulator that
implements it). :-(
On 6/7/21, Leif Lindholm wrote:
> On Mon, Jun 07, 2021 at 17:16:00 +0200, Laszlo Ersek wrote:
>> On 06/07/21 13:40, Michael Brown wrote:
>> > On 07/06/2021 05:41, Ethin Probst wrote:
>> >> For my au
Didn't know you could do USB passthrough, that would be useful -- I do
have a USB mixer that I could test. And I could easily get USB
headphones as well.
On 6/9/21, Leif Lindholm wrote:
> On Wed, Jun 09, 2021 at 13:25:16 +0100, Michael Brown wrote:
>> On 09/06/2021 11:57, Laszlo Ersek wrote:
>> >
Hey all,
So Leif and I have discussed this at length but I thought I'd reach
out to all of you for more help.
I'm having a lot of trouble debugging my UEFI app. Here's how I do things:
- I load the app using uefi-run
(https://github.com/Richard-W/uefi-run) like this (from the main EDK
II directo
Hi Andrew,
How do you debug the EFI binary with LLDB? Can LLDB use GDB stubs or
does that work differently?
On 6/11/21, Andrew Fish wrote:
>
>
>> On Jun 11, 2021, at 10:06 AM, Ethin Probst
>> wrote:
>>
>> Hey all,
>>
>> So Leif and I have discussed thi
On 6/11/21, Andrew Fish wrote:
>
>
>> On Jun 11, 2021, at 11:39 AM, Ethin Probst
>> wrote:
>>
>> Hi Andrew,
>> How do you debug the EFI binary with LLDB? Can LLDB use GDB stubs or
>> does that work differently?
>>
>
> Ethin,
>
> Lldb i
source/edk/edk2/Build/MdeModule/DEBUG_GCC5/X64/UsbAudio.debug
The extra weird thing about this is that CpuDeadLoop() is at the start
of the UefiMain function, its not on line 72. The program doesn't even
start there -- it starts by attempting to get the list of
EFI_USB_IO_PROTOCOL handles availa
Your suggestion of adding 0x240 worked. I'm able to successfully step
through the code now. Thank you!
On 6/11/21, Andrew Fish wrote:
>
>
>> On Jun 11, 2021, at 2:29 PM, Ethin Probst
>> wrote:
>>
>> Initial connection and loading symbols:
>> Remote debug
t; On Jun 11, 2021, at 4:29 PM, Ethin Probst
>> wrote:
>>
>> Your suggestion of adding 0x240 worked. I'm able to successfully step
>> through the code now. Thank you!
>>
>
> OK that makes sense. The address in the add-symbol-file command is not the
> lo
type "help" things get to be
jumbled up when scrolling. I don't know if that's a deficiency with my
terminal or EFI though. But that does seem like a QOL improvement.
On 6/23/21, Laszlo Ersek wrote:
> On 06/11/21 19:06, Ethin Probst wrote:
>> Hey all,
>>
>&g
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 interface descriptors, and those contain vital
information that I need to be able to control the audi
elp much.
On 7/1/21, Michael Brown wrote:
> On 01/07/2021 00:01, Ethin Probst wrote:
>> 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-spec
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 actually go and
try to implement them.
I did manage to retrieve a packet dump, from both myself and fro
Update: I just realized I'd made a typo -- the unknown request is
actually a get_min request.
On 7/2/21, Ethin Probst wrote:
> Thank you for all that information, both of you. I didn't realize that
> VirtIO sound would be so complicated. The specification seemed simple
> enoug
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 incredibly close to getting
audio output working, but Qemu did some weird things that I was unaware
of
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 get rid of.
On 4/13/22 22:33, Nate DeSimone wrote:
Hi Everyone,
I hope you are all working on
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 proposal; I
received some feedback and believe I corrected my proposal as directed,
but unless it
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 missed it.)
On 4/22/22 13:40, Ethin Probst wrote:
So this message is a bit of a quest
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 OOP out
of a purely procedural language. It works, but I don't think its
necessarily ideal. But
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 appears more
complex than I'm sure it really is. Could someone explain how it
works? (What I'm co
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 increase the performance
of the function you're calling because the function will be executed
independe
53 matches
Mail list logo
