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.