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
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
