All of lore.kernel.org
 help / color / mirror / Atom feed
From: Scott Bahling <sbahling@suse.com>
To: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	ffado-devel@lists.sf.net
Subject: Re: Controlling the Tascam FW-1884
Date: Fri, 12 Oct 2018 10:12:47 +0200	[thread overview]
Message-ID: <246b8baaa3c415a0accdb76d3b524dec5e0429f9.camel@suse.com> (raw)
In-Reply-To: <fed5ab3a-c39a-4de9-6802-c064a33140eb@sakamocchi.jp>

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


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

  reply	other threads:[~2018-10-12  8:12 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <9cec059e1ff1a558f21a3f0729c5a69a3d506573.camel@suse.com>
2018-09-08  2:53 ` Controlling the Tascam FW-1884 Takashi Sakamoto
2018-09-08 11:21   ` Scott Bahling
2018-09-10  7:59     ` Takashi Sakamoto
2018-09-12  7:18       ` Scott Bahling
2018-09-17 14:36         ` Takashi Sakamoto
2018-09-24  9:32           ` Scott Bahling
2018-09-28  3:44             ` Takashi Sakamoto
2018-09-28 15:28               ` Scott Bahling
2018-10-02  3:16                 ` Takashi Sakamoto
2018-10-03 20:37                   ` Scott Bahling
2018-10-06  9:07                     ` Takashi Sakamoto
2018-10-07 11:32                       ` Scott Bahling
2018-10-07 14:11                   ` Takashi Sakamoto
2018-10-12  8:12                     ` Scott Bahling [this message]
2018-10-13 10:40                       ` Takashi Sakamoto
2018-10-14 19:09                         ` Scott Bahling
2018-10-22 11:47                           ` Scott Bahling
2018-10-30  9:34                             ` Takashi Sakamoto
2018-11-02  9:26                               ` Scott Bahling
2018-11-02 12:05                                 ` Takashi Sakamoto
2018-11-16 17:37                                   ` Scott Bahling
2018-10-03 19:31               ` Scott Bahling

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=246b8baaa3c415a0accdb76d3b524dec5e0429f9.camel@suse.com \
    --to=sbahling@suse.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=ffado-devel@lists.sf.net \
    --cc=o-takashi@sakamocchi.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.