audiomx process maxed out

[ianatkinson]

Hi,

We took our labs to Sequoia over the Christmas break and have seen an issue whereby the `audiomxd` process sits using 100% CPU on the computers preventing anyone from logging in and rendering the machines unusable.

We've had mixed success with flattening the machines, it seemed to fix some and on others the problem has reoccured.

The main room this has affected are iMac19,2 machines (2019 Intel iMacs, observed by me) but we have also seen this on a handful of M1 iMacs (I wasn't able to verify this myself so possible red herring).

Has anyone else observed this? I'm at a bit of a loss as to what might be causing it, I think the process is part of Core Audio but we don't do anything weird in terms of audio setup really, there are no peripherals on the machines and nobody logged in. The only audio related software that gets installed is Audacity and Adobe Audition as part of CC.

As this happens at the login window following a reboot there are no user processes running anyway.

My thinking is that whatever sound chip is in those machines has driver issues on 15.2, I did file a bug report with Apple but I'm seeing no google results on this and nothing in the beta notes so I don't suppose it's very widespread.

Has anyone else observed this or can offer any insight please?

Thanks,

Ian

[UpqUsyQcTN]

I just want to validate that this is occurring in our org as well.
I haven't seen it (or been reported) on 15.2 but we're getting reports of it on 14.7.2.

i try force quitting it via terminal and it will come back after ~ five minutes.

[ianatkinson]

Well that's interesting and a bit worrying since our current plan is downgrading the machines to MacOS 14!

Are you seeing the issue on a particular model of machine?

[UpqUsyQcTN]

we've only had three reports of it, including myself.
mbp + mba's

lol, why is there a captcha requirement to post?

[Cupboardsss]

One of my machine's is experiencing this issue - very obviously :( 

Near 100% CPU age by 'audiomxd' but only while the machine is (supposedly) sleeping. Utilisation drops to essentially zero once the user is active again, then case temperature plummets from ridiculous to minimal. 
The user account has already been abolished then rebuilt with an alternate home folder name but the issue returned days later. 

MacMini M4Pro Sequoia 15.2 with several AirPlay speaker options available, a Studio display for regular audio and a Jabra headset (via TB4 KVM). 

Grabbed while logged in: this duration was accumulated overnight, leaving the machine hot to the touch in the morning. 

Sorry, no solutions, just the same hair-pulling frustration... 

[ianatkinson]

Interesting that you say there were some airplay devices in range, this was a thought I had last week whether there was some bluetooth speaker in range (as it was quite a specific area of the building mainly affected) and the machines were trying to handshake with it and failing somehow. I had a plan to see if I could find one in the maxed out state and then send a bluetooth off MDM command to it and see if I could watch the load drop but as we're on with fixing them I've not had the opportunity yet.

[ianatkinson]

OK so this isn't just one model of iMac then if it's been seen across iMac, laptops and minis at this stage.

We've definitely had this when the machine isn't sleeping as the initial reports were from users not being able to log in so they're at the login screen but the machine is so thrashed that it can't get any further once they enter their details.

[Cupboardsss]

Hm. Mine's a residential setup with a mixture of devices running Sequoia - iMac with M4, the Mini & MacBook Air M1. Though physically distributed, they're all in range of at least two devices recognised as AirPlay capable, but only the Mini warms the room (as far as I'm aware at this time) even with the M1 sitting alongside.

All devices auto logout after ~1hr - though I'm not convinced an auto-logout needs to occur for the CPU usage to rise. I shall shutdown the Mini tonight & fire it up again in the morning - but without logging in. I'll be working on the Win machine tomorrow so can keep an eye on the Mini's temperature at any time. 

Goal: after a few days of this, to establish if high CPU sleep usage is tied to a login/logout event. 

[UpqUsyQcTN]

so far so good on 14.7.3 🤞

[ianatkinson]

OK so I don' think it's airport/bluetooth doing this as far as I can tell, I have a machine in this state and the process persists with both radios off (and does the same thing if then terminated):

┌──(admin@bw-wksmac2-13)-[~]

└─$ top -ocpu -l3 | grep -A 10 "Load Avg" | tail -1 | cut -w -f2,3

audiomxd 100.3

┌──(admin@bw-wksmac2-13)-[~]

└─$ /opt/homebrew/bin/blueutil --power OFF

┌──(admin@bw-wksmac2-13)-[~]

└─$ /opt/homebrew/bin/blueutil

Power: 0

Discoverable: 0

┌──(admin@bw-wksmac2-13)-[~]

└─$ networksetup -getairportpower en1

Wi-Fi Power (en1): Off

┌──(admin@bw-wksmac2-13)-[~]

└─$ top -ocpu -l3 | grep -A 10 "Load Avg" | tail -1 | cut -w -f2,3

audiomxd 100.6

[Cupboardsss]

Ahh, I also have BlueUtil installed (for shortcut removal of the BT keyboard rather than for audio purposes) but not familiar enough to determine these details. 
A thought: what about WiFi? I believe AirPlay uses both? 

I noted this evening that the M4 iMac is suffering too, it was reported as lagging but, upon further investigation, the internal audio (system) was not available - not an option for the Mac to utilise. Only the AirPlay devices were listed.
The process showing at ~99% was 'coreaudiom'* but on the Mini the process is 'audiomxd'. There is an observable difference here too. The iMac continues to use coreaudiod while logged in while the Mini only uses audiomxd while the machine is not in use - both are the prime CPU users & crating heat. 

Continuing form yesterday's pursuit: the Mini does not self-heat once booted and then left i.e no logging in (duration of test ~2hrs), but will self-heat ~10-15mins after logging out and shall (almost always) continue to self-heat util logging in again. A quick use of Activity Monitor's CPU Time data in reference to ToD time provides this clue. 

* Shall need to verify the iMac process name's last character tomorrow (m or d). 

Lastly, an odd System Settings > Sound behaviour from the Mini: I screen-video'd non-active AirPlay devices to disappear a few seconds after clicking away form the Settings pane, only to reappear immediately upon reselecting the Settings pane. I can't upload the video so have two stills instead... 

 

Sadly, more odd behaviours being captured rather than answers found. 

I plan to raise an Apple support ticket in the next days, for both machines 'running hot' when not in use. 

[RoseCliver]

---

@ianatkinson wrote:

Hi,

We took our labs to Sequoia over the Christmas break and have seen an issue whereby the `audiomxd` process sits using 100% CPU on the computers preventing anyone from logging in and rendering the machines unusable.

We've had mixed success with flattening the machines, it seemed to fix some and on others the problem has reoccured.

The main room this has affected are iMac19,2 machines (2019 Intel iMacs, observed by me) but we have also seen this on a handful of M1 iMacs (I wasn't able to verify this myself so possible red herring).

Has anyone else observed this? I'm at a bit of a loss as to what might be causing it, I think the process is part of Core Audio but we don't do anything weird in terms of audio setup really, there are no peripherals on the machines and nobody logged in. The only audio related software that gets installed is Audacity and Adobe Audition as part of CC.

As this happens at the login window following a reboot there are no user processes running anyway.

My thinking is that whatever sound chip is in those machines has driver issues on 15.2, I did file a bug report with Apple but I'm seeing no google results on this and nothing in the beta notes so I don't suppose it's very widespread.

Has anyone else observed this or can offer any insight please?

Thanks,

Ian

---

It seems the audiomxd process is consuming 100% CPU on your iMacs, likely due to driver issues or conflicts with the Core Audio framework, especially after the macOS 15.2 update. This could involve audio hardware or third-party software like Audacity and Adobe Audition. Consider rolling back to a stable macOS version, resetting the PRAM/SMC, and testing without audio software installed to isolate the cause. Analyzing system logs might help pinpoint the issue, and since you’ve already filed a bug with Apple, staying updated on any patches or fixes is advisable.

[skepert]

I had a very similar issue on a bunch of my classroom iMacs.  iMacs were updated to Sequoia over winter break.  Running Jamf Connect linked to our Entra school accounts, was version 2.36, recently updated to 2.44, issue was observed on both. 

Basically what I observed was after a user successfully authenticated, either to Entra or using the local admin, the machine would go to a black screen and never get the user to the desktop.  I did observe the audiomxd process running at 99% on these machines, but not during every login, only sometimes.  Multiple troubleshooting steps tried but a full wipe and reinstall was the only solution found initially.  After working with Jamf Support we discovered that the auth.db file may be damaged, as running:  sudo mv /var/db/auth.db /var/db/auth.db.OLD    and then rebooting the machine would allow users to log in again, though typically first login may still take awhile but subsequent logins worked as expected.

My Jamf case is still open, still no root cause found as to what may be corrupting the auth.db file.

[ianatkinson]

That's interesting and something worth looking at!

I did a bit of investigation into this the other day and I started to wonder if there were two things going on. Had the same report of some machines that wouldn't log in, I connected to one on SSH and checked top expecting to see the audiomxd at 100% and it wasn't. I then connected with remote desktop to see what was going on on the screen and immediately the audiomxd spiked.

I then repeated this whole process, rebooted the machine, checked processes, no audiomxd, connected ARD, saw audiomxd spike.

That made me wonder if the audiomxd thing is being caused by the remote desktop and we're tending to see it as we're remoting on to the machines to check them, so a red herring.

I then ran a trace on the audiomxd process to try and see if there were any clues as to what it was actually doing. They're hard to read but I did see bluetooth mentioned so I tried turning that off with blueutil and then once it was off I couldn't make it spike again.

So potentially connecting to a machine with ARD which has bluetooth enabled might trigger the audiomxd issue, but it's such an odd problem I'd be hesitant to say that's the one and only cause of it.

Perhaps this auth.db issue is the root cause of the stuck logins though I will see if I can test that here.

Ian