Cumulative AudioDxe issue #740
Comments
vit9696
added
priority:normal
project:audio
help wanted
|
|
|
Added basic VMware support in master. It seems there are some issues:
|
|
Repetitive boot chime. Let me know how I can help to debug the issue. |
|
Are you aware of the error? Occured on ASUS Prime Z370-A I with with Realtek S1220A, Intel i7 8700K From my OpenCore logs: More info in this reddit thread (I am not OP): |
I've got the same issue. |
Got the same issue here. here is the OC 0.6.3 DEBUG log file. |
|
(just putting this on record) AudioDxe crashes QEMU/KVM Looking into getting emulated audio working via AppleALC for QEMU/KVM macOS guests under Linux. The new audio codec dump functionality for SysReport seems interesting. Unfortunately it results in some kind of QEMU crash: Interested in your thoughts on where the problem lies, ie: OC, QEMU, Linux Kernel etc. Please note it still hangs (without the above "emulation failure" message) if using TCG instead of KVM. To reproduce, fire up a q35 UEFI guest via a modern QEMU. Add emulated audio with something similar to this: -device ich9-intel-hda,bus=pcie.0,addr=0x1b then boot OC with AudioDxe.efi active. Attached is:
Thanks |
|
Good morning @vit9696, I don't know if you are already aware of this problem, but I didn't find anything in the issues. I like the chime, but It blocks the audio device on windows. Is there anything that can be done? |
I'm using a Skylake-based Toshiba Tecra Z50-C with the exact same issue, exact same audio device path, and exact same audioDxe problem - it simply can't find the device at all so no audio is being played at boot. I'm including my debug files as well. This is running with OC 0.7.3, and everything is up-to-date. Audio works perfectly in macOS, just not when trying to use the audio device Perhaps worth investigating. |
|
@Toolybird - Crash in QEMU should be fixed by acidanthera/OpenCorePkg@706cb4e |
@antoniomcr96 - Are you able to confirm whether the new commit makes any difference on this issue? |
|
With latest commit ( acidanthera/OpenCorePkg@70196d0 ) |
Hi mikebeaton, I'm the author of that post on Insanelymac about AudioDxe a year ago. |
|
I'm happy to try to investigate further. Please can you post OC debug log, when booting to Windows, and config.plist of affected system. (Just to confirm, it definitely doesn't produce any such problems when booting to Windows on test machines I have available.) |
ok sure np, I will post after I'm back home from work. |
|
windows boot logs with debug build |
opencore-Dell-G7-7588-Windows-boot-log.txt Here is my files. Sorry for late. |
|
@aksm-unmei @antoniomcr96 Can you check whether this change acidanthera/OpenCorePkg@5b58dc1 makes any difference to the Windows audio issue. Build artefacts are here: https://github.com/acidanthera/OpenCorePkg/suites/4724043814/artifacts/130006681 |
Hi mikebeaton, thank you for your reply and work.
Edit: Also I realized that when booting into Windows, the loading icon is spinning longer than usual. Usually there are 2 spinning rotations, but with AudioDxe, it takes 4 times. |
|
I think the longer delay might just be with the change I tried. Can you confirm whether the current version (not in the test branch you just tried for me) also has the longer delay. Thank you for the additional Windows error. |
|
No need to remove AppleALC. Set MaximumGain to zero. I believe this is pretty clearly spelt out in the docs: MaximumGain is the "Maximum gain to use for UEFI audio, specified in decibels", and "On most Intel HDA hardware the reference level of 0 dB is the loudest volume of the hardware". Therefore, if you want the loudest volume of UEFI sound to be maximum, increase MaxiumumGain from its default of -15 (dB) up to maximum volume, 0 (dB). But I would like to know that it all works on some more systems, since these are new changes, so if you like please try this and let me know what you get. |
Changing Thanks for the work 😁, it now replicates original mac 😉 |
|
I upgraded OC to 0.7.7 and AppleALC.kext seems loaded properly. My desktop is ASUS P5G41T-M LX mainboard with ALC887. Thanks a lot if anyone can help. |
Hi, does anyone knows how to fix it? I'm having the same problem on my Samsung Book E30 (ALC256, layout 11)... Audio in macOS runs perfect, but OCAU/HDA/AudioDxe, seems to hate me, thus no boot-chime for me :( everything's up-to-date (OC DEBUG 0.8.2) |
|
@Horevicht - This bugtracker is meant to be for development, not support. The two sound systems are (largely) separate (about as much separate as one OS from another, i.e. they can possibly leave behind settings which affect each other, but that's it). So you 'just' don't have sound configured correctly in UEFI (i.e. AudioDxe), even though you do in macOS (i.e. AppleALC). Run through the guides again, then try forums. |
Hi, thanks for the reply... I came here because my AudioDxe seems to not find my device path! Even though I have already settup correctly the UEFI sound (i.e. AudioDxe) in bunch other hacks. Thus, I believe it's not a "support" issue but a "development" issue. 00:101 00:005 OC: Deleting NVRAM 7C436110-AB2A-4BBB-A880-FE41995C9F82:SystemAudioVolume - Not Found I'm a enthusiast and wanted so badly a boot-chime... I just don't know what I'm doing wrong... Would love to help with debugging! |
|
@Horevicht Please produce another OC boot log, but with a debug version of AudioDxe.efi involved, not just OpenCore.efi. (Should be producing "HDA:" lines in the log.) |
All my drivers are currently from OC 0.8.2 DEBUG (except for HfsPlus.efi)... Thus, AudioDxe.efi is from OC 0.8.2 DEBUG EFI folder (from opencorepkg)... Is it right? Forgive my stupidness |
|
Okay, can we just double-check this, please add any test value in the arguments to the AudioDxe driver, e.g.: and resend debug log. |
I tried with --gpio-setup argument on AudioDxe, and it takes no effect on log. It's literally the same log, but i'll post it for reference just in a bit... I think the main problem is AudioDxe being loaded and connected, but HDA itself does not (because there is not any HDA lines on log, even though I tried DEBUG version of AudioDxe/AppleALC/OC 0.8.2... |
|
Ok, i did tried bunch of options and different values on: AudioDxe>>Arguments>>testing / --gpio-setup None of this could change my OC Debug log... AudioDxe it's properly loaded and connected, but HDA itself does not show up on any log that I attempt. I spent my whole night 'till morning doing several tests and comparing the logs, but ALL LOGS remains equal. Edit: I did a command on terminal and got this (i.e. my first HDA line log) |
|
@Horevicht - If you set any Arguments at all for AudioDxe you should get at least the one HDA: entry, as you are indeed seeing in at least the final listing above. (With the config.plist you sent, you should have been getting it in all log files - since you are including INFO level logging - so I have some doubt about what is happening there.) It looks to me as if, in this case, AudioDxe is entirely failing to connect to the controller and codecs during the "Connecting drivers" phase. That's not a part I've looked at a great deal so far, but I'll look into it. PS We'd normally see these kind of lines during the "Connecting drivers" phase (plus more, with info on the codec layout, the below is reduced with various greps); the "Connecting controller|codec" parts and their subsequent lines are (should be) triggered by the actual connection process: |
|
@Horevicht - Please could you run |
What about that? |
|
Can you try this modified AudioDxe.efi in your Drivers directory, and send debug o/p (make sure it has at least one HDA line in the output, by using Arguments=test or similar). |
At first try, it played Boot-Chime easily! It was so beautiful that I cried <3 The log: |
|
Good good. Your controller is mis-reporting itself as a legacy (i.e. not HDA) audio controller. There are a couple of possible approaches, but I think the best one is to provide a new argument to force AudioDxe to treat a specified PCI device as an HDA Audio Controller, regardless of what the device says it is; or, put more simply, to force AudioDxe to (try to) connect to one particular device, without checking whether or not the device reports itself as an HDA device. I'll work on that. |
Thanks for it! I’ll be happily waiting! In meantime, can I just use the last AudioDxe.efi (+ Argument=test) that you sent (untill something official comes up in OC build/configuration, or anything like that), or am I supposed to do something else? |
|
Well feel free to use it for now. It'll work for you. It might work for anyone else with the same problem. It's not an official release, it's unsupported, and it'll become out of date and incompatible with the rest of OC at some point, but we'll/I'll add the improved fix to the official release, hopefully shortly. And thanks! |
|
@Horevicht - Could you download the latest build from https://github.com/acidanthera/OpenCorePkg/suites/7285262741/artifacts/293607066 and check that it works for you? AudioDxe will not work (again) with no arguments, but if you now use |
It worked like a charm! |
|
I think that the fix did something wrong with Windows… The Realtek driver do not show any output device, so I uninstalled it and now it shows 2 another kinds of driver in Device Manager (Intel High Definition Audio / Intel High Definition DSP)… Those 2 devices never existed in Device Manager… Is it possible that AudioDxe “replaced” the Realtek driver? When Windows is booted from BIOS, the Realtek driver is properly installed and functional, but when it’s booted from OC, happens that “driver switch”, thus I get no output sound device (i.e. no sound at all) |
|
Well, you've never had AudioDxe attached and working before, at all. It is a known issue that AudioDxe can prevent sound in Windows on some systems, but there are also fixes for that. Look at the other arguments listed in the AudioDxe section of Configuration.pdf. |
The Argument “—restore-nosnoop” resolved the issue! Thanks for all! Keep the good work! |
|
I commented on #2073 adding some more info and speculation on the boom/pop/crackle sound at startup problem. |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
See first line, first post above, please: "This issue is for discussing progress on the work items listed below - unless discussing these specifically, please open a new issue." This does look worth opening a new issue though, so please do. |
|
Done. Thanks! |
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.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.--force-codec(0.9.3) and--force-device(0.8.3) options to AudioDxe also improve boot timesThere 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
The text was updated successfully, but these errors were encountered: