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