[alsa-devel] Controlling the Tascam FW-1884

[Scott Bahling]

On Sat, 2018-09-08 at 11:53 +0900, Takashi Sakamoto wrote:
> Hi Scott,
> (C.Ced to alsa-devel, ffado-devel)
> 
<snip>

> 
> 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.

Thanks for the information! I read the RFC and your initial code. Why
did you remove the virtual MIDI port code that was part of the RFC code
(I don't see it upstream)? Did it not work? What I have discovered is
that in "computer control" mode the unit sends MIDI messages via the
virtual midi port (control port). The Tascam Native protocol as well as
the other emulations like Mackie are routed via that virtual midi port
and never touch the physical midi ports.

So the secret might be enabling the virtual midi ports - but it's still
not clear to me if those ports are created/mapped within the FW-1884,
or need to be created on the host OS based on the isochronous packet
data. The latter would be more work.

> 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.

I tested this using a supported OS to program the FW-1884 controls to
midi. It works, and the settings are nonvolatile. With this, all
controls can be assigned, but it's one way control from the FW-1884
outward. There appears to be no way to control the motorized faders or
panel indicators from the application towards the FW-1884 in this mode.

<snip>

> 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.

Right. That's what I meant by reverse engineering - analyzing the
traffic and device behavior to understand the protocols.

> 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]

Yep. Read about all that already ;) It sounds like I could take your
RFC code, build a custom kernel, and start analyzing the status and
control messages to get a better understanding of what is happening at
that layer.

> 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.

Understood, but hacking is part of the fun, and this is looking like a
really nice piece of equipment (better than modern control surfaces I
have looked at in my price range). Legacy buses don't scare me. I'm
still running my main audio capture card on legacy PCI bus.

Thanks for the ground work you have already done!

Regards,

Scott

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20180908/f356302b/attachment-0001.sig>