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

Hi Takashi,

On Mon, 2018-09-10 at 16:59 +0900, Takashi Sakamoto wrote:

<snip>

As long as I know, the image consists of below information:

• pos 0-15: control messages from physical control surface
• pos 16-23: analog input level
• pos 24-31: digital ADAT input level
• pos 32-33: digital S/PDIF input level
• pos 34-35: (not cleared yet)
• pos 36-43: analog output level
• pos 44-64: (not cleared yet)

When parsing the image, a parser should generate several types of events. I prefer to implementing this complicated work in user space instead of kernel space. Expecially for pos 16-23/24-31/32-33/36-43, the parser should always generate events to notify each of the levels.

What we should do is to parsing the image and generate events with enough consideration of task scheduling and eventing dencity. The parser could be implemented as an application of ALSA sequencer.

Thanks for the details. I can work on deciphering the raw control messages. My current idea is to set up a netlink socket and stream the control data to user space just for analysis. I will look into ALSA sequencer to see if I can understand how that could be used.

I noticed that we are able to control the LEDs from the host via the asynchronous link. Do you you think the faders are also controlled that way or would that also go via isochronous packets to the FW-1884?

Regards,

Scott

On Mon, 2018-09-17 at 23:36 +0900, Takashi Sakamoto wrote:

Hi,

I prepare branches in two remote repositories:

https://github.com/takaswie/snd-firewire-improve/tree/topic/tascam-userspace

(a384019c0f78)

• https://github.com/takaswie/libhinawa/tree/topic/tascam-userspace

(a5994ec2165f)

Installing the patched driver, you can read the status and control message in userspace by mmap(2).

Patched libhinawa produces HinawaSndTscm GObject class. This class is also available with gobject introspection. For example with PyGobject:

#/usr/bin/env python3
from time import sleep
import gi
gi.require_version('Hinawa', '2.0')
from gi.repository import Hinawa
unit = Hinawa.SndTscm()
# I assume card number 1 is assigned. Take care of file permission.
unit.open('/dev/snd/hwC1D0')
unit.listen()
while (True):
   for i, frame in enumerate(unit.get_status()):
     print('{0:02d}: {1:08x}'.format(i, frame))
   sleep(0.1)

This code print the message to stdout, but not start packet streaming. You need to start it by ALSA PCM/rawMIDI interfaces, like: $ aplay -Dplughw:1,0 /dev/urandom

I notice that the branches include patches I introduced[1], with some minor optimizations to Linux kernel v4.17 or later. The patches are written just to satisfy investigation work and really ad-hoc ones.

Thanks! I finally had some time to try it out.

My test system is running a 4.12 kernel from openSUSE Leap 15.0. I backported the patches but had to remove your GFP_KERNEL patch for it to work on my kernel. With the GFP_KERNEL patch, user space was not seeing updates to the data stream. With it removed, I had a constant update.

The kernel was unstable and the system hard locked frequently with the patches enabled (with and without the GFP_KERNEL patch). But I was able to map out all the controller functions to the bits in the first 16 quadlets. I will write up my findings and send them later.

...

I noticed that we are able to control the LEDs from the host via the asynchronous link. Do you you think the faders are also controlled that way or would that also go via isochronous packets to the FW-1884?

The rx isochronous packets from system to the unit include no data to control the unit[2]. If the faders are movable from system software, it should be achieved by asynchronous transactions, like blighting LEDs.

I guess without an analyzer that will be difficult to track down.

-Scott

Hi Takashi,

On Fri, 2018-09-28 at 12:44 +0900, Takashi Sakamoto wrote:

Hi Scott,

On Sep 24 2018 18:32, Scott Bahling wrote:

...

The kernel was unstable and the system hard locked frequently with the patches enabled (with and without the GFP_KERNEL patch). But I was able to map out all the controller functions to the bits in the first 16 quadlets. I will write up my findings and send them later.

I'm sorry but I have applied wrong changes to the remote branch for kernel patch. It includes three issues:

1. call vfree() to memory object allocated by kmalloc()
2. bring kernel oops due to double free corruption of 'tscm->status'
3. invalid page mapping of 'tscm->status' to process' VMA

I pushed additional three patches. Would you please test with them?

• 1777454 firewire-tascam: fix kernel oops to call vfree() to memory

object allocated by kmalloc

• e11d941 firewire-tascam: fix double free corruption
• 5e7fef9 firewire-tascam: use one page for mmap(2)ed data

Espeially, when allocating in kernel logical space instead of kernel virtual space, I should have kept one page for 'tscm->status' because kmalloc() allocates memory object unaligned to page boundary by kernel SLAB/SLOB/SLUB allocaters. This is a cause which you cannot see updated data. A page mapped to process' VMA doesn't include region of 'tscm->status' data correctly.

Again, I'm sorry to lost your time due to this kind of my stupid codes...

No worries! It did not waste too much time at all. I assumed it's just quick test code anyway. I was able to get the button press events and control levels mapped to the quadlet bits which was my goal (I'm still documenting my findings).

I will test your new patches this weekend and let you know if it works better.

Are you still thinking to try to make mmap the solution to pass the control data to userspace, or do we need to find another method in the long run?

Regards,

Scott

Hi Takashi,

On Fri, 2018-09-28 at 12:44 +0900, Takashi Sakamoto wrote:

Hi Scott,

On Sep 24 2018 18:32, Scott Bahling wrote:

...

...

The kernel was unstable and the system hard locked frequently with the patches enabled (with and without the GFP_KERNEL patch). But I was able to map out all the controller functions to the bits in the first 16 quadlets. I will write up my findings and send them later.

I'm sorry but I have applied wrong changes to the remote branch for kernel patch. It includes three issues:

1. call vfree() to memory object allocated by kmalloc()
2. bring kernel oops due to double free corruption of 'tscm->status'
3. invalid page mapping of 'tscm->status' to process' VMA

I pushed additional three patches. Would you please test with them?

MMAP works fine and stable with the three additional patches.

-Scott

Hi Scott,

On Oct 4 2018 05:37, Scott Bahling wrote:

On Tue, 2018-10-02 at 12:16 +0900, Takashi Sakamoto wrote:

...

I have an idea to invervene them:

1. For control events, in kernel land, driver module detects

changes of set of bitflags for physical controls, then queue events to tell the change to userspace applications (e.g. poll(2)). The queued events include information about changed bitflags (e.g. a shape of u32 data). Userspace applications execute read(2) then get the bitflags, then parse it and emit userspace event by ports in ALSA sequencer subsystem. The driver and userspace application should pay enough attention to share the queue. The driver can drop the oldest queued events if the queue is full.

2. For level meter, in kernel land, driver module caches the

recent value. Userspace applications execute ioctl(2) with unique command (You can see this kind of commands in 'include/uapi/sound/firwire.h').

However, as long as I note[2], the purpose of some quadlets in the image are not still identified:

"Quadlet 00-15 show control messages. Quadlet 16-23 show analog input level. Quadlet 24-31 shows digital ADAT input level. Quadlet 32-33 shows digital S/PDIF input level. Quadlet 34-35 is unknown.

On my FW-1884 34/35 is analog level of output 1/2. The "Monitor" level pot (as well as the master fader if enabled) control the level so if they are set at 0, then you will not see any signal on the 34/35.

...

Quadlet 36-43 shows analog output level.

36-41 = analog outputs 3-8

...

The other quadlets are unknown."

52: shows the current sample rate setting 010101xx = 44.1k 020102xx = 48k 810181xx = 88.2k 820182xx = 96k

52: Byte 1 shows the current clock source 0x01 = Internal 0x02 = Word Clock 0x03 = Digital In 0x04 = ADAT

54-55 appears to be the level of the internal "Monitor Mix". 57-58 appears to be the level of the stereo mix of the analog inputs

59: Byte 1 indicates what is routed to the Monitor Mix 0x01 = PCM Stream from computer 0x02 = Analog Inputs 0x03 = Both

...

We need further investigation to clear the unknown fields as much as possible to add more codes in ALSA kernel land.

Above is as far as I have gotten with the unknown fields.

On the asynchronous side, I have mapped out the LED codes to the LEDs on the FW-1884 and discovered the registers for controlling the faders.

Thanks for your report. I have additional information from today investigation. In detail, please read the end of this message.

I think it reasonable to take kernel-land driver emits events for quadlet 05-15 to userspace applications, then let SndTscm object in libhinawa. (Extra care is required for the value of monitor-knob). Additionally, SndTscm object produces API to retrieve current value of fader, knob and so on.

Anyway, initial value should be reported to userspace, mmm...

======== 8< --------

00: fader2 fader1 01: fader4 fader3 02: fader6 fader5 03: fader8 fader7 04: solo-knob fader9(=master)

The value of fader is between 0x0000 and 0x03ff (2byte). The value of solo-knob (FW-1884 only) is between 0x0000 and 0x03ff (2byte).

05: op-mode+fader-sense monitor-knob

op-mode is 7 bits in MSB side. - 0x00: computer mode - 0xfe: midi-ctl/mon-mix modes

The value of fader-sense consists of bitflags in which a bit becomes zero during user touches corresponding fader. This is next 9 bits in MSB side. - 0x0100: for fader 9 (=master) - 0x0080: for fader 8 ... - 0x0001: for fader 1

The value of monitor-knob is between 0x0000 and 0x03ff. But the lowest bits becomes frequently without handy operation.

06: bitflags 07: bitflags 08: bitflags 09: bitflags

These bitflags consists two states: - During corresponding button is pressed, bit becomes zero. - some sets of 2 bits represent current value of corresponding knob. The position is largely different depending on FW-1884/FW-1082.

10: unknown unknown 11: unknown unknown 12: unknown unknown 13: unknown unknown 14: unknown unknown

15: dial-value unknown

The value of dial is between 0x0000 and 0xffff, accumulated clockwise. At overflow it resets to 0x0000.

16: analog-in-1 17: analog-in-2 18: analog-in-3 19: analog-in-4 20: analog-in-5 21: analog-in-6 22: analog-in-7 23: analog-in-8 24: adat-in-1 25: adat-in-2 26: adat-in-3 27: adat-in-4 28: adat-in-5 29: adat-in-6 30: adat-in-7 31: adat-in-8 32: s/pdif-in-1 33: s/pdif-in-2 34: analog-out-1 35: analog-out-2 36: analog-out-3 37: analog-out-4 38: analog-out-5 39: analog-out-6 40: analog-out-7 41: analog-out-8 42: adat-out-1 43: adat-out-2 44: adat-out-3 45: adat-out-4 46: adat-out-5 47: adat-out-6 48: adat-out-7 49: adat-out-8

The value of level is between 0x00000000 and 0x7fffff00.

50: (unknown) 51: (unknown)

I expect them for spdif-out-1/2 but actually they're not.

52: clock-status clock-config

As Scott investigated, but configuration of clock source is not necessarily effective in bits of clock-status.

53: (unknown) 54: monitor-mix-1 (enabled at INPUT/BOTH modes) 55: monitor-mix-2 (enabled at INPUT/BOTH modes) 56: (unknown) 57: analog-in-mix-1 58: analog-in-mix-2

59: 0:COMPUTER, 1:INPUTS, 2:BOTH

At monitor mix mode, the above selections are available.

60: (unknown) 61: (unknown) 62: (unknown) 63: (unknown)

======== 8< --------

Thanks

Takashi Sakamoto

Hi Scott,

On Oct 2 2018 12:16, Takashi Sakamoto wrote:

I have an idea to invervene them:

1. For control events, in kernel land, driver module detects

changes of set of bitflags for physical controls, then queue events to tell the change to userspace applications (e.g. poll(2)). The queued events include information about changed bitflags (e.g. a shape of u32 data). Userspace applications execute read(2) then get the bitflags, then parse it and emit userspace event by ports in ALSA sequencer subsystem. The driver and userspace application should pay enough attention to share the queue. The driver can drop the oldest queued events if the queue is full.

2. For level meter, in kernel land, driver module caches the

recent value. Userspace applications execute ioctl(2) with unique command (You can see this kind of commands in 'include/uapi/sound/firwire.h').

I prepare two remote branch as 'topic/tascam-userspace-take2' for kernel driver[1] and libhinawa[2].

The patches for kernel driver adds two features below to firewire-tascam module: - SNDRV_FIREWIRE_IOCTL_TASCAM_STATUS ioctl command - 'struct snd_firewire_event_tascam_ctl' event notification

The patches for libhinawa adds two features below for g-i modules: - hinawa_snd_tscm_get_status() method - 'control' GObject signal

For example[3]:

``` $ cat test.py #!/usr/bin/env python3

from sys import exit from time import sleep

import gi gi.require_version('Hinawa', '2.0') from gi.repository import Hinawa

unit = Hinawa.SndTscm() unit.open('/dev/snd/hwC2D0') unit.listen()

req = Hinawa.FwReq()

def handle_control(self, index, flags): print('{0:02d}: {1:08x}'.format(index, flags)) # data = bytearray(4) # You can check the flags and bright LED with proper values # in the data array. # print(req.write(self, 0xffff00000404, data))

unit.connect('control', handle_control)

while (True): msgs = unit.get_status() for i in range(len(msgs) // 2): left = i right = i + len(msgs) // 2 print('{0:02d}: {1:08x}, {2:02d}: {3:08x}'.format(left, msgs[left], right, msgs[right])) sleep(0.1) ```

When running any scripts with your local build of libhinawa, it's useful to set LD_LIBRARY_PATH/GI_TYPELIB_PATH properly.

``` $ export LD_LIBRARY_PATH="/home/username/git/libhinawa/build/src:${LD_LIBRARY_PATH}" $ export GI_TYPELIB_PATH="/home/username/git/libhinawa/build/src:${GI_TYPELIB_PATH}" $ ./sample.py ... ```

When starting packet streaming and operating control surface, you can see dump with index and bitflags additionally to status dump.

``` ... 06: fffeffff 06: ffffffff 06: feffffff ... ```

As I told, kernel driver emits events corresponding to quadlet 05-15. If there's insufficiency, please inform it to me. If all things look well, I'll submit patches for next merge window but .

[1] https://github.com/takaswie/snd-firewire-improve/tree/topic/tascam-userspace... [2] https://github.com/takaswie/libhinawa/tree/topic/tascam-userspace-take2 [3] https://gist.github.com/takaswie/669fd4254c7b9fd631762fc61ac931f5

Thanks

Takashi Sakamoto

Hi Scott,

On Oct 12 2018 17:12, Scott Bahling wrote:

I have tested the branches and it works well. I was able to create daemon in python to interface the FW-1884 with Ardour via the OSC protocol. That's working reliably.

Good to hear ;)

I had to enable quadlets 00-04 since they contain the fader control values. I masked out the solo control values in the same way as the monitor control values since they continuously fluctuate in the same way.

For FW-1082 these quadlets includes value of movable fader as well, however unlike FW-1884 they have fluctuate quirk. So I think it reasonable for us to program this module to ignore them.

Instead, let us program applications so that they call 'hinawa_snd_tscm_get_status()' periodically to get current value of these faders between touch and untouch event on quadlet 05? This take applications to consume CPU time more efficiently than handling many events.

While testing, noticed that the encoder bits on quadlet 06 do not get updated reliably if the encoder knob is moved quickly. The transitions on those bits happen quickly and some of the bit state changes get lost. I switched to using the absolute encoder values on quadlets 10-15 which works reliably.

Yep. We need to ignore some bits in quadlet 06 and 08 for value of the knobs.

Well, as a result, ALSA firewire-tascam driver handles 'edge-trigge' events except for jog wheel and knobs. For this kind of event, it's useful to notify before/after value when emitting notification. So I'd like to change structure passed to UAPI so that:

struct snd_firewire_tascam_control { unsigned int index; - __u32 flags; + __u32 before; + __u32 after; };

Would I request your opinion? You can see patches here: - https://github.com/takaswie/snd-firewire-improve/tree/topic/tascam-userspace... - https://github.com/takaswie/libhinawa/tree/topic/tascam-userspace-take3

You can receive 'control' event of 'HinawaSndTscm' GObject with these two values:

``` def handle_control(self, index, before, after): print('{0:02d}: {1:08x} -> {2:08x}, {3:08x}'.format(index, before, after, after ^ before)) ```

idx before after XOR 09: ffffffff -> 7fffffff, 80000000 09: 7fffffff -> ffffffff, 80000000 06: ffffffff -> ff7fffff, 00800000 06: ff7fffff -> ffffffff, 00800000 07: ffffffff -> ffffff7f, 00000080 07: ffffff7f -> ffffffff, 00000080 10: 00000000 -> 00000001, 00000001 (knob) 10: 00000001 -> 00000002, 00000003 (knob) 15: 003f000c -> 003f000b, 00000007 (jog wheel) 15: 003f000b -> 003f000a, 00000001 (job wheel) 14: 00100005 -> 00110005, 00010000 (knob) 09: ffffffff -> fffffbff, 00000400 09: fffffbff -> ffffffff, 00000400 05: 01ff00a6 -> 017f00a6, 00800000 05: 017f00a6 -> 01ff00a6, 00800000

Thanks

Takashi Sakamoto

Hi Takashi,

On Sun, 2018-10-14 at 21:09 +0200, Scott Bahling wrote:

On Sat, 2018-10-13 at 19:40 +0900, Takashi Sakamoto wrote:

...

For FW-1082 these quadlets includes value of movable fader as well, however unlike FW-1884 they have fluctuate quirk. So I think it reasonable for us to program this module to ignore them.

Ah, understood.

...

Instead, let us program applications so that they call 'hinawa_snd_tscm_get_status()' periodically to get current value of these faders between touch and untouch event on quadlet 05? This take applications to consume CPU time more efficiently than handling many events.

That should work.

I have tried this, but the endianness of the status bits passed via this method seems to be wrong.

I noticed in your latest kernel code[1], that you don't convert the firewire data to local CPU endian when storing in the "after" variable which ends up getting pushed into the status structure as big endian:

after = buffer[s->data_block_quadlets - 1]; ... ... ... tscm->status[index] = after;

Shouldn't that be:

after = be32_to_cpu(buffer[s->data_block_quadlets - 1]);

which also would remove the need for later conversions in that block of code?

I have a tested patch which I will send as a pull request once github is functioning again.

...

...

Well, as a result, ALSA firewire-tascam driver handles 'edge-trigge' events except for jog wheel and knobs. For this kind of event, it's useful to notify before/after value when emitting notification. So I'd like to change structure passed to UAPI so that:

struct snd_firewire_tascam_control { unsigned int index;

•   __u32 flags;
  

•   __u32 before;
  

•   __u32 after;
  

  };

Would I request your opinion? You can see patches here:

https://github.com/takaswie/snd-firewire-improve/tree/topic/tascam-userspace...

• https://github.com/takaswie/libhinawa/tree/topic/tascam-userspace-take3

You can receive 'control' event of 'HinawaSndTscm' GObject with these two values:

...

Sounds reasonable. For state change detection, I currently store the "before" state of each control in my application. Your new driver implementation will mean not needing to maintain my own state structures for that purpose.

I will try it out in the next few days.

I have only done a small amount of testing, but so far the control event setup is working fine.

-Scott

[1] https://github.com/takaswie/snd-firewire-improve/blob/topic/tascam-userspace...

Hi Takashi,

On Fri, 2018-11-02 at 21:05 +0900, Takashi Sakamoto wrote:

Hi Scott,

On 2018/11/02 18:26, Scott Bahling wrote:

...

I have tested and the patch above works as expected.

Thanks for your check. I pushed the above patch into my remote branch.

Well, soon, merge window for v4.20 (or v5.0) kernel will be closed, then we start working for next v4.21 (or v5.1) kernel. I have a plan to include changes required for the status and control message in this development period (not prepare yet) and the changes are the same in the remote branch. I'll add you to C.C list when posting patches for it.

Thanks!

If you require more functionality, please inform it to me in this development period.

I have been testing the patches for a while now and they work without issue. I'm also testing the libhinawa and hinawa-utils code in the process. I haven't tested the channel level values from the isochronous packets as I haven't a need for that so far. I see that the data changes as expected, but I have not verified if the values are accurate.

But my primary need was the control surface. Between what you already had hinawa-utils and the kernel patches to pass the isochronous data to userspace, I'm able to react on all input from the controls as well as set the fader positions and light the LEDs. I will submit a pull request to hinawa-utils for controlling the LEDs and Fader positions for the FW-1884.

Thanks for your help!

Regards,

Scott