Hi all,

As ALSA firewire stack includes more drivers to expand support for audio and music units on IEEE 1394 bus, I realized that some devices generate periodical short noises in its output sound, and some users reports the issue. I wrote my previous report[1] for Dice ASIC, however today I realize the other type of device has the similar issue. Furthermore, even if using the same ASIC, one has the issue but another has none.

For further investigation, the sequence of packet for long period is required to analyze inclination of the content; e.g. several tens minutes. However, it requires tons of memory for the content of captured packets. As long as I know, there's no protocol analyzer with so much memories.

Unlike asynchronous communication on IEEE 1394 bus, any isochronous communication on the bus can be captured by IR context of 1394 OHCI[2]. This enables to use Linux system for packet capture with large memory/storage.

In the diagram below, two physical machines are connected by two 1394 OHCI controller, and target device is connected to one of the controller.

Windows (or macOS) machine +-----------------+ | proprietary | | unit driver | | | | | proprietary | | ohci driver | | | | | 1394 OHCI | +---- + - + -----+ | | | +---- target device | +---- + ---------+ | 1394 OHCI | | | | | firewire-ohci | | firewire-core | | /dev/fw* | | | | | libhinoko | | | | | applications | |(Python 3 script)| +-----------------+ Linux machine

In this case, the two controllers and the device are on the same bus. When an unit driver in one side (Windows OS) communicates to the device by isochronous packet, the packets from both of the unit driver and the device can be captured in another side (with Linux OS).

Today I released libhinoko[3] to assist this kind of work. This I/O library produces a series of API to operate 1394 OHCI controller via UAPI of Linux FireWire subsystem for any isochronous context; i.e. IR and IT. Especially, IR context with buffer-fill mode is useful for the kind of work. For the implementation, I got great help from Clemens[4].

Like a sister project (libhinawa[5]), the library supports GObject Introspection[6] as well for dynamic language bindings. As a result, interpreter language is available to write libhinoko application (e.g. Python 3). This is good for prototyping of program adapted to vendor-dependent and model-dependent inclinations. You can see some Python 3 examples in `samples` directory (PyGObject[7] is required to run).

If you're interests in libhinoko and its application, please refer to introduction section of documentation[8]. Please ensure that public APIs of the library are not stable yet.

I need more time for the investigation, but wish to propose better implementation against the issue and to write a paper in this year.

[1] [alsa-devel] Dice packet sequence quirk and ALSA firewire stack in Linux 4.6 https://mailman.alsa-project.org/pipermail/alsa-devel/2016-May/107715.html [2] 1394 Open Host Controller Interface Specification https://ieee1394.wiki.kernel.org/index.php/Specifications#1394_Open_Host_Con... [3] Release version 0.1.0 release · takaswie/libhinoko https://github.com/takaswie/libhinoko/releases/tag/v0.1.0 [4] Overview — GObject Introspection https://gi.readthedocs.io/en/latest/ [5] IEEE 1394 for Linux / Content of buffer for receive_multichannel ctx in userspace https://sourceforge.net/p/linux1394/mailman/message/36579137/ [6] takaswie/libhinawa https://github.com/takaswie/libhinawa [7] Overview — PyGObject https://pygobject.readthedocs.io/en/latest/ [8] Hinoko Reference Manual: Hinoko Reference Manual https://takaswie.github.io/libhinoko-docs/

Regards

Takashi Sakamoto