Re: [FFADO-devel] MOTU 896HD

[Patrick N. <pat...@gm...>]

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

On 2/17/08, Jonathan Woithe <jw...@ph...> 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 sa...@mo... 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