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] 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_Controller_Interface_Specification
[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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
