Ticket #356 (new discussion)

Opened 9 years ago

Last modified 7 years ago

MOTU V4HD - Device info & IDs

Reported by: fishb8 Assigned to: jwoithe
Priority: waiting for device info Milestone: Indeterminant (need device info)
Component: devices/motu Version: FFADO SVN (trunk)
Keywords: Cc:
The device the bug applies to:


I have access to one of these units. The stream comming from it should contain 1 video stream, up to 16 audio streams plus whatever command/controll/ancillary stuff would be in there. If I can provide any info, or do any tests to possibly support this device let me know.

On my system a fw1 device with sub-devices fw1.0 fw1.1 fw1.2 and fw1.3 are created. Kernel 3.4.3, new FW stack.

Here's the info for adding it's IDs to be recognized by ffado:


vendor: 0x0001f2 uevent:



0x0001f2:0x000021 0x0001f2:0x000022 0x0001f2:0x000023 0x0001f2:0x000024


model: 0x102800 rom_index: 13 specifier_id: 0x0001f2 version: 0x000021


model: 0x102800 rom_index: 17 specifier_id: 0x0001f2 version: 0x000022


model: 0x102800 rom_index: 21 specifier_id: 0x0001f2 version: 0x000023


model: 0x102800 rom_index: 25 specifier_id: 0x0001f2 version: 0x000024

Change History

06/20/12 13:47:55 changed by adi

Do you know anything about the underlying streaming format?

Did you try to create a configuration entry with the appropriate driver setting?

Please refer to http://subversion.ffado.org/wiki/AddingDeviceIds for more information.

06/20/12 18:07:06 changed by jwoithe

  • version changed from FFADO 2.0.1 to FFADO SVN (trunk).
  • type changed from bug to discussion.

Hi fishb8 - thanks for the report and the information.

I'm assuming the "version" field you reported is the "unit version" from the device.

For the benefit of others following along, MOTU don't use the modelid field to identify the model - instead modelid seems to be vaguely related to the firmware version. In terms of the configuration file, we therefore have a single entry which covers everything manufactured by MOTU, and leave the device identification to the probing code. This in turn uses the "unit version" field of the configROM to differentiate different devices.

The practical upshot is that there's no need to add a configuration entry for this device. Instead one needs to add appropriate entries to the MOTU driver device definitions.

The presence of sub-devices is a new thing for MOTU - none of their other interfaces do this. I'm guessing that the different units correspond to different aspects of the device operation. One is probably for video, one for audio, and the other two ... I have no idea at the moment. I don't know how all this might be fitted into FFADO just yet. Up to now we've only ever had to deal with a "one unit per device" arrangement. Even so, I've added the relevant information to ffado (see r2168); it will be interested to see what's reported if you run something like "jackd -d firewire -v 6" with the V4HD unit plugged in and turned on. You'll need to obtain and install the current subversion (svn) trunk to pick up this change - let me know if you need help doing so.

FFADO deals only with audio at present, so in so far as getting this device working with FFADO it would be limited to the audio side of things. To get the video working, a separate driver would be needed, probably under the v4l2 (video for Linux 2) kernel subsystem. This of course assumes that the audio and video components of the device can be dealt with by separate driver components - which seems likely if the audio and video streams really are separate as the initial report seems to imply. If the audio is instead embedded in the same stream as video the v4l2 driver would need some way to make the audio stream available (there may well be ways of doing this already - I'm not very familiar with the v4l2 subsystem).

As per comment 1, to make any progress on supporting this device we would need to determine the streaming format - that is, the format of the data stream sent to and from the device. We would also have to work out how the device is controlled, and whether the control protocol bears any resemblance to that of existing audio-only MOTU interfaces. At a fundamental level, we would first need to work out which of the sub-devices corresponds to the audio engine.

You may have picked up from other areas of the FFADO site that MOTU have been traditionally hostile to supporting any effort to use their devices under Linux. The MOTU driver we have is the result of an extensive protocol analysis effort - we have received no help from MOTU at all. It's possible that the audio side of this device is based heavily on their other audio interfaces, in which case it may be possible to guess many of the details. Otherwise, protocol analysis is the only way forward.

To give you an idea of what might be required if protocol analysis is needed, you might like to take a look at a talk I gave at Linux.conf.au a few years ago: http://linuxconfau.blip.tv/file/4692954. The slides can be downloaded from http://www.atrad.com.au/~jwoithe/lca2011/lca2011_firewire_analysis_talk.pdf. I'm more than happy to talk about this in more detail - to avoid cluttering the ticket perhaps pick up my email address from one of my ffado-devel mailing list posts.

I'll change the ticket type to "discussion" since at this point that's what it is. Once we get a better feel for where this might head this can be revised. Similarly, while the original version tag was 2.0.1 it really applies to the current development trunk so I'm updating that too. In any case, any changes to support new devices will go into "trunk"; the 2.0.x branch is no longer the focus of fresh development.

06/23/12 10:26:16 changed by fishb8

Thanks for the response, I will hopefully have time to poke around and see if I can find anything useful for you later next week.

Until now I've been plugging the SDI out from this unit into a decklink card and grabbing the audio/video data from it that way. (People elsewhere are working to integrate the decklink API into ffmpeg to be able to access it as a input device) I hadn't tried firewire connection since I was already aware MOTU wasn't willing to release info on their devices, but I became curious when I read that you have been able to successfully reverse engineer some of their audio units.

Also, if it's of any interest, I have access to a Ultralite-mk3 Hybrid. (If I could find the dang power adapter for it)

06/25/12 05:25:48 changed by jwoithe

I'll await the outcome of your poking. :-)

On the subject of the Ultralite Mk3 hybrid, I seem to recall that we had some success getting the audio portion of this device working at some point (I really need to go through my notes to determine which Mark3 devices have been noted as working). If you happen to locate the power adapter, testing the hybrid in firewire mode would at least tell us something about the state of the current code base.

02/27/14 15:14:41 changed by jwoithe

  • priority changed from minor to waiting for device info.
  • milestone set to Indeterminant (need device info).

There have been no further developments reported for over 18 months. Until more information about the device is obtained we can't determine whether it is possible to support this device within FFADO or work towards such support. Consequently I'm marking this ticket's priority as "waiting for device info" and the milestone as "indeterminant (need device info)" until additional information comes to light.