Hi,
I have tried the contact form on the FFADO website and through the email
address provided in the contact pages at the
SourceForge.net project
page to no avail. I'm not sure where else to ask except here. Are any of
the FFADO developers on this email group that can provide a contact
email that will garner a response?
Dear,
I have responded to two of your previous mails, it surprises me that you
have not received them. The content of these answers are copied below.
Should you require more information from us, please don't hesitate to
contact me directly.
Regards,
Pieter Palmers
FFADO Developer
Dear Alex,
I can only briefly answer your inquiry as I am leaving for a business trip to California
in a few hours.
The bottom line is twofold:
* we can't seriously support devices that we don't have access to, so we require
test units.
* the exact information that we need is very device dependent. I think I've given my
estimation of this in a previous email to you (attached), and that's about as detailed
as I can be as I don't know the devices.
There are numerous ways in which this can proceed, I don't really have the time right
now to elaborate. We can discuss this mid-august when I'm back.
Regards,
Pieter Palmers
Alex Tinsley wrote:
Message body follows:
Hi,
I believe you've had previous contact with Calvin Banks who
is our CS manager here in Irwindale, CA.
The product team here at M-Audio wishes to know what is
required by the FFADO project so that the 1394 Audio
interfaces can be supported by this project on Linux.
What is needed by your team that does not divulge the
internal workings of our driver which is not intended to be
released as open source. Do you need signal paths? for
connectivity to map to your control panel, etc?
We'd like to find a way that this is workable if that is a
viable solution if at all possible.
You can contact me directly at alex.tinsley(a)avid.com. You
can also contact raymond.tantzen(a)avid.com who is the 1394
Product Manager.
We look forward to hearing from you.
Alex Tinsley
ETS Compatibility Test Manager
626-610-2464
alex.tinsley(a)avid.com
--
This message has been sent to you, a registered
SourceForge.net user,
by another site user, through the
SourceForge.net site. This message
has been delivered to your
SourceForge.net mail alias. You may reply
to this message using the "Reply" feature of your email client, or
using the messaging facility of
SourceForge.net at:
https://sourceforge.net/sendmessage.php?touser=2567490
Subject:
Re: [I'm a vendor and want my device supported] What do you need for M-Audio 1394
Devices to work?
From:
Pieter Palmers <pieter.palmers(a)ffado.org>
Date:
Wed, 06 May 2009 14:40:34 +0200
To:
alex.tinsley(a)avid.com
Message-ID:
<4A018542.7050902(a)ffado.org>
Disposition-Notification-To:
Pieter Palmers <pieter.palmers(a)ffado.org>
User-Agent:
Thunderbird 2.0.0.17 (X11/20080925)
MIME-Version:
1.0
References:
<20090505194413.2660CD470F(a)vermouth.dreamhost.com>
In-Reply-To:
<20090505194413.2660CD470F(a)vermouth.dreamhost.com>
Content-Type:
text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding:
7bit
Dear Alex,
Thank you for your interest in the Linux community and the FFADO project in particular.
In general we require two things to support a device:
1) permanent access to a test device
2) information on the vendor-specific changes to the generic platform used (assuming the
device is based upon a BridgeCo/BeBoB, TCAT/DICE or ECHO Audio platform).
I assume that the device(s) you are inquiring for are based upon either the BridgeCo or
the DICE platform. In such case all streaming is supported by our generic AMDTP/IEC61883
streaming engine.
For device discovery and stream configuration we implement two 1394TA AV/C based
mechanisms (one using bridgeco specific commands, and the other mimicking the Apple driver
discovery) and the DICE driver specification 1.0.7.0.
For internal mixer control we have implemented the AV/C Audio Subunit specification and
the TCAT DICE EAP mechanism. This means that if you are using these protocols, the
additional information we require is limited.
If you use another protocol for any part of this, the only way that we can support it is
if we have access to its specification. Note that this access can take multiple forms: a
more or less formal specification, a developer to talk to, source code, ...
So to answer your question:
I can't really say what we need, I can only indicate what we already have. For most
platforms we have implemented the major building blocks to be able to support devices with
minimal additional information. But how much information we exactly need depends on the
device implementation.
Let me narrow down what I know/suspect about your FW device range, and what it would take
to support it:
* NRV10
I suspect it uses a BridgeCo DM1100 + BeBoB firmware.
Has already been reported to work fine with BeBoB platform support. Doesn't seem to
have an internal mixer. The only reason why it has no 'supported' label is because
we don't have access to one. Access to a device would make this device a supported
one.
* FW Solo
I suspect it uses a BridgeCo DM1100 + BeBoB firmware.
Has been reported to work with BeBoB platform support, except for the fact that people
have to configure the mixer/routing in another OS first. The AV/C model seems to
illustrate how to configure the devices mixer/routing, and I would probably be able to
implement support for it with this info alone. Access to a device would make this device a
supported one.
* ProFire Lightbridge
I suspect it uses a BridgeCo DM1500 + BeBoB firmware.
Has been reported to work with BeBoB platform support, but people report random issues
with it. It seems to be a straightforward BeBoB design without complicated mixer. Access
to a device would make this device a supported one.
* ProjectMix I/O
I don't really know about this interface. I think it uses a DM1100 with customized
bebob firmware.
If it uses the stock BeBoB style discovery it will work out of the box for audio
streaming. For the control surface functionality I can imagine several paths. The most
likely one being that the control surface gets a MIDI channel as if it were connected
through MIDI. This would mean that on the FFADO side there is not much that we have to do
to support it. As it supports Mackie HUI and standard MIDI this would mean it is instantly
useful to users. Another option would be that asynchronous communication is used to
communicate the messages, which would require a bit more information.
As for support for this device, it depends on what is under the hood. If it works with
the standard BeBoB discovery and control mechanism, it's probably very easy to support
this device. It would be a nice addition to our project as there is not really a similar
product available for Linux users.
* ProFire 2626 and ProFire 610
These are obviously based upon the DICE platform, as you advertise JetPLL.
I've been told that there were some extensive customizations to the stock firmware
that have been done to the standard TCAT firmware to implement AV/C support. I don't
have any details on these customizations, but I do have good contacts with TCAT and I know
they are willing to work with me on this provided there is a green light from M-Audio.
I suspect that the ProFire 2626 is based upon the DICE-II and an external DSP mixer. This
means that the audio streaming will work out of the box, but that we require some
information on how to control the DSP mixer. The ProFire610 is most likely based upon the
DICE-Mini, using the onboard mixer. If EAP-enabled firmware is used we have all
information required to support the mixer and the metering.
With respect to older devices:
* Firewire 1814 and Firewire 410:
As far as I know these are based upon an early, highly customized version of the BeBoB
platform. To support them we need the information on how to discover and configure the
device, and how to configure the mixer/routing (if possible). Although we get quite some
inquiries regarding these devices, I'd rather not spend the effort of implementing a
completely new discovery procedure for obsolete devices. On the other hand, if you can
provide the information and allow me to pass it on to people having one of these devices
that want to do implement the code themselves, they'll work one day or the other. I
could however be wrong about this and we might have everything we need to implement
support for these devices quite easily.
* FireWire Audiophile
I suspect it uses a BridgeCo DM1100 + BeBoB firmware. Very similar to the FW Solo.
Has been reported to work with BeBoB platform support, except for the fact that people
have to initialize the device in another OS first. The device requires upload of the
firmware before it works. This means that we require the .bcd firmware to upload it from
Linux (we have a bridgeco firmware upload tool). It should not be very difficult to
support this device.
* Ozonic
I suspect it uses a BridgeCo DM1100 + BeBoB firmware.
Has been reported to work with BeBoB platform support, except for the mixer support.
Seems to be a similar case as the Solo/Audiophile. As far as I know the control data is
transported through MIDI meaning it is automatically supported. It should not be very
difficult to support this device.
So to summarize my assessment (provided you supply us with the appropriate test units):
* The following devices will not require any effort from your side to be upgraded to a
'supported' status:
NRV10, FW Solo, ProFire LightBridge, FW AudioPhile, Ozonic
* With green-light from M-Audio, supported by TCAT:
ProFire 2626, ProFire 610
* Depending on the implementation, it might be easy or hard:
ProjectMix
* Most likely not very easy:
FW1814, FW410
I hope this answers your question, and I hope that we can get things started to embrace
M-Audio as a Linux-friendly vendor and add the M-Audio devices to the FFADO supported
devices list.
Greetings,
Pieter Palmers
FFADO Developer
alex.tinsley(a)avid.com wrote:
> Alex Tinsley sent a message using the contact form at
>
http://www.ffado.org/?q=contact.
>
> Hi,
> I work in the test department and work closely with product management and
> engineering. We are curious about what you need in order to make the
> M-Audio devices work with your project? From what I can gather you just
> need access to the I/O routing so your driver can connect to our firmware
> is that correct? Or is there more to it than that? At this point we are
> fielding you for information before making any commitment. Your feedback
> would be greatly appreciated.
> Thanks,
>
> Alex Tinsley
> Test Mgr - Avid Audio
> 5795 Martin Road
> Irwindale, CA 91706
> 626-610-2464 (p)
>