Hi Takashi,
On Sun, 2018-10-07 at 23:11 +0900, Takashi Sakamoto wrote:
Hi Scott,
On Oct 2 2018 12:16, Takashi Sakamoto wrote:
I have an idea to invervene them:
- 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.
- 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 .
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.
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.
diff -Nrup a/sound/firewire/tascam/amdtp-tascam.c b/sound/firewire/tascam/amdtp-tascam.c --- a/sound/firewire/tascam/amdtp-tascam.c 2018-10-09 09:49:54.693197299 +0200 +++ b/sound/firewire/tascam/amdtp-tascam.c 2018-10-11 10:55:14.865475143 +0200 @@ -130,8 +130,10 @@ static void read_status_messages(struct index = be32_to_cpu(buffer[0]) % SNDRV_FIREWIRE_TASCAM_STATUS_COUNT; quad = buffer[s->data_block_quadlets - 1];
- if (index >= 5 && index <= 15) { - if (index == 5) + if (index <= 15) { + if (index == 4) + mask = 0xffff0000; + else if (index == 5) mask = 0x0000ffff; else mask = 0xffffffff;
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.
Thanks!
Scott