103

I have an external audio interface (M-audio fast track c400). In order to get my macbook to recognize it (display in audio/midi setup), I have to reboot, which is a hassle. I have had other m-audio interfaces that were automatically detected when connected, and I'm pretty sure this one should be the same. Most posts around the internet suggest updating the OS or the software/firmware for the device. I have done all of those with no luck. I am currently running OS X 10.8.5.

Is there a way to force OS X to reload the device? Preferably some command line voodoo that I could fire off quickly when needed or wrap up in a nice little shell script.

Edit: Progress..

The problem appears to be fixed now... I'm not sure how the following solved the problem. If you know, please comment!

Inspired by @sbugert's answer, I started looking into other system daemon's that might do the trick if restarted. As a shot in the dark I killed coreservicesd. This caused the OS to become visibly unstable and I was eventually logged out automatically. To my surprise, when I logged back in, my audio interface was recognized..

Based on that, I hypothesized that killing coreservicesd and logging out/in may be a possible (ugly) workaround. So I unplugged the interface and plugged it back in, and as expected, it was not recognized. So I killed coreservicesd and attempted to log out, however I could not get the system to log out due to the instability caused by killing coreservicesd. I eventually was forced to do a "hard" shutdown (i.e. holding the power button until it turns off). After booting up the macbook again, the interface is now recognized automatically every time I plug it in. I suspect that this "hard" reset may have solved the issue without all the shenanigans with the coreservices daemon, but I have no way to test that.

If anyone can shed light on this, please do!

Edit: It stopped working again so I don't know what's up.

Community
  • 1
RyanM
  • 1,153
  • 2
  • 8
  • 7

6 Answers6

120

EDIT: most likely only works for osx before 10.13

This is what you need, 

sudo kextunload /System/Library/Extensions/AppleHDA.kext
sudo kextload /System/Library/Extensions/AppleHDA.kext

But if you want to kill your coreaudio as well, 

 ps aux | grep 'coreaudio[d]' | awk '{print $2}' | xargs sudo kill

use with caution.
The grep target is written this way specifically to exclude grepping the grep process itself in the ps out.

Ali
  • 1,498
  • 3
  • 14
  • 15
  • 7
    The driver loading/unloading is the only thing that worked to make the Mac detect my headphones. THANK YOU! – wizonesolutions May 17 '14 at 00:26
  • The kext changes caused my laptop to reset - I don't recommend it. The fix for me was to go to `Settings > Sound` and check the Output is set correctly. – vaughan Dec 04 '14 at 17:58
  • @vaughan what is your OSX version? any special hardware? like fancy microphone or speakers or audio devices with specially drivers? – Ali Dec 04 '14 at 21:35
  • This temporarily brings back my sound. In my case, I have had audio issues ever since using a Plantronics USB headset that was provided to test Cisco Jabber. Reloading the AppleHDA kext provides temporary sound but video still lags and stutters. – Aaron Jan 22 '15 at 23:54
  • @Aron you much have some software (driver) installed that (on boot?) replaces or changes things back. Ideally they also provided you with an uninstaller that removes that faulty software/driver. – Ali Jan 23 '15 at 14:32
  • 1
    Works. I had to kill coreaudio first, probably because a track was playing - should've stopped it first. MacBook Pro 13, late 2013, 10.10.1 – VladFr Feb 05 '15 at 14:22
  • @Ali why 'coreaudio[d]' and not just 'coreaudiod'? – dev Oct 24 '15 at 16:51
  • @dev I remember (at least at the time, I guess it was snow leopard?) there were also other processes running, that will get stuck and their name started with `coreaudio` but at least on El Capitan it looks they may not be present. – Ali Oct 25 '15 at 11:41
  • @Ali but I mean from a regexp point of view, isn't `coreaudio[d]` exactly the same as `coreaudiod`? (ie a bracket expression with only one character is equivalent to that single character) – dev Oct 25 '15 at 11:49
  • @dev you are correct. It must have had a `*` at the end or something. Don't really remember. Maybe got deleted in editing or something. Good catch. – Ali Oct 25 '15 at 11:54
  • Using builtin speaker and this fixed when VLC caused all output to become silent. But also it caused volume control not to work. – William Entriken Jul 20 '16 at 20:00
  • Just restarting core audio solved my problem... whatever my problem was. My system just hung for 10s or so and then recovered except for sound. OS X: 10.11.5 -- but volume control doesn't work. Reloading kext's fixed it all the way. – xaxxon Aug 18 '16 at 10:58
  • 11
    (kernel) Can't unload kext com.apple.driver.AppleHDA; classes have instances: (kernel) Kext com.apple.driver.AppleHDA class AppleHDATDMBusManager has 1 instance. (kernel) Kext com.apple.driver.AppleHDA class AppleHDATDMBusManagerCS4208 has 2 instances. Failed to unload com.apple.driver.AppleHDA - (libkern/kext) kext is in use or retained (cannot unload). – Sergei Krivonos Oct 01 '16 at 12:09
  • That is great, thanks. It happens most times I do not disconnect my bluetooth headphone properly, so I have bound those commands to an alias of restartAudio in my .zsh_profile ! – swifty Feb 01 '17 at 19:08
  • Thanks @ali it finally saved me a daily restart I had for the past 3 months of my life! – Aidin Apr 23 '18 at 19:05
  • 3
    I get the same error messages as @Sergei. After doing so, my sound is completely disabled. The icon is grayed out, the function keys don't work. I have to reboot to bring everything back. – Patrick M Aug 06 '18 at 23:49
  • Follow-up question if it does not work on High Sierra [here](https://apple.stackexchange.com/questions/401554/how-to-get-sound-back-after-kextunload-applehda-kext-on-high-sierra). – Karlo Sep 19 '20 at 00:14
99

Try typing this into Terminal:

sudo killall coreaudiod

This will kill the coreaudio process and restart it.

sbugert
  • 1,091
  • 6
  • 5
  • This is exactly what I was hoping for! ...but it doesn't seem to work. Upon executing the command I see all the internal audio devices disappear and reappear in Audio/MIDI setup, but the external interface does not appear with them. I also tried `killall -KILL` and `killall -ABRT` which have the same result. Perhaps something similar but lower-level needs to be done, like restarting/reloading all usb devices? – RyanM Sep 19 '13 at 19:34
  • 2
    This fixed my no sound effects problem. – wisbucky Mar 02 '16 at 08:31
  • 3
    wow my issue was the internal speakers would stop working intermittently until i rebooted. thanks! this did the trick! – Elon Zito Apr 29 '16 at 03:36
  • 2
    Did not restart for me. Sound is just off/disabled now. – Stop Slandering Monica Cellio Aug 31 '16 at 17:27
  • 2
    Did not restart for me as well. Any specific command to start it ? – ayrad Nov 15 '16 at 14:32
  • 2
    @sequoiamcdowell This should work: http://apple.stackexchange.com/questions/187983/sudo-killall-coreaudiod-made-it-so-i-dont-have-any-volume-at-all – Hannes Karppila Dec 14 '16 at 04:02
  • 1
    Some applications do not handle the audio daemon going away very well. For example, iTunes may just show a grayed out volume control until you restart it. – Scott Ahten Feb 10 '17 at 21:38
  • this is the correct answer for 10.13, my issue seems to be caused by Spotify. – nzajt Sep 07 '18 at 17:03
  • why is this answer so low - it works for me? Spotify may also be the culprit for me. – Cornelius Roemer Dec 10 '19 at 12:23
  • This worked like a charm for me on macOS Mojave (10.14.6 (18G6032)). – bappak Oct 13 '20 at 18:08
16

The "proper" way to restart coreaudiod is this: sudo launchctl kickstart -kp system/com.apple.audio.coreaudiod

JGurtz
  • 328
  • 2
  • 6
4

Same solution but with different variation

sudo kill -9 `ps ax|grep 'coreaudio[a-z]' | awk '{print $1}'`
julkiewicz
  • 783
  • 1
  • 5
  • 7
user1573604
  • 161
  • 4
  • 7
    Don't use `kill -9` just for the sake of it. A bare `kill` is perfectly sufficient to halt the daemon in normal circumstances. Indiscriminate use of `-9` can lead to situations where a daemon shuts down so brutally that you can no longer restart it. – dland Dec 19 '14 at 09:15
0

I have the same interface and that happened to me a lot when I first got it.

I thought the audio drivers in my Mac were the problem, but it was just the way I plugged in the interface.

Every time I wanted to use it, I had to unplug it and plug it back into the computer.

Dave M
  • 13,138
  • 25
  • 36
  • 47
prodbymrii
  • 11
-2

Here I have discovered that if I select another device before disconnecting the interface (Fast Track C400 too), I can connect it again later with no problem. But if I am using the fast track and then disconnect it, it can't connect again until restart it.

Davi Raubach
  • 1