[alsa-devel] Controlling the Tascam FW-1884

[Scott Bahling]

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
-------------- 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/20180924/7a2eefbe/attachment.sig>