Mixer API V2


The mixer API serves as a communication mechanism between the hardware communication layer and the mixer applications. This separation is there since there can only be one process that interfaces with the hardware, but multiple control processes can be imagined (e.g. midi control daemon).

It is not the goal of the API to provide a mechanism that allows the automatic construction of mixer UI's or other controllers. Providing this type of functionality is very complex since it requires an abstraction that encompasses the abilities and limitations of all available devices.

Instead an approach consisting of several broad but inaccurate abstractions has been chosen. The most obvious example for this is the Matrix Mixer control. All non-trivial mixer operations are fit into the matrix mixer model. This model implies that there is a path from every one of its inputs to every one of its outputs. However a lot of devices don't implement such elaborate mixing functionality, e.g. an input can only be mixed to a subset of outputs. The matrix mixer abstraction does not provide means to prevent invalid mixing operations.

The result is that in order to implement a control interface for a certain device, some knowledge about the device's operation is necessary. This is not considered a problem since this should only be done once for every device. A scheme deriving all these abilities and limits would complicate things to a much larger degree.

Transport Layer

The transport layer is chosen to be DBus, since it provides a decent RPC mechanism and has good chance of being present on any fairly recent distribution. It also provides standardized means of introspection (=figuring out what functions you can call) and has plenty of language bindings and language tools. It also seems to be invented for this type of applications.

The ffado dbus server connects to the session bus and it listens to:


Several paths are presented by the server. The main control path is




All DBUS compatible FFADO entities implement the org.ffado.Control.Element.Element interface. This allows them to be part of a Container and automates the DBUS support.


Interfaces implemented:

A first child node is the DeviceManager? node:


The DeviceManager? node will contain child nodes that represent the detected FFADO-compatible devices on the firewire bus. The child node path is the GUID of the device.