Boom sound when using audiodxe #2073
Comments
|
It will be the order of sound card init commands. Check the |
|
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? |
|
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 |
|
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. |
|
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?) |
|
Yes, Duang means the chime. |
|
@franksfc Have you tried |
|
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. |
|
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? |
|
it booms 10s before the chime |
|
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 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. |
|
Thanks! I will always be there if you need any further information. |
|
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. |
|
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). |
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). |
|
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. |
|
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. |
I think you missed my other comments. |
|
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...) |
|
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). |
|
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. |
|
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 |
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. |
No worries, I'm just glad you're taking time to address this issue, thank you very much.
I don't think the rest of the setup is relevant, if it is just let me know. |
|
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. |
|
Hi @mikebeaton sorry for the late response, I wasn't home. |
|
@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. |
No worries. |
|
@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:
*Using @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:
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 |
|
Could you see if you can recreate the situation in your first videos, where console debug output carries on after the line |
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. |
|
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 |
|
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. |
|
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). |
|
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). |
|
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). |
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).
I perfectly understand, all the time you spent on it for free is already remarkable, thank you again for that.
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). |
If it was done - certainly very low priority - it would definitely be as an option, with the old behaviour probably remaining the default.
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 |
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? |
|
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 |
|
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)? |
|
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 |
|
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. |
|
What pin should I short the sense one with?
|
|
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 |
|
Tbh at a complete guess, I would have said you might just need to short Head Phone Detection to GND. But that is only if your macOS thinks there is a headphone jack, but just with nothing connected to it. Might be worth a try? If not, I agree it may be more complicated. |
|
I think I'll cut through it and just connect my old case front panel like I did before, I'll do that tomorrow and let you know |
|
Ok I executed extensive tests in all possible configurations and found out there are two distinct sets of booms: one coming from the main speakers connected to the USB soundcard (these are barely audible normally and that's why I never noticed and never brought that up, I had to crank the amplifier volume up to hear them clearly, I also usually have the amplifier off by the time I reach the login screen), and the known old ones from the little speaker connected to the motherboard via the f_audio header (or via my old case front panel through a jack-jack cable and some crocodile connectors and then to the f_audio header, I also tested with headphones instead but the result are identical, although the booms are fainter and more difficult to identify).
I summarized the tests setup in this table:
I made videos of all 6 tests and included the corresponding opencore boot log txt here. I decided to record the videos with the main speakers volume cranked up to catch those booms too, but later I realized they also occur by simply unplugging the USB soundcard and plugging it in again with the system already on, so I discarded them as not being part of the booms issue and I will ignore them (I will only signal on screen those coming from the small speaker in the videos, ignore the rest), although they occur regardless of AudioDxe being enabled, so maybe they are related to what you are reporting? TEST 1
TEST 2
TEST 3
TEST 4
TEST 5
TEST 6
Conclusions: I don't know if any of this is useful to you, I honestly just wanted to put everything down once so to have something organized to reference, and I hope you can recognize some of those lines and maybe infer the cause from those. |
|
It would help if you could summarize the tests and booms in a table, so maybe TEST1-TEST6 across the top, and a description of the various booms down the side (a bit like my table, but with more entries, I guess!) - and do not leave out the to USB/non-small speaker clicks and pops - you can just describe which speaker they come from in the description. |
|
I had originally started noting all the main speakers booms in the videos and in the comment too, but stopped and erased them after I found out they also occur when unplugging and plugging back the USB soundcard while the system is already on (this makes me think it is not related to the original issue, even though I just tested with windows and this doesn't occur), I won't go back and redo it because it was taking a huge time and their timing was not as accurate as the others so the lines they were appearing at were often different between tests, but I can do a table no problem:
*In this setup it is not a single boom but rather two distinct booms but very close to each other so that they are discernible only through the slo-mo function of the video, in person they sound like a single noise, although qualitatively different than the others. Here is an overall scheme of the boom pattern regardless of the test considered:
|
Here is a recording of my issue. I set my SetupDelay to 1000. There is always a boom sound before the driver tries to play the chime. I know the boom sound may happen in some cases such as booting the PE, but it never happens when booting the windows. Hope I have made it clear. |
|
Thanks for the recording. It is accepted that there is an issue, which will be annoying to people on whose setup it shows. In fact I was able to replicate something very similar on my headphone jack. But it's likely to be a fairly significant investment of time to figure out how to resolve this (and very likely in some systems it will not be fully resolvable). 'Help wanted' label still applies, for anyone who has, or wants to gain, the necessary skills to look at this. |
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
The text was updated successfully, but these errors were encountered: