This issue is for discussing progress on the work items listed below - unless discussing these specifically, please open a new issue.

Currently there are several issues in AudioDxe, which we most likely want to resolve some time.

• Currently most cards physically support 16-bit signed 44100 Hz or 48000 Hz audio streams. However, for audio speech these formats are usually an overkill, as most files are 8-bit unsigned 22000 Hz or 24000 Hz. These formats generally are not natively supported, so AudoDxe silently refuses to play these files. I believe we need to be able to upsample them in the fly the way AppleHda.efi does.
• Currently we only support uncompressed PCM data and can only use .wav containers in particular. This takes a lot of disk space and may affect disk i/o when AudioDxe becomes more performant. I believe we need to support ADPCM QuickTime format in CAF containers, just like AppleHda.
• Calling PlaySound or its async version generally takes for 1-3 seconds for unknown reasons. This is quite undesired for e.g. BeepGen protocol implementation, which produces much slower sequences of beeps (e.g. 3/200/150 beep after the successful login in FV2). It also makes password input in FV2 feel sluggish, as every entered character also adds a beep via VO protocol. I believe we should try to improve performance at the very least.
• I initially wanted to implement BeepGen protocol as a looped call to PlaySound. However, once again, due to its lags it is not possible. Perhaps, even if we do not immediately resolve audio lags, we can at least have a separate interface for looped audio, as currently I have to allocate a buffer equal to sound length, which is dangerous and costly.
• Mono audio produces longer delays than stereo audio between calling PlaySound and actual sound playback compared to stereo audio. I believe it needs to be investigated at the very least as this feels illogical.
• Mono audio only plays on the left channel. This is definitely not right, as mono audio should be streamed to both channels.
• Audio codecs on virtual machines do not work or have issues. VMware audio codec is not detected and I remember that QEMU audio codec also has issues. I am also not positive that AMD works fine or not. I believe we want to support VMware HDA at the very least for testing purposes.
  • Support is now improved: initial boot chime plays correctly on both QEMU and VMware; however both systems have issues (namely badly dropped and choppy sound) when playing sequences of samples, such as when using picker audio assist.
• Setting up audio parameters, such as frequency or channel number, can cache values and be no-op most of the time. Currently it does not, which may add unnecessary delays during audio startup. I believe we need to agree on who handles caching. I am fine with both routes: AudioDxe and OC, but they need to be agreed upon.
• AudioDxe driver connection takes a lot of time. This is probably the biggest problem even taking playback lags into account. I believe we should invent a way to make it less bad, as boot time is very critical for OpenCore.
  • Some improvement achieved via acidanthera/OpenCorePkg@e7ad34e but more still required for slower machines and/or more complex sound card layouts
  • The --force-codec (0.9.3) and --force-device (0.8.3) options to AudioDxe also improve boot times
• Some users (not all) have crackles, pops or even 'booms' at sound card startup using AudioDxe. This means we need to re-order enabling amps and output channels at startup (most likely via an additional option, as there is unlikely to be a one size fits all approach).

There also are code cleanup issues, but this can be handled separately, as cleaning up AudioDxe and putting it to OcSupportPkg is pretty much a dedicated issue.

CC @Goldfish64, @Download-Fritz, @Andrey1970AppleLife