This Page will be no longer updated. Please visit the new RME Audio Website
RME - Tech Info

This is the place for you to find more detailed technical information and special details about our products.
Additionally, you will find detailed explanations on various subjects, which didn't fit into the manuals.

RME Tech Info

Firewire 800 under Windows XP SP2 - Information on Speed Problems


Prior to the release of new hardware, RME carry out extensive tests not only of the hardware itself, but also of its compatibility to other hardware. When testing the Fireface 800, we found hardware errors of several manufacturers. More information is found in the Tech Info FireWire 800 Hardware - Compatibility Problems.

Firewire 800 under Windows XP SP2

Windows XP SP1 did not support FireWire800 (1394b). Nevertheless, it worked, although the full performance of FireWire 800 wasn't achieved in some cases. With the release of Service Pack 2, Microsoft decided to no longer 'ignore' FireWire 800, but to treat it correctly according to the current OHCI specifications (Open Host Controller Interface). For Microsoft, at this time 'correctly' means switching to the slowest transfer mode S100, equalling 100 Mbit per second, for reasons of safety and compatibility.

Microsoft quotes unclear OHCI specifications as the reason for this slow down. Indeed OHCI does not clearly define 1394b. Current FireWire 800 chips send a 2-bit speed code of 0x3 (instead of 0x2 = S400) in the Self-ID-Packet 0. But OHCI only knows this code as 'reserved'. At a second glance, however, it becomes obvious that Microsoft have simply not looked closely enough, because there are additional Self-ID-Packets being sent. Self-ID-packet 8 correctly specifies the speed with the three-bit code 0x3 = S800. Packet 8 had been already defined in the '1394a supplement', and is therefore not an innovation of FireWire 800.

Microsoft's proceeding is thus at least controversial. In any case, it's a prime example of a somewhat unworldly bureaucratic-mindedness. Since there are no devices that only support S100, the need to throttle the bus speed does not actually exist. At least we do not know of any such devices, and as it seems Microsoft did not make this change because of actual complaints about incompatibilities. One is simply left wondering ...


Saving the Fireface

This case once again proves the great advantages of a freely configurable hardware. RME has been using FPGAs (Field Programmable Gate Arrays) for years. These can be turned into completely different circuitries by simple flash updates. A combined update of firmware and driver made the Fireface 800 compatible to SP2. For now, the device shows the following behaviour:

  • At 1394b interfaces, the Fireface will work with FireWire 800 (800 Mbit/s)
  • If SP2 is detected, the speed does not decrease to S100, but in one direction only to S400. In the other direction, S800 stays active. With this, the Fireface 800 is still fully operational, just as if it were connected to a FireWire 400 interface (1394a).

This behaviour is introduced with firmware 1.38 and driver version 1.1. The fix will be successful for most users, since FireWire 800 is still relatively rare at the moment. If, however, an external FireWire 800 harddisk is to be used successfully alongside the Fireface, FireWire 800 becomes a necessity. This of course can already create a problem, since our fix only works for the Fireface. An external harddisk would therefore still be operated with S100* under SP2.

* Under SP1, the typical transfer rate of external FireWire 800 harddisks is almost the same as when using PCI, and when using an internal IDE controller. Our test drive, a somewhat older IBM, reaches 39 Mbyte/s. With SP2, the value drops to 10 Mbyte/s.


Other Manufacturers

Special adaptations from other manufacturers are possible as well. For example, LaCie already provides a firmware update for their FireWire 800 harddisks, which brings full performance under SP2. At a closer look, this 'firmware update' seems to install a FireWire filter driver, which knocks out Microsofts S800 detection. Since October, Macpower also provides an update. Although all external FireWire 800 drives use the same Oxford chip (922), a fix like this is limited to products of one company. Therefore, owners of no-name PCI cards and no-name drive cases will probably never get an update or fix ...


Back to SP1?

So is it necessary to uninstall SP2 to get back the previously achieved performance? No. It is sufficient to install the operating system's old FireWire driver. In fact it is already enough to exchange two files [1]. Here's how to do it:

  • Go to the the hidden Windows\Inf directory and copy 1394.inf to a new directory, like \1394_fix.

Before updating to SP2:

  • Go to Windows\system32\drivers and copy ohci1394.sys and 1394bus.sys to \1394_fix. These files have a date around august 2002, and say SP1 in their file properties.

If you already updated to SP2: the old ohci1394.sys and 1394bus.sys are found in Windows\Driver Cache\i386\ Copy the files from this archive into the directory \1394_fix.

If you had not installed SP1: the files are found in, but this archive includes older files that we did not test.

  • Install the SP2 update
  • Go to Windows\system32\drivers and copy these files to \1394_fix: arp1394.sys, enum1394.sys, nic1394.sys

These files are the ones from SP2. There is no need to reinstall all old FireWire drivers. Some of them haven't changed, others are for network use only.

These files are now also found in the, location see above.

  • Rename to

This is necessary, as Windows includes a nice security mechanism, which prevents worst-case-users from accidentally overwriting important driver files with older versions, or even worse, deleting them completely. So if you try to install the mix of driver files in \1394_fix, Windows will automatically install the newer files found in its!

  • Make sure the Fireface is switched off and no other external FireWire device is present.
  • Go to Device Manager, FireWire controller (OHCI xxx, 1394 or similar), Properties, Driver, Driver Update. Select 'No, only this time', 'Install from a list or specific location (advanced)', click 'Next', select 'Don't search I will choose the driver to install', click 'Next', then 'Have Disk'. Now point to \1394_fix. Then continue.
  • Windows will now ask for the path to the file ohci1394.sys and 1394bus.sys. It wants to install the newer ones (see above). Again point to \1394_fix.

That's it. You can now go to Driver Details, and verify that all driver files are from SP2 except the ohci1394.sys and 1394bus.sys, which are from SP1. Next reboot, switch on the Fireface, and check that the Fireface can perform record/playback.

Finally you can rename back to Windows will no longer try to copy the newer driver file until you do a reinstall of the FireWire controller driver. So it makes sense to activate the driver cache security mechanism again.

[1] In the first version of this Tech Info, only the file ohci1394.sys had been exchanged. With this, the throughput rises to good S400. But exchanging the 1394bus.sys as well will activate full 800 Mbit/s.


More information on this topic

Last update: 10/12/2004


MS Patch available for FireWire 800 and SP2

On December 17, 2004, Microsoft published a Knowledge Base article about the FW800 slowdown problem under SP2, confirming the behaviour to be a problem of SP2. At the same time MS released a file update, which has to be installed manually. The article says this update will not be included in later updates and hotfixes, so it must be installed manually whenever needed. The link to the article: (Ersparen Sie sich die deutsche Version ...)

Quote: After you install Windows XP Service Pack 2, some 1394 devices (such as digital cameras that use S400 speed) may not perform as expected. Install this update to help prevent this issue.

So does it fix the Firewire 800 problems?

Yes, it does. Almost ...

The patch installs a new ohci1394.sys, and adds an entry SidSpeed to the OHCI controller in the registry. The documentation from Microsoft on this patch is disappointing. Here's what we found out:

  • After installing this patch, no-name FireWire devices which operate in asynchronous mode seem to be able to use S800, without any further firmware updates etc. The IBM disk in the noname drive enclosure that we use (SpeedStar) now reaches 51 MByte/s (38 at S400, 10 at S100). So this patch seems to give full speed here. Note that the setting SidSpeed had no (in words: none) effect on the transfer rate. It stayed at 51 MB all the time.
  • After installing this patch, FireWire devices which operate in isochronous mode and support higher speeds are no longer slowed down to S100, but to S400. This of course helps the Fireface too, but it still needs our own patch to reach S800 (in one direction). Note that the SidSpeed setting controls the transfer rate. Isochronous devices will slow down to S100, S200 or S400 when changing the reg entry to 0, 1 or 2. According to MS a setting of 3 is expected to give the old behaviour of SP1 - which is not true. While SP1 enabled S800, SP2 with this patch enables only S400.
What does this all mean?

RME recommends to install this patch. It will help you to stay compatible, and also delivers nearly the highest speed possible when using the Fireface. Only users working with three Firefaces could gain a bit more performance by using the old SP1, but might run into trouble at other places. Usually the combination of RME's (driver/firmware included) fix together with SP2 and this MS patch gives trouble-free operation of up to three Firefaces, and with most other FW devices out there.

Last update: 01/31/2005


Copyright © Matthias Carstens.

All entries in this Tech Infopaper have been thoroughly checked, however no guarantee for correctness can be given. RME cannot be held responsible for any misleading or incorrect information provided throughout this document. Lending or copying any part or the complete document or its contents is only possible with the written permission from RME.