Re: Controlling the Tascam FW-1884

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Scott,
(C.Ced to alsa-devel, ffado-devel)

On Sep 7 2018 23:01, Scott Bahling wrote:
I recently got my hands on a FW-1884 and would like to get it working in
Linux. I'm mostly interested in using the control interface which should
support several midi control interface protocols like Mackie Control or
Mackie HUI. From the user manual it appears that the host computer needs to
set the registers on the FW-1884 to switch modes (they reference Windows
applications).

I see that you have recently been working on user space support asynchronous
commands to such devices. The hinawa_utils code has some beginnings of
support for setting options on the Tascam devices and I have just started
playing with that.

Thanks for your suggestion.

At present, the most of features on control surface of FW-1884 are not
available, especially for fader, knob and start/stop buttons.

In data transmission between system and devices on IEEE 1394 bus,
both of asynchronous transactions and isochronous packet streams are
available. In a case of TASCAM FireWire series, messages via MIDI
physical interface is bypassed to asynchronous transaction, while
messages generated on control surface are bypassed to isochronous
packets, multiplexed with PCM frames.

When enabling multiplexing messages to isochronous packet,
demultiplexer should be implemented to ALSA firewire-tascam driver,
but not yet. You can see my initial RFC in alsa-devel[1]. This patch
enables userspace applications to perform the demultiplexing, however
this idea easily brings cache-coherency problems due to page mapping
between kernel/userspace and impossible to be applied. We need to
investigate another idea to achieve the demultiplexing in kernel land.

As another option, according to page 26 in 'TASCAM FW-1884 Owner's
Manual', when programming Keys to port 1-4, system could receive MIDI
messages from control surface of FW-1884. However, I've not investigated
it.

How are you determining the registers and flags? Do you have documentation,
or are you reverse engineering? Do you know the registers and flags for
setting the control protocol?

If you have any hints on how figure out the proper registers and flags I'm
happy to contribute to the work you have started and help support more
functions of the FW-1884.

User manuals are documents to which we can refer. The most vendors
licenses their drivers/software with EULA and in most cases it can't
allow users to binary-based reverse engineering.

All of my work are done with external protocol analyzer unit on
IEEE 1394 bus. When working to implement drivers, I
read/classified/parsed content of many packets sniffed by the analyzer.
An initial idea of libhinawa/hinawa-utils is to assist this my work.

I heard FFADO developers uses some ways for this type of work:
 - Usage of host controller of TI PCILynx and driver module (nosy.ko)
 - Windows application; bushound[2]

However, this type of work takes you long time, so I don't necessarily
recommend you. It's 2018 and I think you can find alternative control
surfaces on USB. If you take long time to make devices available on
GNU/Linux, it's better to select devices on 'live' buses instead of
'legacy' buses such as IEEE 1394 bus, IMO. In a case of USB, wireshark
with usbcap is the easiest way for us to sniff packets on Windows.

[1] http://mailman.alsa-project.org/pipermail/alsa-devel/2015-July/094817.html
[2] http://perisoft.net/bushound/

Regards

Takashi Sakamoto
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel



[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux