Jump to content

M-Audio (Avid) Fast Track Ultra - El Capitan Workaround


oliveiro
 Share

80 posts in this topic

Recommended Posts

Thank you for this work around Oliverio! While the MIDI function was never utilised by me, I found that with this work around my iPhone could not be detected by OS X. Using your new workaround this is no longer and issue and my iPhone is behaving correctly. I was going to post regarding this issue but your new workaround seems to fix this issue :)

 

Hope youre well.

 

Bill

 

Hi Bill ! My pleasure !

(I'm fine, hope you're well too.)

This other workaround is more homogeneous. It's also a little heavier (than post10's).

Everyone should make their own opinion, on which workaround fits better on their config.

Glad it helped you

Cheeers

Link to comment
Share on other sites

At least one other user reported losing Mouse/Keyboard after trying these workarounds. I'm a bit in the dark on that, since I've had no problem on my rig : I'm on a hackintosh, with pc mouse & keyboard from Logitech, and they're not even using logitech drivers, just Apple HID drivers. On my system, it does not cause any conflict...

 

@ Mazomo : One thing you can start with, is IOregistryExplorer on a working Yosemite (or ElCapitan with working mouse/trackpad/kb):

browse down the tree list in the left panel, till the end of the ACPIplaftorm section, to the USB section. There, you normally see your FastTrack (when it's powered), and all your USB stuff ; you should see sections concerning your HID devices : mouse, trackpad  & keyboard. Inspect the lines there, and try to figure which drivers are used for each devices. That should point you to drivers that need to be reversed to Yosemite Version (and thus, to be compatible with the workarounds described in this topic)

 

I suspect the following :

 

post-460968-0-61428600-1470733353_thumb.png

 

post-460968-0-89193900-1470733369_thumb.png

 

If your report here, I'll try to help.

Link to comment
Share on other sites

Hi oliveiro,

 

Thanks for your excellent post, I have been able to revive my Fast Track Pro unit. However the Bluetooth on my Macbook Pro (2014,1) is now not playing ball. My Magic Mouse and Keyboard are generally working, but the scroll on the magic mouse no longer works. On top of that the Bluetooth preferences pane has completely disappeared.

 

This happened after I followed the steps in post #10. I also followed the steps in post #24 but the issue remained. I did get an error message when trying to install "IOUSBFamily.kext" in post #24. I don't know wether this is relevant or not.

 

Any help would be greatly appreciated, but many thanks for all your efforts in finding the main fix!

Link to comment
Share on other sites

Hi oliveiro,

 

Thanks for your excellent post, I have been able to revive my Fast Track Pro unit. However the Bluetooth on my Macbook Pro (2014,1) is now not playing ball. My Magic Mouse and Keyboard are generally working, but the scroll on the magic mouse no longer works. On top of that the Bluetooth preferences pane has completely disappeared.

 

This happened after I followed the steps in post #10. I also followed the steps in post #24 but the issue remained. I did get an error message when trying to install "IOUSBFamily.kext" in post #24. I don't know wether this is relevant or not.

 

Any help would be greatly appreciated, but many thanks for all your efforts in finding the main fix!

 

Hi there Jhutley, I too had this problem but I managed to get it working again.Ive detailed it in a post on the first page, also are you running a macbook or a hackintosh?

 

Regards

Bill

 

EDIT: Ive attached the IOBluetoothFamily kext from Yosemite for your convenience, try using this in S/L/E using kext wizard. Be sure to back up the original IOBluetoothFamily.kext that is there! 

 

 

Yosemite IOBluetoothFamily.kext.zip

  • Like 1
Link to comment
Share on other sites

Hi Bill, many thanks for the reply. Unfortunately my celebrations were short lived as the Fast Track Pro seems to have become unstable with my Cubase AI5 DAW.

 

I was going to revert to my Time Machine back-up (prior to following oliveiro's instructions) but somehow doing this has corrupted my boot drive... I'm currently trying to deal with that, hopefully I might be able to give this a go soon.

 

Thanks again,

Link to comment
Share on other sites

Hi Bill, many thanks for the reply. Unfortunately my celebrations were short lived as the Fast Track Pro seems to have become unstable with my Cubase AI5 DAW.

 

I was going to revert to my Time Machine back-up (prior to following oliveiro's instructions) but somehow doing this has corrupted my boot drive... I'm currently trying to deal with that, hopefully I might be able to give this a go soon.

 

Thanks again,

 

Ah that sucks J, if you need any assistance with that do let me know. Id be happy to help! 

 

Regards

BIll

Link to comment
Share on other sites

@JHutley

it would be interesting to know what error message you got when trying workaround #2, and what unstable behavior you had with Cuba$e ?

Good luck with your boot restoration, that kind of errors sometimes cost you a week and terabytes to copy, when instead just a 1 byte flag on a partition would have been enough to solve the thing. I hate these situations (! :blink: !)

 

o

Link to comment
Share on other sites

  • 1 month later...

I've had some extra time to further experiment :

I noticed problems with the help of IOregistryExplorer : IOUSBuserclient seems to be broken when using the workaround described in Post10.

Which prevents the Fast Track Ultra MIDI port to be correctly configured by OsX.

(On my system, it also breaks the configuration of my Epson Printer/Scanner, scanner is not seen)

 

To avoid that, I came back to the first workaround :

 

I removed (and backed up as usual) the following files from ElCapitan(10.11.5)/System/Library/Extensions/ :

 

attachicon.gifScreen Shot 2016-08-02 at 11.53.26.png

 

And replaced them (installed with KextUtility) with the following ones from Yosemite(10.10.5)/System/Library/Extensions/ :

 

attachicon.gifScreen Shot 2016-08-02 at 11.54.04.png

 

Some files seem to be missing from the Yosemite folder, but if you check inside the plugins folders of IOUSBFamily.kext, you'll find the related kexts.

So this is basically reversing all USB kexts to yosemite versions.

 

For those of you who can't easily access a Yosemite system, here are the files I'm using (as usual, taken from my clean Yosemite 10.10.5)

 

attachicon.gifYosemite.zip

 

Once that is done, a simple reboot should be enough. After reboot, checking with IOregistryExplorer, the FTU midi channel seems to still be missing, but it gets created when launching the FTU Control Panel (the same happens for my Epson Scanning Device, not seen by OsX until the Epson Scan App gets launched)

 

System seems to be stable so far, I'll report later.

 

I have no midi device (all of my midi controllers are USB), so I cannot further test this workaround as far as the FTU MIDI port is concerned.

Please report here I you can test this.

 

O.

 

Hi Oliveiro,

Sorry for the extended delay! We had a baby so that's been my July & August B)

Back to the fix - rolling back to the Yosemite kexts is not ideal, because it seems that this may have a cascade effect on other peripheral devices (e.g. keyboard and mouse?).

I am no expert in kext editing - what I am wondering is, per your first response: is there a way to simply add a reference to the Yosemite com.apple.driver.AppleUSBMergeNub inside the El Capitan IOUSBHostFamily.kext? Since the M-AudioFastTrackUltra.kext->info.plist is searching for this driver, would this fix the issue? Alternatively, is it possible to edit the plist to point to the AppleUSBHostMergeProperties.kext??

 

 

Curious if there is a more pointed way of going about this rather than rolling everything back. Loved your first fix - just load one kext using the kext utility, reboot, and voila. Elegant. Would be great to complete the fix with midi support while keeping it as simple as you had it!

 

Thanks!

 

PS: Listening to the greatest, creamiest sounds on my M-Audio BX8as thanks to you!! So happy to have this back. Can't wait to get the midi working at the same time!

Link to comment
Share on other sites

Hi Oliveiro,

Sorry for the extended delay! We had a baby so that's been my July & August B)

Back to the fix - rolling back to the Yosemite kexts is not ideal, because it seems that this may have a cascade effect on other peripheral devices (e.g. keyboard and mouse?).

I am no expert in kext editing - what I am wondering is, per your first response: is there a way to simply add a reference to the Yosemite com.apple.driver.AppleUSBMergeNub inside the El Capitan IOUSBHostFamily.kext? Since the M-AudioFastTrackUltra.kext->info.plist is searching for this driver, would this fix the issue? Alternatively, is it possible to edit the plist to point to the AppleUSBHostMergeProperties.kext??

 

 

Curious if there is a more pointed way of going about this rather than rolling everything back. Loved your first fix - just load one kext using the kext utility, reboot, and voila. Elegant. Would be great to complete the fix with midi support while keeping it as simple as you had it!

 

Thanks!

 

PS: Listening to the greatest, creamiest sounds on my M-Audio BX8as thanks to you!! So happy to have this back. Can't wait to get the midi working at the same time!

 

Hey guys, and also congratulations on the baby my friend!

 

I just updated to MacOS sierra on my hackintosh, and noticed something weird. The Fast Track Ultra 8R is recognised by OS X Sierra now? This is fantatic except audio output will not work with it currently. Levels do seem to be coming in via the M Audio control panel however audio playback will result in no sound produced from OS X.

post-1236054-0-43450700-1474415797_thumb.png

post-1236054-0-89644400-1474415804_thumb.png

post-1236054-0-25889700-1474415913_thumb.png

post-1236054-0-06475300-1474415920_thumb.png

  • Like 1
Link to comment
Share on other sites

Hi !

 

@fixmymac : I've been experimenting (A LOT ! :wallbash:) with plist files inside kexts, to no avail. Unfortunately, the only functionnal workarounds I found were the ones described in this topic, sorry (!)

The changes that occurred between Yosemite and ElCapitan, mainly the new "host/client" architecture, which basically replaced one file in Yosemite by two files in ElCapitan, prevents us from simply renaming a file, or fooling the system with kexts references. At any rate, it is beyond my skills and understanding... I'm currently using post#24 workaround, and didn't notice other problems than the ones described in that post ever since. And yes, it might require experimenting to get some Mouse/Keyboard working properly... probably not that hard to solve : it just requires you to identify the proper driver used in Yosemite. But as mentionned before, I didn't meet that problem with my standard logitech PC mouse and keyboard.

 

@mcshmoopy : that sounds like good news ! maybe Sierra brings wider compatibility... did you compare the Ioregistry outputs in Sierra, to ElCapitan's (w/ workaround) ? or Yosemite's ?

 

I have to keep my workstation in good health (lots of work to do with it), so I won't be able to test Sierra before a long time. :blush:

But I still can help interprete Registry outputs.

 

O.

Link to comment
Share on other sites

Hi !

 

@fixmymac : I've been experimenting (A LOT ! :wallbash:) with plist files inside kexts, to no avail. Unfortunately, the only functionnal workarounds I found were the ones described in this topic, sorry (!)

The changes that occurred between Yosemite and ElCapitan, mainly the new "host/client" architecture, which basically replaced one file in Yosemite by two files in ElCapitan, prevents us from simply renaming a file, or fooling the system with kexts references. At any rate, it is beyond my skills and understanding... I'm currently using post#24 workaround, and didn't notice other problems than the ones described in that post ever since. And yes, it might require experimenting to get some Mouse/Keyboard working properly... probably not that hard to solve : it just requires you to identify the proper driver used in Yosemite. But as mentionned before, I didn't meet that problem with my standard logitech PC mouse and keyboard.

 

@mcshmoopy : that sounds like good news ! maybe Sierra brings wider compatibility... did you compare the Ioregistry outputs in Sierra, to ElCapitan's (w/ workaround) ? or Yosemite's ?

 

I have to keep my workstation in good health (lots of work to do with it), so I won't be able to test Sierra before a long time. :blush:

But I still can help interprete Registry outputs.

 

O.

 

 

Hi !

 

@fixmymac : I've been experimenting (A LOT ! :wallbash:) with plist files inside kexts, to no avail. Unfortunately, the only functionnal workarounds I found were the ones described in this topic, sorry (!)

The changes that occurred between Yosemite and ElCapitan, mainly the new "host/client" architecture, which basically replaced one file in Yosemite by two files in ElCapitan, prevents us from simply renaming a file, or fooling the system with kexts references. At any rate, it is beyond my skills and understanding... I'm currently using post#24 workaround, and didn't notice other problems than the ones described in that post ever since. And yes, it might require experimenting to get some Mouse/Keyboard working properly... probably not that hard to solve : it just requires you to identify the proper driver used in Yosemite. But as mentionned before, I didn't meet that problem with my standard logitech PC mouse and keyboard.

 

@mcshmoopy : that sounds like good news ! maybe Sierra brings wider compatibility... did you compare the Ioregistry outputs in Sierra, to ElCapitan's (w/ workaround) ? or Yosemite's ?

 

I have to keep my workstation in good health (lots of work to do with it), so I won't be able to test Sierra before a long time. :blush:

But I still can help interprete Registry outputs.

 

O.

 

Cheers Olivero! Unfortunately I dont have a copy of my El Capitan IORegistryExplorer, but would you mind if I send a copy of my Sierra one over to you? You seem like youre far more knowledgable than me! 

Bill's Macbook Air.ioreg.zip

Link to comment
Share on other sites

Hi Bill,

 

I checked the file from your SIerra registry, strangely, it looks similar, as far as the FTU is concerned, to an untouched ElCapitan registry (ie with a failing FTU), with the same symptoms as the ones described in that post.

 

But as shown in your post's attached screen captures, the control panel detects the FTU : so OsX Sierra (partially) loads the driver. Maybe the failure is related to the "no UUID" shown in your KextWizard window. It's weird that the control panel is able to show sound modulating on the meters, because to my limited understanding, it requires the driver to be properly interacting with OsX USB drivers.

Why you "see" sound, and don't hear it, I could not tell... sorry.

 

I guess the workarounds we use in ElCapitan will work the same for Sierra. To be tested. But as I wrote before, I'm afraid I won't be able to install and test Sierra before spring next year.

 

Don't hesitate to post here, if you do other tests, I'll try to help.

 

Cheers!

Link to comment
Share on other sites

Guys, thanks a lot for trying to make this done.

 

Success on El Capitan gives hopes (however in my case I couldn't make multitouch functions on trackpad work on A1425, wasted several weeks for that, that was scary days).  But mb "Hardware connected" from the start in Sierra can predict an easy fix?

 

BTW, as for update with default fast track ultra driver from Sierra: it seems like the driver have a good connection with changing settings, levels and anything through the driver UI. I can change IO lvls without problems and I can hear the difference while streaming live through my fast track ultra. The only bad part is that there are no sound from macOS directly.  

 

I feel like there is no need to start all this mess with testing and reverting whole usb functionality to Yosemite's since usb-input works fine. Mb we need to point the right kext for the system anyhow?

 

Hope for Oliveiro's help here. I would really appreciate with a right vector for testing. I can verify your ideas on my side or make a remote access through teamviewer etc. We can try simple ideas at first, mb there will be lucky one's.

 

Would be cool to save time for all the users of Fast track ultra.

(Btw, I still haven't found a good alternative for this interface, do anyone know?)

 

 

 

Link to comment
Share on other sites

Hi Diooo ! welcome to the Party !

I'd say one good thing would be to test post10 IOUsbFamily replacement, and report here, with ioregistryexplorer output concerning FTU, and possible related failures in USB devices.

Link to comment
Share on other sites

Hi Diooo ! welcome to the Party !

I'd say one good thing would be to test post10 IOUsbFamily replacement, and report here, with ioregistryexplorer output concerning FTU, and possible related failures in USB devices.

 

Thanks.

 

Unfortunately, replacing IOUsbFamily gave no solution, card behaves like nothing was changed and giving no errors in ioregistryexplorer. Could you please check it from your experienced eye?

This is the log after changing files - https://www.dropbox.com/s/z0dhner06uumkgv/Sierra-ioregistry-after-replacing-iousbfamily.ioreg?dl=0

 

My USB-HDD, for example, seems to be working fine after changing files.

 

**upd:

or maybe it's all cause of "system caches failed to rebuilt due to unknown error.." (

my SIP is off, tried to rebuild caches without familyusb as well. Will try to do this from command line and write about updates

Link to comment
Share on other sites

Don't bother... I mean don't lose your time trying to rebuild caches properly for now, it won't affect what's interesting us...

 

From what I see, there's a change also inside the M-Audio device in the registry : before now and until Yosemite (ElCapitan with our workaround) there was a sub-device to the FTU device, inside the registry, named MaudioUsbRipley (I wonder if it is related to Ellen Ripley :blush:  !). I never figured exactly what it was doing, but from your file's content, and Bill's, I know understand it controls the whole control panel, graphics and feed, everything but the actual sound. It is now replaced (at least in Bill's ioreg) by a "MaudioUsbMother" subdevice ("Mother" ?! I'll end up really believing that there are Alien's Fans at M-Audio ?!? :D ). Anyway, both of them (Ripley or Mother) seem to work in your Sierra systems, and both enable control panel with controls and visual.

 

If you look in your ioreg files, go down to almost the end of the file (scroll, don't search), you'll reach the usb section, and the FTU device is inside. There should be a subdevice created under the second FTU line "fast Track Ultra@3", a "IOUsbInterfaceUserClient" subdevice , which (I guess) drives the actual sound of our FTU. In ElCapitan and Sierra, it's not there, and there's no sound.

 

So we have to find a way to let it load. In Yosemite just IOUsbFamily replacement was enough... apparently it is not sufficient in Sierra. You'll have to try the "whole USB" workaround I believe.

 

The problem, from what I figured when searching for a workaround for ElCapitan, is that "IOUsbInterfaceUserClient" is related to USB system drivers (system kext files) but also to another part of the system called Frameworks : and everytime I tried messing around with frameworks (reversing to yosemite version for instance) I had a major Crash... :blink:. Plus the fact it is heavier changes to the system, which is not our goal...

 

PS : I might be wrong about the Ripley/Mother thing, because Bill is using an FTU"8R" (rack version), and maybe the subdevice was already "Mother" in Yosemite, only Bill could confirm that... But it doesn't change the rest of my (limited and humble) analysis.


Second thoughts : it might be relevant you provide us with the errors appearing in your console log when the system caches fail to rebuild. if you can...

Link to comment
Share on other sites

Don't bother... I mean don't lose your time trying to rebuild caches properly for now, it won't affect what's interesting us...

 

From what I see, there's a change also inside the M-Audio device in the registry : before now and until Yosemite (ElCapitan with our workaround) there was a sub-device to the FTU device, inside the registry, named MaudioUsbRipley (I wonder if it is related to Ellen Ripley :blush:  !). I never figured exactly what it was doing, but from your file's content, and Bill's, I know understand it controls the whole control panel, graphics and feed, everything but the actual sound. It is now replaced (at least in Bill's ioreg) by a "MaudioUsbMother" subdevice ("Mother" ?! I'll end up really believing that there are Alien's Fans at M-Audio ?!? :D ). Anyway, both of them (Ripley or Mother) seem to work in your Sierra systems, and both enable control panel with controls and visual.

 

If you look in your ioreg files, go down to almost the end of the file (scroll, don't search), you'll reach the usb section, and the FTU device is inside. There should be a subdevice created under the second FTU line "fast Track Ultra@3", a "IOUsbInterfaceUserClient" subdevice , which (I guess) drives the actual sound of our FTU. In ElCapitan and Sierra, it's not there, and there's no sound.

 

So we have to find a way to let it load. In Yosemite just IOUsbFamily replacement was enough... apparently it is not sufficient in Sierra. You'll have to try the "whole USB" workaround I believe.

 

The problem, from what I figured when searching for a workaround for ElCapitan, is that "IOUsbInterfaceUserClient" is related to USB system drivers (system kext files) but also to another part of the system called Frameworks : and everytime I tried messing around with frameworks (reversing to yosemite version for instance) I had a major Crash... :blink:. Plus the fact it is heavier changes to the system, which is not our goal...

 

PS : I might be wrong about the Ripley/Mother thing, because Bill is using an FTU"8R" (rack version), and maybe the subdevice was already "Mother" in Yosemite, only Bill could confirm that... But it doesn't change the rest of my (limited and humble) analysis.

Second thoughts : it might be relevant you provide us with the errors appearing in your console log when the system caches fail to rebuild. if you can...

 

Thanks for the detailed explanations, I think they predicted this Alien horror that would happen after El Capitan release in such way  :drool:  

Unfortunately, Kext Utility gave me "unknown error", KCPM Utility Pro said that caches have been rebuilt successfully (but they haven't actually), and on OS X Single mode I had next errors, also I guess they aren't much informative: 

https://drive.google.com/file/d/0B95Z_7OFk36acGpoSVk0cVZFaWM/view?usp=sharing

 

I'm scary to start all the USB revert for now, as I was restoring system on my main computer cause of it as well.. Are u sure we don't have another choices? Hope you'll find those screen helpful.

Link to comment
Share on other sites

Since I'm not taking risk on my main computer, I won't invite you to do so ;) . Let's wait for the moment, until someone has a spare system or spare partition to test "heavier" workarounds on Sierra.

 

your screen capture is useful and relevant, thanks. It shows Sierra can not use IOUsbFamily, (and from its plugins folder, IOUSBMassStorageClass, AppleUSBXHCI (USB3.0), AppleUSBUHCI (USB1.0) fail too)

So let's bet appleUsbEHCI (USB2.0) is ok.

 

First thing first : before installing IOUSBFamily from Yosemite, did you follow the related post procedure, and backed up both IOUSBFamily AND IOUSBHostFamily ?

 

Then, to clarify things : it is possible (wtih SIP disabled) to "install" a kext into an apple system (most of them go into /System/Library/Extension). In that case, "install" means copy the kext in that folder, and set its permissions properly. It does not imply that our mac is then able to use the kext properly : which means load it and the "link" it to the kernel (which is the heart of the system). A kext most of the time relies on other system kexts and files, and there are a lot of mutual relations between all these files. When we try to force an old Yosemite version into a newer system, we mess with that.

 

So sometimes, kextUtility goes fine, but system fails to load the kext and spits an error. The best way to check that, is to open Console.app located in Utilities folder, click on "system.log" on the left panel, and look for any error message while installing the kext with KextUtility.

 

The other thing to clarify is System Cache : when you boot a Mac or a Hackintosh and choose in one way or another to "ignore system caches" or "force reload extensions", boot process parses extensions folders, scans all kexts, then try to load them, once loaded, it links them to the kernel, and then they are ready to be used. Cache building and kernel prelinking is a procedure one can start manually, but which also happens automatically when you install a new kext or device (sometimes it requires a few minutes before system triggers the process). The goal is to "cache" (=store) the list of working kexts, and prelink them to kernel. It allows the system to boot faster when no options is chosen, because the system then just needs to read from that cache file/folder instead of parsing system folders, reading, checking, linking etc... (which before SSD drives could make boot process way longer !)

 

So, you can have a working system, with manually modified kexts (like our workaround for instance) loaded and working, but some dependencies between kexts are not respected, the system detects it and it refuses to rebuild those caches and prelinks. The system works, but is not clean, takes a bit longer to boot, and when you install anything new, it automatically attempts to rebuild caches (about 30 or 40 times) which uses a lot of CPU an disk reads.

 

When searching for the first workaround, I spent time looking at console.app logs, to find any errors related to system cache building, then replace the faulty kext by a yosemite version... until there were no compatibility/dependency errors anymore.

 

That being said, your screen capture confuses me, because it says basically that IOUSBFamily is not used. Unless you forgot to backup and remove the IOUsbhostFamily file, it doesn't make sense to me.

 

Could you do two things please :

open utilities folder, launch System information.app, and click on Extensions in the "software" group on the left panel. We are looking for the versions of the appleusbehci and iousbfamily (screen capture if you like)

open utilities folder, launch Terminal.app and type :

 

kextlibs /System/Library/Extensions/M-AudioFastTrackUltra.kext

 

then :

 

kextlibs /System/Library/Extensions/IOUSBFamily.kext

 

it won't modify anything, just outputs related libraries/kexts to the 2 mentioned kexts.

 

We'll start from here...

And also, please remember I'm not a specialist of any kind, or a coder or anything... I'm just a guy with a non working M-Audio card, who tries to make it work (!)

All I know, I learned it mainly from experience, testing, and from this forum. So I might have made errors, or wrong statements...

 

 

 

PS : "Victoria" as your macbook name , is that for "Hasta la Victoria Sempre" ?

Link to comment
Share on other sites

No, Victoria is just my girlfriend's macbook name :)  Want to test things here before ruining the last chance on my El Capitan machine.  

 

Unless you forgot to backup and remove the IOUsbhostFamily file, it doesn't make sense to me.

 
hm..seems like your instruction on post10 which you've recommended doesn't require removing IOUSBHostFamily file. 

But I tried both choices. Removing kexts inside plugins folder and completely changing original by your modified IOUSBHostFamily file.

 

BTW, I haven't changed anything inside IOUSBFamily yet, so it's still the same file: https://drive.google.com/open?id=0B95Z_7OFk36aZnhiS1FuazFxS0k

and I can see that appleusbehci is changed and not loaded into the system (suppose it's due to the cache's rebuilt problem?) - https://drive.google.com/open?id=0B95Z_7OFk36aRV9OMDUxNDU0OHM

 

 
and commands from Terminal:

kextlibs /System/Library/Extensions/M-AudioFastTrackUltra.kext


For x86_64:
    com.apple.iokit.IOAudioFamily = 205.11
    com.apple.iokit.IOUSBFamily = 900.4.1
    com.apple.kpi.iokit = 16.0
    com.apple.kpi.libkern = 16.0
    com.apple.kpi.mach = 16.0
    2 symbols not found in any library kext.

For i386:
    No libraries found.

    690 symbols not found in any library kext.

and 

kextlibs /System/Library/Extensions/IOUSBFamily.kext
For all architectures:
    com.apple.iokit.IOPCIFamily = 2.9
    com.apple.iokit.IOUSBHostFamily = 1.0.1
    com.apple.kpi.bsd = 16.0
    com.apple.kpi.iokit = 16.0
    com.apple.kpi.libkern = 16.0
    com.apple.kpi.mach = 16.0

For x86_64:
    1 symbol not found in any library kext.
Link to comment
Share on other sites

MY BAD !!!  I edited my previous post accordingly. I wrote too fast and mixed both workarounds (this is not that fresh in my mind) : you are absolutely right, post10 is just a modification of a genuine IOUSBHostfamily.

Sorry for misleading you... :poster_oops:

So the "SingleMode" screen capture you attached in post42 makes reference to IOUSBFamily not loading : if you only modified IOUSBHostFamily when booting that way, maybe the Yosemite's AppleUSB*HCI are not compatible anymore with OsX (Sierra)

 

As far as "AppleUSBEHCI not loaded" is concerned, from what I understand, OsX only uses one of the 4 files : AppleUSBOHCI & AppleUSBUHCI are for USB 1.0 only, AppleUSBEHCI for USB 1.0 & 2.0, and AppleUSBXHCI is for USB 1.0, 2.0 and 3.0. What's strange is that the first Ioreg file you posted showed the FTU driver partially loaded under AppleUSBEHCI. So maybe yes, it is cache related, but normally if system cache is outdated, OsX boots without using it, and thus tries to load each system kext, including the modified AppleUSBEHCI (I suppose your MacBook is USB 2.0 ?). But you still can try force ignoring cache at boot, and then check again.

 

Thanks for the files and screencaps you provided : there's been no change in dependencies between ElCap and SIerra as far as MAudio and IOUSBFamily are concerned. I think I should have asked you to "kextlib" IOUSBHostFamily instead of IOUSBFamily (same confusion I made), but I don't think the output would be different or relevant neither....

 

So I'd say, since the IOUSBHostFamily modification doesn't bring interesting evolution to our matter, maybe the best for now is you to restore all genuine Sierra files (At least, after you'd try to boot force ignoring caches with a modified IOUSBHostFamily)

 

Then, maybe try somthing I did in my first attempts to find a suitable workaround : try reversing IOAudioFamily.kext to Yosemite's version.

In Elcap it did not change much, and was not useful for the FTU to work, but since Sierra seems to enable M-Audio Control Panel, with only actual sound management missing, and since IOAudioFamily is in the dependency list of the M-audio kext, I guess It's worth trying...

 

Or maybe change both IOUSBHostFamily and IOAudioFamily (Yosemite's, or ElCapitan's)

Otherwise, we'll have to track OsX specific USB Audio drivers, if any...

 

Please, keep me posted.

 

Cheers !

 

PS : clever thing to test everything one someone else's computer ! but maybe not one's girlfriend's one :D !!

At first I thought your name's choice was a kind of black magic incantation : "to victory over M-Audio 's mac drivers !"

with all due respect to historical resistances of course :ph34r:

Link to comment
Share on other sites

Wow you guys have been hard at work! Im very impressed

I tried to extract a Yosemite IOAudioFamily but Im not very good at using pacificst so the one I created I dont think was correct. Would any of you fine gents be able to provide me with a Yosemite IOAudioFamily? Ill be able to test to see if I can get audio working then

Link to comment
Share on other sites

Hey Bill (& Diooo), thanks for trying...

 

So, to sum things up, on SIerra you tested :

- genuine system

- genuine with  modified IOUSBHostFamily only (Yosemite AppleUSB*HCI)

- genuine with only IOAudioFamily from Yosemite

 

Were results always the same ?

 

Maybe try IOaudioFamily.kext from ElCapitan, it might be worth it on a genuine Sierra, and then if it fails, on genuine Sierra with a modified IOUSBHostFamily (yosemite files).

Finally , did you try replacing all USB kexts with yosemite files  (if Sierra USB files look the same as ElCapitan's) ?

That's all I can think of for now. Thanks !

 

PS : what are the benefits/improvements between ElCapitan & SIerra (speed ? stability? GUI ?)

  • Like 1
Link to comment
Share on other sites

Hey Bill (& Diooo), thanks for trying...

 

So, to sum things up, on SIerra you tested :

- genuine system

- genuine with  modified IOUSBHostFamily only (Yosemite AppleUSB*HCI)

- genuine with only IOAudioFamily from Yosemite

 

Were results always the same ?

 

Maybe try IOaudioFamily.kext from ElCapitan, it might be worth it on a genuine Sierra, and then if it fails, on genuine Sierra with a modified IOUSBHostFamily (yosemite files).

Finally , did you try replacing all USB kexts with yosemite files  (if Sierra USB files look the same as ElCapitan's) ?

That's all I can think of for now. Thanks !

 

PS : what are the benefits/improvements between ElCapitan & SIerra (speed ? stability? GUI ?)

 

Tbh I dont think there are many benefits from going to Sierra aside from a few gimmicky apple features. I just like everything working on the latest software and what not!

 

Ive actually managed to buy a brand new Tascam US 16x08 which is class compliant and working without drivers now! Ill still be keeping my Fast Track Ultra 8R and when I get some time Ill see if I can go over all the workarounds you listed off again and see if we can be successful!

Link to comment
Share on other sites

 Share

×
×
  • Create New...