Thank you all for the very helpful info thus far.  (More below.)

On 2/17/08, Jonathan Woithe <jwoithe@physics.adelaide.edu.au> wrote:
Hi Patrick

>
> 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.
 
Okay.  I also found the nosy software you referred to earlier.  Here's a link for anyone else interested:
 
http://bitplanet.net/nosy/
 


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

http://www.ioi.com.tw/products/proddetail.aspx?ProdID=1060006

The model number is IOI-1394TT.
 
I called IOI, and they said they aren't selling this card anymore (even though it's still listed on their web site).  My google/ebay searching hasn't turned up any other active sources either.


> 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.
 
I read the (rather short) datasheet for the TI TSB12LV21B (PCILynx-2) chip, and I couldn't see any mention of this capability.  Granted, it may be there and my limited knowledge of 1394 may be blinding me of it.  Does anyone else have another reference that explains how this works (at the chip level)?  I'd like this mainly for my own understanding, but also so I know what to look for on the off chance that another chip exists.


> 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 sales@motu.com informing
them of all the earlier correspondance.  I received the following terse
reply:

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
reply:

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.
 
Thanks again for all this info.  I'm willing to contact them and attempt to speak to a product manager or someone at that level.  I just didn't want to waste time (mine and theirs) if someone had recently contacted them.  I understand every company views their IP differently.  But I think it's worth another shot given it's been over 2 years.  And perhaps a product manager never got the chance to consider this option if the sales team "handled" it themselves.  Still, if the answer is no, I won't be shocked.
 
Jonathan, if you like, we can speak further off-list about a plan.
 
Regards,
Patrick