The first step is to determine what underlying protocol is used by the
> I posted on ffado.org a while ago about helping to get some support for the
> ProjectMix I/O.
> I have one of these, and I was just wondering what would be necessary to
> actually get support going for it?
interface: is it a "standard" generic one like AVC (as used by BeBoB), DICE,
etc, or is it a completely proprietary one (like MOTUs use)? This will
determine how much work would be required to get it going.
If the interface is based on an established protocol then at least some of
the work is already done. What would be required in this case is to work
out the details of any vendor-specific extensions used and add the necessary
code to FFADO to make use of these.
On the other hand, if a completely proprietary protocol is used then one
will need to deduce to details of the protocol from scratch. This is
obviously a much harder proposition.
Based on a comment on the forum, it is suspected - but not yet confirmed
AFAIK - that the ProjectMix uses the same firewire platform as the M-Audio
1814. There's a smattering of comments around the net which suggest it
might leverage AVC but I'm not certain about that.
The feasibility of this approach is critically dependent on whether this
> I'm happy enough to buy a Lynx PCI card and monitor the firewire data, then
> send it to you guys, or if anyone's closer who could work on the interface
> themselves. I live in Northern Ireland.
device uses AVC commands (or one of the other generic protocols we support).
If so, then this *might* work - but only if the vendor extensions employed
don't deviate too far from the standard specification. However, if there is
a need to discover the entire protocol then the person writing the code
really needs physical access to a sample device to allow this to happen
efficiently. Debugging and cross-checking protocol details without the
actual interface is very inefficient - in any given 2 hour session one might
have to run dozens of tests, the nature of which are determined by the
outcome of earlier tests. It is just not feasible to do rely on someone
else to do this testing: it could take 20 days to work through one night's
worth of tests.
To further illustrate the point, FFADO's MOTU driver was developed from
first principles with no assistance from MOTU over the course of 12 months
by myself using a Traveler. I had the interface and would often run many
tests across a night trying to identify specific protocol details. Without
being able to run tests myself the process would have taken many years.
Once we had the basic protocol worked out, it was possible to add support
for other devices in the family based on a simpler series of tests I could
ask people to do. The devices were similar enough in this situation that
these tests plus some educated guesswork was sufficient to get things going.
As an aside, we don't recommend the purchase of MOTU interfaces for use
with FFADO because MOTU have been hostile to our efforts since day one.
So in summary, we need to know whether the 1814 uses a protocol that's
similar to something we already support. Acquiring some async packet dumps
via a PCILynx will probably tell you this, but there may be other ways
(sometimes the labels on the chips inside the interface can give some
clues). This will give some indication as to how hard it might be to
support the 1814. In any case, it will be *much* easier for someone to code
the support if they actually have an 1814. Otherwise it could become an
exercise in frustration.