Re: Controlling the Tascam FW-1884

[Takashi Sakamoto <o-takashi@sakamocchi.jp>]

Hi Scott,

On Sep 29 2018 00:28, Scott Bahling wrote:
> On Fri, 2018-09-28 at 12:44 +0900, Takashi Sakamoto wrote:
> 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?

The latter is better.

The patchset to map page frame for status and control image is just for
our work to investigate. Practically, it includes several issues:

1. Due to scheduling granularity of user processes against interval to
update the image, applications in the processes can fail to pick up
events on the image.

2. Recently, bare embedded board with ARM cores becomes pupular. Some
of them have PCIe buses. It's better for users to use units on
IEEE 1394 bus, however ARM is known as cache incoherent architecture.
In the architecture, page frame mapping can bring unexpected results.
(See a conditional macro[1].)

For these reasons, we need to find another solution based on
synchronous procedure such like read(2)/ioctl(2). For this direction,
we need to care several items:

1. The status and control image includes several types of data;
bitflags for physical controls of device surface, level meters
and so on. Although it's acceptable to fail picking up values for
level meters, it's not for physical controls.

2. TASCAM FireWire series includes below models and the layout of
bitflags differs depending on them:
  - FW-1884
  - FW-1804
  - FW-1082
(FE-8 has not been investigated yet.)
It cost expensive to handle such differences by kernel land in
development/maintenance POV.

3. In current implementation of ALSA firewire-tascam driver,
demultiplexing of OHCI 1394 isochronous packet runs on
software IRQ context. Total time of software IRQ context is
shared in system wide, thus it's better to reduce load as
much as possible even if software IRQ run on schedulable tasks
(threadedirq).

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. Quadlet
36-43 shows analog output level. The other quadlets are unknown."

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

[1] 
https://github.com/takaswie/snd-firewire-improve/blob/topic/tascam-userspace/sound/firewire/tascam/tascam-hwdep.c#L192
[2] 
http://mailman.alsa-project.org/pipermail/alsa-devel/2015-July/094817.html


Thanks

Takashi Sakamoto