Boom sound when using audiodxe

[franksfc]

I have a dell Inpisron 3670 machine with alc867/891. When I use the audiodxe and play the sound, there is always a boom sound before Duang. The speaker is not to be blamed.

opencore-2022-06-26-043816.txt

[mikebeaton]

It will be the order of sound card init commands. Check the Configuration.pdf section for AudioDxe, and see if any of the optional driver Arguments improve the situation.

[franksfc]

Thank you for your help! But I tried the arguments with no luck, including --gpio-setup, --restore-nosnoop and --gpio-pins 0~15. Maybe I haven't understood the configuration.pdf correctly. Could you give me more hints?

[mikebeaton]

Well... I only said try. Idk if those will help you for sure. But it was worth testing because, in AppleALC (for contrast) you have pretty much full control over what commands are sent to the card at audio setup (assuming you are an expert in editing/creating configs). AudioDxe, on the other hand, tries to do some generally suitable things to initialise sound which should work on all/most/many machines. Some of the code paths depend on what hardware it detects, but within a given class of hardware, there is not so much user control over what it does. Those fairly recently added arguments give some additional control.

It sounds like you need an additional option to swap the ordering of ... something (more specifically something to do with the ordering of applying power and enabling amps); investigation required. I didn't author AudioDxe, but have been updating it recently. I don't have a huge amount of time to work on it right now, though...

If you're able to go back to OC 0.7.6 (i.e. before all recent changes to AudioDxe) it would be helpful to know whether that older version still shows the problem or not. (That involves using some fairly different OC settings that you'll need to revert to (use ocvalidate from the relevant version(s) of OC to make sure your config.plist is basically right), so make sure you keep, e.g., a working, bootable USB of current OC as a backup, or do the test using a USB install of the older OC.)

[franksfc]

I'm very glad that I can help improve the audiodxe! I am an old Opencore user and I have been using Opencore since 0.5x. The older versions of audiodxe have the same problem. It's my greatest pleasure to offer any help wanted.

[mikebeaton]

It's helpful to know the older version has the same problem, thanks. I'll have to leave this open for now and get back to you in due course, unless any other devs have time to look sooner. (Btw 'Duang', you do mean 'chime', yes?)

[franksfc]

Yes, Duang means the chime.

[mikebeaton]

@franksfc Have you tried SetupDelay? Depending on your exact meaning of 'boom', possibly you just need this setting. Some sound card amplifiers do not respond immediately to volume changes. Therefore on card init the card can be at max (or other very loud 'default') audio volume initially, and for up to 0.5s after we change the amplifier settings. This introduces a delay before playing the chime to allow for this.

[franksfc]

Unfortunately, no. I noticed 'in microseconds' so I tried 1000,10000,500000,1000000,10000000 and the issue didn't improve at all. I have also tried resettrafficclass and discconecthda quirks. Forgive me if the sentences are grammatically wrong as I am a beginner in English.

[mikebeaton]

Yes, it is microseconds, and the docs suggest up to 0.5s delay, so your values make sense. I assume with the 10,000,000 value you did actually observe a long (10s) delay before the sound plays? If so, is the 'boom' still immediately before the sound, or ~10s before?

[franksfc]

it booms 10s before the chime

[mikebeaton]

Okay, that makes the situation clear: it is indeed the sound card setup ordering (as I suggested above), and not to do with the different problem which SetupDelay can help with.

I don't believe this is affecting many other systems, but some (certainly not all) systems also get pops or crackles at startup (which is a similar issue, and possibly even exactly the same, interacting with your speaker system). I'm going to have to park this for now. But I'll add it as something that needs addressing to the Cumulative AudioDxe issue.

[franksfc]

Thanks! I will always be there if you need any further information.

[MagistraNocte]

Hi, just wanted to say I'm seeing a similar problem too, I'm working on a Powermac G4 mod and I wanted to have an internal speaker to play the boot chime like the original Powermac G4, so i set up a small speaker attached to a small PAM8403 amplifier powered through USB (i actually give it power through the SPDIF motherboard header with some jumper cables, but I also tried giving it the 5V through the USB 1/2 header, the led header, molex and even an external source through my arduino board, the problem is still there, it's not in the power source) connected through a case front panel audio cable to the fronto panel audio header on my motherboard (Gigabyte Z690M DS3H), as soon as the boot chime starts playing I hear a loud pop (the chime itself starts with a loud pop, as if the sound card were abruptly being turned on), then, later in the boot process close to the login screen showing up I hear a couple of other loud pop as if the speakers were powered off and on again or something like that, I ruled out the small speaker or the PAM8403 being the problem since connecting my main speakers to the same motherboard audio header gives the same problem (the pops are not as louds with my speakers but that's probably related to the amplifier i'm driving them with smoothing it up a bit, but the pattern of the pops is exactly the same). it's also notable to add that the problem does not occur when I connect any audio source to my motherboard's rear panel audio out instead of the front panel header, it also doesn't occur when disabling the boot chime in the config.plist (or setting the gain low enough for it to not play, for that matters) so it seems to be related to opencore and the boot chime, but also specifically to the Intel HDA motherboard header channel.

[MagistraNocte]

Ok, I tried adding a delay with SetupDelay and I can confirm too that the first loud pop happens as soon as the motherboard logo disappears regardless of the delay set (with a delay set the chime is pop-less but the two pops near the login screen are still there). ~Also weirdly enough SetupDelay in my version of opencore (0.8.5) doesn't seem to be in microseconds, a value of 10 is an audible delay, a value of 1000 are more or less 10 seconds and a value of 1000000 (which would be 1 second if it were in microseconds) doesn't let me boot at all (I guess it would have booted but it's reading it as a 10000 seconds delay), should I open a separate issue for the SetupDelay bug?~ EDIT: I see SetupDelay was changed from microseconds to milliseconds in opencore 0.8.3, the dortania guide should be updated

[MagistraNocte]

I don't believe this is affecting many other systems

Could this be because it is related to the front panel motherboard header only, and that is not something every user is using? especially not to play the boot chime since front panels usually only have headphones ports and it's not usual for users to already have headphones on before even booting. maybe the issue is actually affecting more systems than we know, if not all (in my case it's just your average alder lake desktop build, nothing peculiar with weird layouts like a laptop). Can anyone confirm there is no pop/boom/crackle sound during boot with the boot chime enabled (and outputted to all the ports) coming out of your front panel headphone port in your system?

[MagistraNocte]

Also worth noting the problem is also present when booting to windows, but since opencore is still used even when booting to windows and the boot chime still plays, this is still probably opencore related

[mikebeaton]

Also worth noting the problem is also present when booting to windows, but since opencore is still used even when booting to windows and the boot chime still plays, this is still probably opencore related

Well, that should be easy to check: on almost all systems (and I am sure on a standard Dell - I assume you are reporting about the same hardware, since you do not say?) you can boot into Windows directly, not via OpenCore (if you set up a native BIOS boot entry for it, if there is not one already).

You can also try using OC, but with and without AudioDxe enabled (obviously when disabled losing your OC boot chime, if you have that set up), to see if the presence of that is what is making the difference.

[MagistraNocte]

Hi, thanks for the reply, I already said in my first comment that disabling the boot chime (or setting its gain so low that it doesn't play) the issue doesn't occur.

[MagistraNocte]

and I am sure on a standard Dell - I assume you are reporting about the same hardware, since you do not say?

I think you missed my other comments.

[mikebeaton]

If the boom happens after boot chime, but not after no boot chime, then sure, the setup which AudioDxe is doing is indeed causing the issue. (Even more so, if we find no boom when AudioDxe is completely disabled in the Drivers section - could you try this? AudioDxe does a bunch of setup when installed, even if it never plays a sound afterwards.) It is very hard to fix these issues with no machine to replicate on though, it really requires someone with some knowledge of audio programming and OC programming, and a machine to try changes on. (I already have a Help Wanted label on this, so...)

[MagistraNocte]

I can confirm no boom is heard with AudioDxe disabled, even though the little speaker itself is still powered by the motherboard (i can hear the background noise when up close).

[MagistraNocte]

my machine is up for testing anything if you need it, audio is my field of work but I'm no programmer, I doubt I could help in that regard unfortunetely.

[MagistraNocte]

with actual headphones connected to a case front panel connected to the f_panel audio header on the motherboard I hear the boot chime but the booms are not really booms anymore, they're way quieter than with the amplified speaker, I can identify them just because I know they're there, but they're barely audible, it's clear that opencore is not the only part of the equation, maybe something to do with impedence difference between headphones and a 4ohm/3watts little speaker? yet the same speaker/amplifier combo connected to the rear panel audio out doesn't play any boom sound

[mikebeaton]

I can confirm no boom is heard with AudioDxe disabled, even though the little speaker itself is still powered by the motherboard (i can hear the background noise when up close).

Okay, so no boom with AudioDxe completely disabled, and also no boom with AudioDxe enabled but the chime volume below the level at which it will play anything? That narrows down where we need to look - i.e. presumably only at the code that initialises things when a sound is actually played, not at anything initialised before that.

There are 100,000 different cards - and I've already dropped in and done fixes for a few of them - this is only a spare-time pursuit, unfortunately - so I can't promise anything especially timely, I'm afraid.

A full OC debug log from your system (with debug versions of OC and AudioDxe) one with the volume up loud enough that the chime is played (and the boom effect confirmed) and one with AudioDxe still enabled but the sound volume low enough that the chime is not played (and lack of boom effect in the case also confirmed) would be helpful.

[MagistraNocte]

this is only a spare-time pursuit, unfortunately - so I can't promise anything especially timely, I'm afraid.

No worries, I'm just glad you're taking time to address this issue, thank you very much. I produced the log you requested (if you need a differen "Target" value in config.plist just let me know, set that to 67 for now), and I also recorded 3 videos of the issue (sorry for the mess! I'm still working on the case mod): the first one with the boot chime and the booms playing (I have highlighted the exact moment of every boom with onscreen text, I hope it's clear enough), the second one with same setup but with the screen in the picture so that hopefully you can match the exact moment the boom takes place with a specific line in the logs (I've noticed the second and third booms corresponds to lines that are not in the log file, right before all those "private" lines, I guess it is because at that time opencore has done its thing and the os has taken on, and so that part of the verbose is logged to some other file inside the OS? if this is the case just let me know where to find it and I will provide it), the third one with no boot chime and no boom sound (here "MaximumGain" is set to -100, previously it was -30). I also set "SetupDelay" to 2000 so that the first boom doesn't get lost in the chime sound (since it seems to be fainter then the two later ones). I also included my config.plist. This is my current setup:

• Opencore version: 0.8.5 (sorry I haven't taken the time to update to 0.8.6 yet, if this is critical just let me know)
• Motherboard: Gigabyte Z690M DS3H (audio codec: Realtek ALC897)
• CPU: i7 12700k alder-lake
• GPU: Sapphire AMD 5700XT (the founder edition looking one, not the pulse or the nitro one)
• small 4ohm/3watts speaker driven by a PAM8403 amplifier chip connected to the motherboard F_audio header (same happens using a real case front panel module with actual speakers connected to it through normal audio jack cable, but it does not happen if connected to the rear motherboard audio out, see my previous comments).

I don't think the rest of the setup is relevant, if it is just let me know. Thank you again for your time. Files

[mikebeaton]

Hi @MagistraNocte - I have put up a test build at https://github.com/acidanthera/OpenCorePkg/actions/runs/3613166325 - please can you download and run the debug version of this.

I have added some additional two second delays during audio setup to try to determine exactly which audio setup command(s) are causing the unwanted noise(s). (It should take about 20 extra seconds to start up - it's adding delays on 2 or 3 different commands, on 2 or 3 different widgets - so be patient.)

I need to know, on the version with the chime which gives clicks or booms, exactly when before the chime the first click or boom sound (or sounds, if there are more than one) occur(s). (E.g. on the video you sent, the initial click/boom was 2 seconds before the start of the chime.) You already have Audio->SetupDelay=2000 in your config, as you mentioned - that was helpful for being sure where the issue occurs; so that I know what delays I am seeing where, just leave that as it is.

Another annotated video with the screen in shot would be very helpful (the first boom - which I am sure you can hear clearly there - is not very audible in the video, so the annotations are useful), plus the associated OC debug log.

[MagistraNocte]

Hi @mikebeaton sorry for the late response, I wasn't home. Thank you again for putting time into this. Here is another video (screen in shot) with text highlights (I managed to put the speaker right next to the screen this time, you should hear everything clear now) and the corresponding opencore log. If you need anything else just let me know.

[mikebeaton]

Okay, that's great. Just to confirm that you are seeing/hearing what I am: there's one click immediately on setting vref 1 on widget 0x1B (and nothing else before or around the chime), and then two clicks just before the macOS login screen is displayed.

The trick will be the setup order, there'll be something else which will ramp up the power more slowly, avoiding the click, and which should be done after enabling the widget vref instead of before, as now. (And the reverse would need doing before the OS starts.) When I get a few more minutes to look at this, I'll hunt for plausible candidates.

[MagistraNocte]

Okay, that's great. Just to confirm that you are seeing/hearing what I am: there's one click immediately on setting vref 1 on widget 0x1B (and nothing else before or around the chime), and then two clicks just before the macOS login screen is displayed.

The first few lines happens fast, it's difficult to tell, looks like it can be anything between "Starting to play chime..." and "Setting vref 1" but it makes sense it is this last one. I can confirm the one you listed are the only clicks I hear.

The trick will be the setup order, there'll be something else which will ramp up the power more slowly, avoiding the click, and which should be done after enabling the widget vref instead of before, as now. (And the reverse would need doing before the OS starts.) When I get a few more minutes to look at this, I'll hunt for plausible candidates.

Again thank you. I understand this issue is not the priority at all, and I really appreciate your work on this.

[mikebeaton]

@MagistraNocte Sorry it's taken me so long to get back to this. I don't think you ever put up a SysReport, please can you set SysReport=true in config.plist, then reboot, and send me the contents of {ESP}/SysReport/Audio folder.

[MagistraNocte]

Sorry it's taken me so long to get back to this

No worries. Here's the requested folder, I used the same debug efi folder I used for past logs and test regarding this issue (I kept a copy), everything should be the same as in previous messages, let me know if you need anything else. Audio.zip

[mikebeaton]

@MagistraNocte - Thanks for that dump. I was playing around with this a bit more last night, and I'm a bit less hopeful.

I can recreate exactly (?) the same booms and pops if using the earphone output from the built in Realtek ALC255 on my Dell 3070 i9 MFF.

I previously understood @franksfc's original report to state that there were no booms and pops at all without AudioDxe (i.e. with that driver disabled), but that is not my experience:

	Without AudioDxe	With AudioDxe (+ SetupDelay*)
Pops on starting machine	yes	yes
Additional pop before chime	no (n/a)	yes
Two pops during macOS boot progress bar	yes	yes
Pops while shutting down macOS	yes	yes
Pops while starting Linux	yes	yes

*Using SetupDelay just helps to separate the audio setup pop from the chime itself.

@MagistraNocte - Can you confirm (or deny) any of the above findings, for your setup?

I also attempted fairly radically changing the setup order - and unfortunately got exactly the same pop, on exactly the same command (i.e. when enabling output amp vref as per the OC log with delays). You can try this alternative version too, if you like, it will be the macOS build artefact from here https://github.com/mikebeaton/OpenCorePkg/actions/runs/4423925293, when it has finished building, so another video with audio, showing the log on screen and being able to hear when it pops, would be useful!

[MagistraNocte]

@MagistraNocte - Thanks for that dump. I was playing around with this a bit more last night, and I'm a bit less hopeful.

I can recreate exactly (?) the same booms and pops if using the earphone output from the built in Realtek ALC255 on my Dell 3070 i9 MFF.

I previously understood @franksfc's original report to state that there were no booms and pops at all without AudioDxe (i.e. with that driver disabled), but that is not my experience: Without AudioDxe With AudioDxe (+ SetupDelay*) Pops on starting machine yes yes Additional pop before chime no (n/a) yes Two pops during macOS boot progress bar yes yes Pops while shutting down macOS yes yes Pops while starting Linux yes yes

*Using SetupDelay just helps to separate the audio setup pop from the chime itself.

@MagistraNocte - Can you confirm (or deny) any of the above findings, for your setup?

I also attempted fairly radically changing the setup order - and unfortunately got exactly the same pop, on exactly the same command (i.e. when enabling output amp vref as per the OC log with delays). You can try this alternative version too, if you like, it will be the macOS build artefact from here https://github.com/mikebeaton/OpenCorePkg/actions/runs/4423925293, when it has finished building, so another video with audio, showing the log on screen and being able to hear when it pops, would be useful!

I can confirm that even with this new test version I get the same results as before:		Without AudioDxe	With AudioDxe (+ SetupDelay*)
Pops on starting machine	yes (this is probably normal and unavoidable because it happens when the audio components first receive power? that's why I never bringed it up)	yes
Additional pop before chime	no (no chime)	yes
Two pops during macOS boot progress bar	no	yes
Pops while shutting down macOS	no (there is one if I'm restarting it but that is the "Pops on starting machine" one)	no
Pops while starting Windows	yes (when starting the machine); no (the one before the chime, because no chime)	yes

Made another video of the boot with the same settings as the last one + SysReport=true and this time I used the slo-mo function of my iphone to better see the lines at wich the 2nd and 3rd booms occurs, it seems the 2nd one appears somewhere around the GTrace synchronization point 1 and the Unsupported PCH lines, while the 3rd appears right in the middle of all those <private> lines. As for the first one: with this test version it appears when the screen is waiting on the bunch of lines that end up with OCC: Install console control (2C17A0B0/0/0), Current - Success. Here is a complete copy of my test EFI folder (with sanitized config.plist), the video, the opencore log for the boot seen in the video, and the SysReport audio folder Thank you.

[mikebeaton]

Could you see if you can recreate the situation in your first videos, where console debug output carries on after the line OCC: Install console control (.....), current - Success? As it is seeing the HDA: log lines on screen compared to the timing of the sounds which helps to show exactly when the issue is occurring. Make sure you install a DEBUG version of everything from that alt. build - well, at least, of AudioDxe.efi as well as OpenCore.efi. (Also, maybe try BuiltinText instead of BuiltinGraphics, etc. - I can't immediately see why this has changed, as you do seem to be using the debug version of AudioDxe.efi: the HDA: lines are in the text log, assuming the text log comes from the same run as the video.)

[MagistraNocte]

Could you see if you can recreate the situation in your first videos, where console debug output carries on after the line OCC: Install console control (.....), current - Success? As it is seeing the HDA: log lines on screen compared to the timing of the sounds which helps to show exactly when the issue is occurring. Make sure you install a DEBUG version of everything from that alt. build - well, at least, of AudioDxe.efi as well as OpenCore.efi. (Also, maybe try BuiltinText instead of BuiltinGraphics, etc. - I can't immediately see why this has changed, as you do seem to be using the debug version of AudioDxe.efi: the HDA: lines are in the text log, assuming the text log comes from the same run as the video.)

Yes, the txt log comes from the same run as the video, I'm not sure why the logging changed, I'm still using the same EFI folder I used for the old videos (I kept an untouched copy of it while using another non-debug one for everyday use), and yes I'm using the debug version of everything (or at least everything I'm using in this EFI folder) that was in the test build you sent me, I was under the assumption that it was logging differently because of fome change on your part.

[MagistraNocte]

Ok changing to BuiltInText reverted it back to how it was in previous videos, strange though, I don't remember ever changing it in the firts place, anyway, here's another video, the chime boom clearly occurs at the enable output amp vref 1 - Success line, the rest is same as my previous comment.

[mikebeaton]

Okay, that one worked. Thank you.

I agree that from your table of results, AudioDxe is negatively affecting your noises at startup (extra clicks that you don't get without it; even though on some systems - such as mine - the same clicks at the same times occur with or without it). Can I confirm one more thing? You do have sound working in macOS itself, right? And if so then, without AudioDxe, that gives no clicks or booms after the very first machine startup click, all the way up to and including macOS starting to play sounds?

If so, I guess my next step should be to look into the AppleALC setup for your machine, since that + AppleHDA apparently does know how to start your sound card without clicks.

[MagistraNocte]

I confirm that without AudioDxe no click (other than the startup one) is ever heard.

Yes my audio is setup correctly with the correct layout id and everything, it works even though I don't use it at all (I have a better external class compliant usb sound card), I must note though that if I use it (i.e. if I connect my main speakers to the integrated output of the motherboard instead of the usb sound card) the sound works but it's very noisy, since my previous build was my first assembled pc (only real macs before that one) and it was also an hackintosh (el capitan+clover, made in 2015) and I was already using this external sound card at the time, I don't really know integrated motherboard sound cards at all and I don't know if this level of background noise is normal and to be expected from them, I know they are a cheap component.

There is also some coil whine problem, coming from my psu I think, and some other (different) from my gpu (rx 5700xt), and some of it seems to end up in the integrated audio signal (maybe it wouldn't be that noisy without this), but this is a known problem with some of these cards in hackintoshes (something to do with power management I think, I don't experience it at all in windows).

[MagistraNocte]

One thing to note: you tested using headphones connected directly to the motherboard, in my current setup instead I have a small speaker (+ amplifier) connected to the hd_audio header on the motherboard (the one you usually connect case front panel to) BUT it is connected through just some jumper cables, i don't have an actual front panel cable connected to it, I'm just using the audio + and - pins to extract the signal to send to the speaker, the rest of the hd_audio header is free, as a result it is not seen as a possible output device by the OS (not even windows) because I have not populated the other pins through which the OS knows that a front panel exists (if you have one) and that headphones are connected to it, so I cannot play any sound through the speaker after boot, AudioDxe on the other hand seems to not care about the sense pin and all and it is able to play the chime through it just fine (although with clicks).

[mikebeaton]

Yes, AudioDxe does not check the sense pins. Making it do so would be a possible upgrade.

Given the ubiquity of pops, clicks and booms (with sufficient amplification) on these sound cards, I think this would have to be moved to low priority. Sorry!

A more like-for-like test would be if you can configure macOS so that it starts up and plays sounds through the very same channel used for the chime on your rig. I'm guessing (as I think you may be suggesting?) that it might end up sounding like my system (i.e. clicks during macOS startup even without AudioDxe).

[MagistraNocte]

Yes, AudioDxe does not check the sense pins. Making it do so would be a possible upgrade.

Please don't! that would completely break my current configuration ahah (it takes advantage from the fact that AudioDxe plays the chime through the connector even though there should be nothing connected to it, this way I can draw just the audio signal from it with jumper cables without having to connect an actual front panel and salvaging it to kind of frankenstein-soldering the speaker into it).

Given the ubiquity of pops, clicks and booms (with sufficient amplification) on these sound cards, I think this would have to be moved to low priority. Sorry!

I perfectly understand, all the time you spent on it for free is already remarkable, thank you again for that.

A more like-for-like test would be if you can configure macOS so that it starts up and plays sounds through the very same channel used for the chime on your rig. I'm guessing (as I think you may be suggesting?) that it might end up sounding like my system (i.e. clicks during macOS startup even without AudioDxe).

Actually according to my first comment in this thread (I had forget about it honestly) this only ever happens to me through the hd_audio header, If I connect something (like my main speakers, the one normally connected to the external usb sound card) to the rear motherboard audio out there are no pops, with or without AudioDxe enabled (that is, if my first comment is to be trusted, since I don't really remember anymore, I should test it again), I was suggesting you should see if you hear the clicks through headphones connected to your case front pane audio out, if you have any (and if it is connected to the hd_audio header on the motherboard like my little internal speaker is) because that would be closer to my setup here (if I remember correctly what I tested back when I wrote my first comment, I had tried using the front panel from my old case, connecting it to the hd_audio header of my current build and connecting my main speakers to it and the booms where there, like you would expect), even though if you hear them from the rear motherboard out that's already enough to say you experience this problem too (although it is different).

[mikebeaton]

Please don't! that would completely break my current configuration ahah

If it was done - certainly very low priority - it would definitely be as an option, with the old behaviour probably remaining the default.

I was suggesting you should see if you hear the clicks through headphones connected to your case front pane audio out

My headphones are connected to my case front panel audio out! (I assume you just mean the normal headphone connector on the front of the case - in a situation like mine with a standard setup.)

[MagistraNocte]

My headphones are connected to my case front panel audio out! (I assume you just mean the normal headphone connector on the front of the case - in a situation like mine with a standard setup.)

Oops! i guess I misread your comment, then your test shuold be equivalent to my current setup

[mikebeaton]

Oops! i guess I misread your comment, then your test shuold be equivalent to my current setup

Well I suppose not quite, because when my headphones are plugged in macOS carries on to produce sound through those, whereas in your case it produces sound through another channel, right?

[MagistraNocte]

In my case macOS outputs sound through the usb sound card (just because I set that in system preferences, I can switch to motherboard out and optical, which I don't have), but only after boot, during boot AudioDxe is set to output sound to the hd_audio header only

[mikebeaton]

Yes that is what I understood. The additional test which I would be interested in is, if you could manage to persuade macOS to output sound through the same channel of the same codec as your chime, then does your system replicate everything on my system, including two clicks at macOS startup (even if you do not use AudioDxe)?

[MagistraNocte]

You mean having an actual front panel connected to the motherboard instead of a couple of jumper cables and selecting it as the audio device in the OS prior to rebooting? I think I did it back before my first comment, I don't quite remember but I could certainly do that again

[mikebeaton]

I don't think there is a need for changing any other connections, as long as you can short the sense pins so macOS will see the output as present and usable.

[MagistraNocte]

What pin should I short the sense one with? this is the pin configuration on my board:

[MagistraNocte]

Actually I recall reading somewhere that shorting the sense pin only tells the OS that a headphone has been connected in the port, not that there is a front panel connected to the motherboard, I think that is more complicated and requires putting specific resistors between some pin