Crates.io | firewire-motu-protocols |
lib.rs | firewire-motu-protocols |
version | 0.3.0 |
source | src |
created_at | 2022-08-05 07:25:16.394526 |
updated_at | 2024-02-25 03:47:51.886679 |
description | Implementation of protocols defined by Mark of the Unicorn for its FireWire series. |
homepage | https://alsa-project.github.io/gobject-introspection-docs/ |
repository | https://github.com/alsa-project/snd-firewire-ctl-services |
max_upload_size | |
id | 639191 |
size | 372,336 |
The library crate includes implementation of protocol for models of MOTU FireWire series, designed to audio and music unit in IEEE 1394 bus.
The Mark of the Unicorn (MOTU) launched 828 in 2001 as its first model of FireWire series. The model and 896 (launched in 2002) were the first generation of series in which the same hardware design and protocol appear. The first model of second generation, 828 mkII, was launched in 2004. The first model of third generation, 828 mk3 was launched in 2008.
In MOTU FireWire series, some models were launched for video processing purpose, while they are not supported yet since protocol is unclear.
All of models support notification by asynchronous transaction with quadlet message to registered address. The message includes bit flags for some purposes; foot pedal event, and so on. For further functions, the models in second and third generation also have two ways to configure internal functions. In the crate, they are called as "register DSP" and "command DSP".
The register DSP models use asynchronous write transaction to address space of target node for corresponding function. When user operates on-board function by hand, the change status is notified in isochronous packet multiplexed with PCM frames and MIDI messages. The information of hardware metering is also delivered by the same way.
The command DSP models use command to configure functions and notify status changes. The command frame expresses current configuration. When user operates on-board function by hand, the command frame is transmitted by asynchronous transaction to registered address. The other node transmits asynchronous transaction with command frame to configure the functions. The information of hardware metering is delivered by the same way as registered DSP model.
Linux sound subsystem, a.k.a ALSA, provides loadable kernel module (snd-firewire-motu
) as
driver for the units. The driver maintains isochronous packet streams for audio frames and MIDI
messages as well as notification mechanism by asynchronous transaction since the other internal
functions such as digital signal processing can be operated by user space application directly.
For register DSP models and command DSP models, the driver caches state of device expressed in
the sequence of quadlet message in isochronous packet stream.
The driver allows the application to read the notified message and cache of state by executing
system call.
hitaki library has
SndMotu
GObject class for the purpose. Nevertheless, the crate has slight dependency on hitaki
crate about the SndMotuRegisterDspParameter
structure. The operation to SndMotu
class is
delegated to runtime program.
The crate is supplemental implementation for runtime program to operate the internal functions except for isochronous packet streams.
This is the list of dependent crates.
The glib and hinawa crates require some underlying system libraries
The functions of Linux FireWire and Sound subsystem is called via hinawa and hitaki crates and libraries to communicate with node in IEEE 1394 bus, thus the crate is not portable.
This is the list of models currently supported.
The crate is developed and maintained by ALSA GObject Introspection team for snd-firewire-ctl-services project, and not stable yet. The included Rust elements are likely changed without backward compatibility.
The crate is released under GNU Lesser General Public License v3.0 or later with respect to clause for reverse engineering.
If finding issue, please file it in https://github.com/alsa-project/snd-firewire-ctl-services/.
The implementation of protocol is developed by the way of reverse engineering; sniffing IEEE 1394 bus to which target device is connected, and analysis of the communication between the device and driver provided by hardware vendor. It's natural not to work with your device since developer worked with blackbox.