Re: [LAD] FFADO Contact Needed

alex tinsley wrote:
> 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@email-addr-hidden. You
>> can also contact raymond.tantzen@email-addr-hidden who is the 1394
>> Product Manager.
>> We look forward to hearing from you.
>> Alex Tinsley
>> ETS Compatibility Test Manager
>> 626-610-2464
>> alex.tinsley@email-addr-hidden
>>
>> --
>> 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@email-addr-hidden>
> Date:
> Wed, 06 May 2009 14:40:34 +0200
> To:
> alex.tinsley@email-addr-hidden
> Message-ID:
> <4A018542.7050902@email-addr-hidden>
> Disposition-Notification-To:
> Pieter Palmers <pieter.palmers@email-addr-hidden>
> User-Agent:
> Thunderbird 2.0.0.17 (X11/20080925)
> MIME-Version:
> 1.0
> References:
> <20090505194413.2660CD470F@email-addr-hidden>
> In-Reply-To:
> <20090505194413.2660CD470F@email-addr-hidden>
> 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@email-addr-hidden 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)
>>

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Tue Aug 18 00:15:03 2009