FIX: Running Motu FW devices in XP SP2, SP3

[TheRealRoach]

Updated: Wed, Apr 16, 2010,

Note: A second thread was started that explored the use of a third-party firewire bus controller driver instead of the Windows version. Read more here: http://www.motunation.com/forum/viewtop ... 14&t=34558

[Edit: To anyone that tries this, please report back with your findings!]

In the post XP SP1 world, all went to sh*t for anyone trying to daisy chain multiple MOTU FireWire [FW] devices, like myself, who was content using daisy-chained first-generation MOTU 896s on my old P4 system. The symptoms of misbehaving MOTU devices - whether using a single unit, or multiple units that were daisy-chained, as is one of the main selling features of the MOTU FW units 896, 828, ultralite, traveller - were the unpredictable and ominous blinking sample rate LEDs of the your MOTU devices later on in the chain that would refuse to sync, random clicks and pops, buzzes and chirps at random frequencies, squeals, drop-outs, all-out failures to load the MOTU FW audio drivers at all, or your MOTU unit not being detected by your system. I searched the forums high and low and eventually concocted a recipe that has worked for me, and i figured that i would share it with anyone else who has come up dry in finding a solution [and the disclaimer is that there will be lots of instructions for manual registry and driver modifications... be careful and take your time because the accidental removal of the wrong files would cause some problems.. and please, read through the whole post before attempting this as some preparation is required]:

I'm currently running from my SIIG FW400 card w/ TI chipset (The Lacie FW800 PCI card is just as stable) -> 896#1 -> (daisy chain) 896#2.
- Current driver is 3.6.7.0 (3.6.8 wouldn't even come close to working, and was the newest driver at the time this was written), running at 64 samples. (2.404ms in, 1.542 out)
- Cubase 4.5.2.274
- 2xMOTU 896s first generation.
- Quad 3.0ghz machine based on an nvidia MB.
- PNY 9400GT video card.
- Windows XP Pro SP3 full updated as of Apr 1, 2009, which I strongly recommend doing.


[Edit: ] There are TWO main system modifications. Part [1] and [2] are required for WinXP SP2 users. Part [1] only is required for fully updated SP3 users. It is also worth noting that best results are after a fresh install of the OS, fully updated SP3 system:

- [1] in Device Manager, I "updated" (more like "back-dated") Texas Instruments IEEE 1394 Host Controller driver to SP1 version by manually changing "1394bus.sys", and "ohci1394.sys" to their SP1 counterparts. In Device Manager -> Properties -> Driver [tab] -> "Driver Details",
C:\Windows\system32\DRIVERS\1394bus.sys should have file version: "5.1.2600.1106 (xpsp1.020828-1920)". C:\Windows\system32\DRIVERS\ohci1394.sys should have file version: "5.1.2600.1106 (xpsp1.020828-1920)" as well, if the file replacement worked properly. Note the "sp1" located within the string of characters and numbers.

- The method of replacing them was as follows:
[1.1] - disconnect all external FW devices
[1.2] - locate the "OHCI Compliant IEEE 1394 Host Controller" (or similar) under "IEEE 1394 Bus host controllers" in Device manager. Right Click and uninstall.
[1.3] - Next, locate "sp2.cab" and "sp3.cab". Move them from your system and place them onto a portable USB drive (or equivilant). Once you have moved these files, disconnect the drive from your system.
[1.4.1] - Lastly, Locate the following files one by one and shift+del: "1394bus.sys", "arp1394.sys", "enum1394.sys", "nic1394.sys" and "ohci1394.sys" and shift+del
[1.4.2] - An effective way to do this is to perform a search of all hard drives for *1394*.* and be sure to select "search hidden files and folders," "Search system folders," and "search subfolders" under "more advanced options" and delete the mentioned files. It is important to perform this operation properly otherwise [1.5] will not "find new hardware" and will re-install the non-SP1 FW drivers. These files are hidden in many places on the system as a safety measure to prevent loss or accidental deletion of important system files.
- [we've effectively killed FW on the computer system by this point and prevented [1.3] XP from automatically re-intalling them upon reboot.]
[1.5.1] - reboot system, at startup, windows will have "found new hardware." When prompted to install drivers, follow the options that will allow you to pick your own via "Have Disk..." option. Direct it to the "ohci1394.sys" and/or "1394bus.sys" versions from SP1.Even if you had since updated to SP2 and SP3, you should still be able to find an SP1.cab lurking in your file system). I also have sp1 files posted here: http://roachmouthrecords.com/firewire_sp1.zip
[1.5.2] - This phase is complete. Use methods in [1] to verify that SP1 versions installed correctly. At this point you can move "sp2.cab" and/or "sp3.cab" back onto your system in their original folder.
[1.5.3] - Reboot system.
[1.6.1] - install MOTU 896 driver (remember I used 3.6.7.0, however 3.6.7.3 and 3.6.7.3 are also favorites)
[1.6.2] - Turn off system. Power on the first MOTU in your chain.
[1.6.3] - Turn on system, the system will auto detect the MOTU hardware and proceed to install three or four drivers. It'll tell you when it's done. When it shows "installation complete", you can shut down your system and power on the next MOTU in the daisy chain and repeat [1.6.3]
[1.6.4] - Reboot.
[1.7] - Install your Digital Audio Workstation.

If you are an XP SP3 user, you are done. If you are an SP2 user, read on:

- [2] The second main part is hacking the registry:
[2.1] - Power off MOTUs and any other FW hardware.
[2.2] - Download http://www.microsoft.com/downloads/deta ... laylang=en Microsoft hotfix to fix firewire bus speed in XP SP2
[2.3] - Reboot.
[2.4] - [the next portion is a well known sequence of steps as published on the RME site, to manually step up the FW bus speed to SP1 levels]
[2.5] - locate the firewire controller within the registry:

To locate the [Motu] FireWire controller information, follow these steps:
[2.5.1] - Open Device Manager. To do this, right-click My Computer on the Start menu, click Manage, and then click Device Manager under System Tools. You can also click Properties under My Computer, and then click Device Manager on the Hardware tab.
[2.5.2] - Locate your FireWire controller in the IEEE 1934 Bus host controllers section.
[2.5.3] - Right-click the FireWire controller entry, click Properties, and then click the Details tab.
[2.5.4] - Click Device Instance Id. You see a string of letters and numbers that is similar to the following: *
PCI\VEN_104C&DEV_8020&SUBSYS_00D81028&REV_00\4&19FD8D60&0&60F0
The information between the two slash marks (\) is the "1394_hc_hw_id". "VEN_104C&DEV_8020&SUBSYS_00D81028&REV_00" is the hardware ID in this example. The information that follows the second slash mark (\) is the "1394_instance_id". "4&19FD8D60&0&60F0" is the instance ID in this example.

[2.6.1] Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\
CurrentControlSet\Enum\PCI\1394_hc_hw_id\1394_instance_id\Device Parameters
[2.6.2] - If the SidSpeed value does not exist in the right pane after you click the Device Parameters subkey in step 2, create it. To do this, point to New on the Edit menu, click DWORD Value, type SidSpeed, and then press ENTER. *
[2.6.3] - Right-click SidSpeed, and then click Modify. *
[2.6.4] In the Value data box, type one of the values that are shown in the following table, and then click OK.Value Speed *
0 S100 speed
1 S200 speed
2 S400 speed (default value)
3 S400/S800 speed (Windows XP Service Pack 1 [SP1] value)
Note If you try to use a value that is larger than 3, SidSpeed will use a value of 0 (S100 speed).
[2.6.5] Quit Registry Editor.*
[2.6.6] Reboot.

DONE.

[Note: Below are various chronological notes and findings from along the way]

Sept 2008 notes
It's worth noting that before completing either modification on an SP2 system, the 896s will hardly work together. Symptoms included squealing (even after computer system was powered off), inability of DAW to load drivers (showing garbled text along with "unknown error occurred ... motu drivers, error #25"), 896s not syncing. Attempt for sync via wordclock is also FUTILE!

When ONLY the first step is completed (re installing of windows SP1 drivers "ohci1394.sys" and "1394bus.sys") the squealing stopped, I WAS able to load the MOTU FW audio drivers into the host DAW, however the second motu would continually fall out of sync... this being characterized by the flashing sample rate LED on 896#2. Playback and recording was continually stuttered, dropped out and unusable. The second Motu would not hold sync whether or not the DAW was loaded (i.e., even on windows idle)

When ONLY the second step is completed (i.e. hacking the registry to manually input SidSpeed value 3) the squealing stopped, I WAS able to load the MOTU FW audio drivers into the host DAW, I was able to hear playback, but it suffered from momentary interruptions in the form of clicks, snaps, buzzes, and dropouts. BUT nonetheless, playback/recording would hold together stable for about a minute at a time.

(Another incidental modification - which may or may not have had an effect - was disabling the motherboards onboard FW connection.)

It was only when BOTH seperate modifications were performed that the system performed flawlessly.

SO, hopefully it stays that way but I will notify you if anything changes.

I was testing the system all afternoon, recording 16 tracks of audio into a session running lots of plugins and a high track count of about 70 tracks, with the use of external digitally sync'd effects in Cubase 4. I was trying to do all sorts of things that would mess up playback/sync/record like minimizing Cubase 4, opening explorer and browsing through active file folders, and the thing kept locked tight. During playback I also turned on an off other units that sync to the MOTUs via AES/EBU in an attempt to budge the sync, but it still held.

I'll be sure to report back any further findings, or problems in what I have mentioned here. Likewise, if anyone else can confirm or deny the success of these steps I would be most interested in fine-tuning this process to making the MOTUs a useable piece of gear again.

Feb 16, 2009 update notes:
Hey everyone. So for an unrelated reason I had to re-install my system and follow my own steps posted here and discovered a few things. First of all I slightly botched step [1.4] and the result was that the 1394bus.sys (and other 1394*.sys files) kept magically reappearing even with the removal of sp2.cab and sp3.cab and prevented the "found new hardware" of step [1.5]. As a workaround I located the 1394 bus in the device manager and used the "update driver..." function and pointed to my files. This is NOT a functioning workaround to fully fix the issue and I learned that the hard way as I continued to experience pops/interruptions in playback while the system was under a moderate load. I decided to reattempt step [1.4] and have now included the new findings. Long story short, Windows turned the files into "hidden files" when it discovered that I was hackin around in the system files. Very clever XP, but not clever enough. muhaha. The new findings are included as steps [1.4.1] and [1.4.2]

[patinsilico]

Do you think theres a chance that this method would work for those just using a single motu via firewire to stop the pop/clicks/stutters etc? Has anyone found a solution for this yet btw?

[TheRealRoach]

I had observed clicks/pops/and other interruptions even in operation of a single MOTU 896, although they increased in frequency and intensity as I added the second 896 to the FW daisy chain, which makes sense because this requires a much greater bandwidth.

I would recommend this "method" and would be surprised if it didn't work. Be sure to follow it very carefully and if you do run into problems/questions, or need clarification of instructions please post it up here.

... Likewise, please report back if this DOES fix your problem.

[hswin]

Hello TheRealRoach,

"Locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\PCI\1394_hc_hw_id\1394_instance_id\Device Parameters"

I looked for the registry entry, but did not find it. I got down to Enum, but no PCI entries anywhere around. I am running XP Pro & SP2, so I don't know if that has anything to do with this dilemma. I would like to have tried this and see if it made any difference in my setup.

Oh well, mine is doing fine, so I may not do anything. Just a passing comment. Having fun with 32 tracks!

Hal

hp zd7000 laptop 2.8 Ghz 1 Gb RAM
XPP SP2
MOTU 896HD (x3)
MOTU Ultralite
SONAR 6.0
many studio mics

[TheRealRoach]

I looked for the registry entry, but did not find it. I got down to Enum, but no PCI entries anywhere around. I am running XP Pro & SP2, so I don't know if that has anything to do with this dilemma. I would like to have tried this and see if it made any difference in my setup.

Hey hswin,

As a general rule: "if it ain't broke, don't fix it." Are you experiencing any of the issues described in post #1 of this thread with your 3 896HDs? If you are running a stock version of SP2 then it certainly would be a surprise if everything was functioning properly.

Nevertheless, the reason you don't see a "PCI" subdirectory is likely because you're on a laptop. To find your specific registry subkey follow the steps under the heading: "To locate the [Motu] FireWire controller information, follow these steps:" It should identify the exact registry location.

[majdid]

Anyone tried this, please let us know the results..hopefully motu will look at this fix and include it in their upcoming driver version, and we will be done with the squeals..i didnt personally tried it thou

[hswin]

Hello Therealroach,

Quote:
"As a general rule: "if it ain't broke, don't fix it. Are you experiencing any of the issues described in post #1 of this thread with your 3 896HDs?"
No, mine are functioning great!

"If you are running a stock version of SP2 then it certainly would be a surprise if everything was functioning properly. "
I had replaced the original hard drive in the laptop, so it is a clean install of XPP and SP2. I did re-install the original SP1 FW drivers as you eluded to in your earlier "fix". All is well even with an Ultralite hung on the end of the chain.


Having fun with 32 tracks in OKC
hp zd7000 laptop 2.8 Gb 1 Gb DDR RAM
Sonar 2S, 3S, 4S, 5S, 5P, 6.12P
MOTU 896HD (x3)
MOTU Ultralite
many studio mics
email: hswin@att.net

[TheRealRoach]

*bump*

Anyone else given this fix a try?

[mandobilly64]

Do you think theres a chance that this method would work for those just using a single motu via firewire to stop the pop/clicks/stutters etc? Has anyone found a solution for this yet btw?

Hey, I'm not sure about SP3 but I recently got the Motu 828mk3 and set it up but was having problems with stuttering in Wavelab, on a 24-96 stereo file. I called tech support, tried everything they said and ended up figuring out it may be the firewire port (VIA), so I bought a new one but wasn't sure if it was Texas Instruments chipset or compatible. Installed it and it would sort of work but was putting a huge load on my CPU, mind you this was just a stereo file. However, every time I closed Wavelab and re-opened it the stuttering re-occurred. If I uninstalled the firewire driver and rebooted the system it would work but still high CPU usage. So today I decided to look for a Texas Instruments chipset firewire card and found one at Guitar Center here in Austin, came home a plugged it in, bamm no problems and CPU usage is back down where it should be and everything is running at top speed.
So I think this may be the biggest problem with the Motu drivers and would highly recommend this Pyro PCI firewire card.

Peace,
Billy

[tonewheeltom]

Good news! This fix worked for me (so far). I'm using a non-Mk 3 Ultralite (mk 1?) that I've had since April and have always had the crazy faders with crackles/distortion.

I'm using Windows XP SP3, and only using one Ultralite with the Dell notebook's original fireware 4-pin port & the Ultralite's separate power supply.

I did less than the above directions. In Device Manager I uninstalled the Dell's firewire. I then just copied the 2 SP1 drivers mentioned in the post, clicked yes to replace the similarly named drivers, rebooted, etc. I never even followed the 2nd step with hacking the registry, but I'm not chaining multiple Ultralites together.

BTW, I uninstalled all MOTU files and reinstalled with the original installation disc. Now I'm back at 6 ms of latency with 256 samples per buffer - not possible with the later MOTU drivers.

6 months of BS, but now thanks to everybody here (and NOBODY at MOTU) it looks like I'll get my $550 worth for this product I read such great reviews about!

[TheRealRoach]

I did less than the above directions. In Device Manager I uninstalled the Dell's firewire. I then just copied the 2 SP1 drivers mentioned in the post, clicked yes to replace the similarly named drivers, rebooted, etc. I never even followed the 2nd step with hacking the registry, but I'm not chaining multiple Ultralites together.

Great! In your case, the second step isn't vital, although if you encounter any problems down the road you know what to do. Your FW bus is likely only operating at 100mbps instead of the firewire rated 400mbps, but that shouldn't be a showstopper any time soon.

[Bridgy]

Hi, I have the same clicking squealing problems so I was glad to see your post.
I managed to do the registry hack without problem but it did not fix my problem so I went on to try part 1 and replace those to SP2 driver files with their SP1 counterparts. No problems finding the SP1 files but was unable to get XP to let me replace them.

I unplugged my Motu, unistalled the device from control panel ok so far. I then shift+deleted those to SP2 files but without me doing anything they magically re-appeared !!! How is that possible? Seems some windows task is refreshing that directory somehow.

Any ideas?

Bridgy

[TheRealRoach]

Hi, I have the same clicking squealing problems so I was glad to see your post.
I managed to do the registry hack without problem but it did not fix my problem so I went on to try part 1 and replace those to SP2 driver files with their SP1 counterparts. No problems finding the SP1 files but was unable to get XP to let me replace them.

I unplugged my Motu, unistalled the device from control panel ok so far. I then shift+deleted those to SP2 files but without me doing anything they magically re-appeared !!! How is that possible? Seems some windows task is refreshing that directory somehow.

Any ideas?

Bridgy

Yes in fact... You reminded me about an important step that I left out. I just edited it into the original post in BOLD and is now labelled step [1.3]. Windows does in fact replace the files automatically on reboot, and thereby prevents you from installing the SP1 versions. Let me know how it goes. This new step is very important, and the "Found New Hardware..." message on reboot in step [1.5] is the indicator that [1.3] was performed correctly.

Those cab files (as you will read) are archives of ALL of the Windows XP drivers that it keeps in its back pocket in the event that the active drivers are deleted accidentally. On reboot while XP is loading, if XP can't find a driver to load (in this case the Windows Sp2/Sp3 FW drivers), it then looks into the "*.cab" files for the archived driver. If it can't find it there, THEN it will it will prompt "Found New Hardware..." when you log into XP.

[Bridgy]

Ok, I tried your suggestion of temporarily moving the cab files off my system onto a USB drive, disconnected it and then tried again to delete the driver files from system32\drivers but they still come back!! I did a search for the two files and they are located in quite a number of other places so I guess Windows just keeps finding them. I think I will give this option a miss as I do not want to move something I shouldn't. I am due to install a new FW card in the next couple of days so I will see if that fixes my issues before coming back to try this again.

Bridgy

[majdid]

just wanted to let you know, i rolled back from SP3 to SP2, then installed the WindowsXP-KB885222-v2-x86-ENU.exe patch (didnt seem to do much thou), things seems slightly better..but still have to do some serious playback/recording tests, playing around with winamp for few hours doesnt says much about if its ok or not..