Thank you all for the very helpful info thus far. (More below.)
> For the sniffing, should I run the MOTU windows software (I haven't used
> this yet), and sniff on the same PC? Or do I need to stick another
> PC (with the PCILynx card) between the windows PC and the MOTU? What s/w do
> you use to do the sniffing? I've got XP installed on my windows PC, and I
> have another spare desktop that I can put whatever on (currently has FC4).
You require at least 2 PCs. One running the MOTU-supplied software under a
MOTU-supported OS with a standard OHCI firewire card, the other running
Linux with a PCILynx card which has at least 2 external ports. The MOTU is
connected to the Linux PC, as is the other "supported" PC. In other words,
the Linux PC is in the "middle" of the bus.
IOI were also making PCILynx cards when I was out looking for them. From
memory at the time they were quite reasonably priced too - around US$50.
I ended up buying direct from IOI since they had no Australian distributor
and I was very pleased with the way it turned out. Being in the US you'd
have a local distributor I guess. The product URL is
The model number is IOI-1394TT.
> What exactly does PCILynx enable?
The PCILynx chipset passes ALL async firewire packets to its host even if
they are not addressed to the host. Since all firewire audio device
configuration occurs via async packets this is kind of important if you're
doing protocol analysis. The "standard" OHCI-based cards on the other hand
do not pass async packets unless they are addressed to it. This is not a
driver issue - it's in the hardware. The OHCI chips are physically
incapable of passing packets unless they are addressed to it because the
OHCI specification dictates this.
> Would it be worth another try to request the protocol from MOTU? When was
> the last time anyone contacted them? Can you share any past correspondence
> with them?
Hey, you can try, but don't be offended if you get stonewalled. The biggest
problem is that MOTU only provide access to the standard tech support people
via their website - it's not possible to contact someone else higher up the
chain. These people are simply told that that they support X and Y
operating systems and anything else is a no-go. They simply parrot this
company policy back to you and end the exchange. If it were possible to get
access to someone higher up the chain to whom we could explain precisely
what we wanted things *might* be different. Note that even this is doubtful
since the entire company seems convinced that giving out their protocol
amounts to a release of their precious intellectual property. However,
they'd be more chance of success at the upper levels than with the plebs
manning the tech support email address.
It's possible that a phone-based approach might get further but it would
have to be well thought out in advance. You need to avoid getting switched
through to technical support at all costs because otherwise you'll just get
the standard company line repeated back to you yet again. I've toyed with
the idea of trying this but (a) I really can't afford the (potentially
lengthy) international phone call and (b) 3am local time isn't the best time
of day to make such a phone call.
The last time I tried MOTU tech support was in November 2005. At that time
they told me that:
This information is not available through MOTU's tech support as of right
now. However, you can try sending a suggestion that MOTU should provide
this information to suggestions@MOTU.com
This I did, and received no reply at all - not even an acknowledgement that
the email was received. I then sent something to firstname.lastname@example.org informing
them of all the earlier correspondance. I received the following terse
The Traveler is supported with Windows and Mac OS drivers.
MOTU has no current plans to develop products for Linux.
I then explained that I didn't want them to develop for Linux and only
wanted the protocol documentation to allow myself to do the development.
Not unsurprisingly, in response to this I received the following two line
I'm sorry but the answer is no. The APIs and internal control
information are proprietary and not available to outside developers.
Game over, and hense the protocol analysis approach.
I would be interested in discussing the possibility of a fresh approach.
Contact me off-list if you're interested or want further details of the
exchanges mentioned above.