Mobile I/O 2882

Support Status: 
Planned
Manufacturer: 
Metric Halo

Comments

this is with the Metric Halo 2882 connected.
they plan to update all their boxes with USB, possibly this year. planned to be field upgradeable.

in the meantime, this output for MH 2882 2d Expanded +DSP

any suggestions on how to proceed with any userland checking?

root@avlinux:/# ffado-test ListDevices
-----------------------------------------------
FFADO test and diagnostic utility
Part of the FFADO project -- www.ffado.org
Version: 2.1.9999-2468
(C) 2008, Daniel Wagner, Pieter Palmers
This program comes with ABSOLUTELY NO WARRANTY.
-----------------------------------------------

=== 1394 PORT 0 ===
Node id GUID VendorId ModelId Vendor - Model
0 0x0007590000000dc5 0x00000759 0x00000000 Boris Manufacturing Corporation -
1 0x001451fffebbe92e 0x00001451 0x00000000 Linux Firewire -
no message buffer overruns

root@avlinux:/# ffado-test Discover
-----------------------------------------------
FFADO test and diagnostic utility
Part of the FFADO project -- www.ffado.org
Version: 2.1.9999-2468
(C) 2008, Daniel Wagner, Pieter Palmers
This program comes with ABSOLUTELY NO WARRANTY.
-----------------------------------------------

1402702866841098: Debug (ieee1394service.cpp)[ 363] initialize: The raw1394_read_cycle_timer_and_clock call and/or the CLOCK_MONOTONIC
1402702866841132: Debug (ieee1394service.cpp)[ 364] initialize: clock source is not available.
1402702866841143: Debug (ieee1394service.cpp)[ 365] initialize: Fallback to raw1394_read_cycle_timer.
1402702866841149: Debug (ieee1394service.cpp)[ 366] initialize: FFADO may be susceptible to NTP-induced clock discontinuities.
1402702866841158: Debug (ieee1394service.cpp)[ 367] initialize: If this is an issue, upgrade libraw1394 to version 2.1.0 or later and/or
1402702866841164: Debug (ieee1394service.cpp)[ 368] initialize: kernel 2.6.36 or later.
1402702866843114: Debug (devicemanager.cpp)[ 354] discover: Starting discovery...
1402702867321816: Error (ieee1394service.cpp)[ 797] doFcpTransaction: FCP transaction didn't succeed in 2 tries
1402702867321912: Warning (ieee1394service.cpp)[ 772] transactionBlock: FCP transaction failed
1402702867321963: Error (bebob_avdevice.cpp)[ 99] probe: Number of channels command failed
1402702867733836: Error (ieee1394service.cpp)[ 797] doFcpTransaction: FCP transaction didn't succeed in 2 tries
1402702867733919: Warning (ieee1394service.cpp)[ 772] transactionBlock: FCP transaction failed
1402702868145827: Error (ieee1394service.cpp)[ 797] doFcpTransaction: FCP transaction didn't succeed in 2 tries
1402702868145906: Warning (ieee1394service.cpp)[ 772] transactionBlock: FCP transaction failed
1402702868145984: Error (avc_avdevice.cpp)[ 89] probe: Subunit info command failed
1402702868146065: Debug (devicemanager.cpp)[ 661] discover: Discovery finished...
1402702868146131: Debug (devicemanager.cpp)[1258] showDeviceInfo: ===== Device Manager =====
1402702868146176: Debug (Element.cpp)[ 121] show: Element DeviceManager
1402702868146217: Debug (devicemanager.cpp)[1266] showDeviceInfo: --- IEEE1394 Service 0 ---
Iso handler info:
Dumping IsoHandlerManager Stream handler information...
State: 2
no message buffer overruns

-flyshooter
AVLinux 6.0.3 on iMac4,1
TC SK-48 (works)
Metric Halo 2882 (not working yet)
Eventide H8000FW (not working yet)

I read about MH's field "upgrade" plans myself a few weeks ago. It's an interesting development from the hardware engineering side of things if nothing else.

While FFADO has a placeholder for a metric halo driver, there has been no progress on coding such a driver. As a result, all Metric Halo firewire devices remain unsupported by FFADO. Several years ago contact was made with Metric Halo and at least at that time it was indicated that they would be willing to provide some assistance to the FFADO project. Unfortunately FFADO has lacked the developer resources to pursue this any further. Note that FFADO has only a small number of core developers and none of us are paid to work on FFADO - all FFADO work is done in our spare time.

To directly answer your question, based on the current set of developers and their existing commitments both in and outside of FFADO, do do not see any work being done to support firewire-equipped Metric Halo interfaces in the near future. This is in many ways disappointing - it would be fantastic to have these interfaces supported under Linux. However, our resources regrettably do not currently allow us to contemplate commencing work on these interfaces. Obviously if someone came along wanting to work on a Metric Halo driver we would welcome them!

As for USB audio interfaces, the ALSA project already has infrastructure in place to support such devices. However, from what I've read about Metric Halo's USB plans it seems that they implement their own protocol over USB (much like they did when using firewire). This means that even when they move to USB the "class compliant" USB audio driver is unlikely to work (and certainly won't provide access to all the device's capabilities). If USB Metric Halo devices are to be supported, I expect there will be a need to write a dedicated USB ALSA driver for them. While some of the ALSA developers are paid to work on ALSA, they are already committed to supporting other devices. As I read the situation, a Metric Halo USB ALSA driver is only likely to come about if someone steps forward to write one. The consolation is that if Metric Halo is still open to cooperating with Linux driver developers (as they seem to have been earlier, as noted above) then at least some protocol information might be forthcoming.

first, thanks for explaining the situation with ffado development. i do appreciate the efforts and the progress has at least enabled I/O for one device i have, the TC SK-48.

regarding MH USB -

MH posted on the MobileIO mail list after Musikmesse this year, which was copied over to gearslutz
http://www.gearslutz.com/board/high-end/916058-new-metric-halo-developme...

bullet #7
7) Since the computer transport is USB Class Audio, the units can be used with any host that supports USB Class Audio -- this includes Mac OS X, iOS, Windows and Linux.

this is also discussed briefly in part 2 of the videos that are linked in that message.

It reads & sounds like we'll have, at the least, I/O for linux with the upgrade. No specific mention about DSP or a mixer in this context. But DSP and a mixer with hardware control would make upgrading pretty compelling for me. of course, the reality or likelihood that none of the MH interfaces are going to work using ffado suggests pursuing the upgrade if i ever want to use MH with linux.

thanks for all the efforts, i'm glad you folks picked up the ball for firewire audio with this project.

cheers!

Thanks for the followup. In many ways it's not surprising they've gone with the USB class compliant mode since it opens up operation with some tablets too. I'm a bit hazy about the details but I think there is some limitation with the audio-class operation which reduces the maximum number of IOs available. However, USB isn't really my field so I could be wrong about this. While I know that USB class compliant operation with some devices does not support all possible IOs, this may be a limit imposed by the device rather than the class-compliant mode itself.

It's nice to see that Linux got a mention in the article you referenced.

As far as I know, the USB audio class mode does not (generally speaking) support mixer or DSP control - that is, it provides audio streaming only. How this translates to Linux control of these interfaces remains to be seen, but at least in the first instance I expect DSP control to be unavailable. I suspect that such control may be done with their own protocol.

As is usually the case with things like this, the situation will probably only become clear when people start testing the hardware. :-)

Yes, we'll see how this goes. I am curious how much control & device access they'll provide for linux. I sort of expect something more than streaming, because, at least with the 2882, switching phantom power on/off for any input can only be done through a software interface. not having adequate control over this but just doing the streaming could leave them somewhat exposed. i can't see them saying you can "use this with [linux|iOS|windows|OSX] but you need to run brand X OS to flip the bits for [phantom power|digital audio|etc]. that said, i have no idea how many in pro audio want to run linux. however, ardour and mixbus (harrison) are getting mentions on the MobileIO list.

Thanks for your insights. I'll direct further questions and comments to Metric Halo as I can see this thread has gone out of scope for FFADO.