I'd like to point out that blind people do not just use speed alterations to PCM data to achive such incredibly fast speeds; speed alterations also come from the fact that the speech synthesizer

Hi everyone. About Ethin's question: synthesizer protocol. Perhaps we could extend this to the setup utility too (as well as all other things displayed on the screen)? Answer: This is the target from

Rafael, What member functions to you think that EFI_AUDIO_OUTPUT_PROTOCOL should contain? I'm thinking if we had an EFI_TEXT_TO_SPEECH_PROTOCOL that driver could produce a PCM/Wave buffer, it could

Embedding a speech synthesizer would make things unified across all OSes. You wouldn't need to worry about self-voicing; the speech synthesizer would do that for you. As for the boot manager, yes,

Hi Andrew. As you have mentioned: it writes the NVRAM variables that point to OS loader on the EFI System partition. Note the OS installer is the software that copied OS loader to the EFI System

Answer: The EFI Firmware has some default boot options, but when an OS installs it writes the NVRAM variables that point to OS loader on the EFI System partition. Note the OS installer is the

Hi Ethin. don't know how long ago it expired but it definitely has expired, so you don't need to worry about IP (I don't think).) An OS setup utility would be nice if it weren't for the fact that it

The patent for MP3 expired a year or so ago, if memory serves. (I don't know how long ago it expired but it definitely has expired, so you don't need to worry about IP (I don't think).) An OS setup

Rafael, I'm not exactly the ARM expert, but what we have seen is as long as en EFI PCI driver follows the EFI rules for DMA it should work just fine on all CPU architectures. The historical problem

Another possibility would be to alias the 0xA0000..0xBFFFF SMRAM to 0x30000..0x4FFFF (only when in SMM). I'm not super enthusiastic about adding this kind of QEMU-only feature. The alternative would

Mike:

Hi Everyone Answering Ethin: Answer: Neither do I. Lets wait some ARM expert to give some opinion :) Answering Andrew supported? I assume the CODEC implies the audio file formats that can

"Laszlo Ersek" <lersek@...> wrote: Laszlo, thanks for trying it out. It's nice to hear that approach is somewhat usable. Hopefully we won't have to invent 'paused' cpu mode. Pls CC me on your

I've got good results. For this (1/2) QEMU patch: Tested-by: Laszlo Ersek <lersek@...> I tested the following scenarios. In every case, I verified the OVMF log, and also the "info mtree"

Hi Sean, For host based tests, I agree that VS2017 or VS2019 would be a good choice. Pick the one with the best coverage and easiest for developers to get feedback on the test results and test

Rafael, Did you do much research into CODECs? Like which one(s) should be supported? I assume th CODEC implies the audio file formats that can be decoded? Also how large are the audio files? Is the

If other platforms are PCI-based (i.e. allow us to scan the PCI bus and figure out where (in MMIO space) the HDA controller is mapped to), then it (theoretically) sould work. I don't know for sure

Hi everyone. So, based on everything was mentioned here. The idea is to propose the creation of two protocols: - EFI_AUDIO_OUTPUT_PROTOCOL: This protocol should be the responsible for initializing

Hi Everyone Sorry for the delay on the response, to many things happening at the same time. I will try to answer e-mails to this thread every Saturday or Sunday morning at least. About Andrew's and

Currently it is building on Windows with VS2019. VS2017 would be trivial but not worth it in my perspective given how aligned the two are. If you really wanted to do a weekly or nightly build it