From: Jonathan Woithe <jwoithe@ph...> - 2007-12-13 22:42:10
Over the next month or so I'm hoping to have a look at adding support for
the MOTU mixer (assuming MOTU streaming is under control). What is the
current state of the mixer infrastructure? More importantly, is there
anywhere you can suggest I look to get a handle on what needs to be done to
support mixer elements?
Do we have an application which can be used to exercise the mixer controls?
I should probably be able to tell all this from svn but due to commitments
over the past month I have lost track of precisely where we're at with the
mixer infrastructure. I know you made a switch from OSC to dbus but that's
about the extent of my knowledge at present.
Jonathan Woithe wrote:
> Hi Pieter
> Over the next month or so I'm hoping to have a look at adding support for
> the MOTU mixer (assuming MOTU streaming is under control). What is the
> current state of the mixer infrastructure? More importantly, is there
> anywhere you can suggest I look to get a handle on what needs to be done to
> support mixer elements?
> Do we have an application which can be used to exercise the mixer controls?
> I should probably be able to tell all this from svn but due to commitments
> over the past month I have lost track of precisely where we're at with the
> mixer infrastructure. I know you made a switch from OSC to dbus but that's
> about the extent of my knowledge at present.
I switched over to dbus with introspection indeed, hence you can use any
generic DBUS client to control the mixer stuff (e.g. dbus-viewer).
The basic architecture of the system is:
libcontrol/* contains some base classes that are to be inherited by
control elements. (these should become interfaces at one point)
There are some elementary base classes present: Container and Element.
Then there are some more specific 'Elements': Continuous, Discrete and
The idea is that every FFADODevice inherits from Control::Container, and
hence can contain other control elements.
In order to create controls you would implement subclasses of the
element that suits your needs the best (e.g. Control::Discrete). You
then re-implement the get/set functions to perform the action you have
in mind. When building a mixer it then comes down to creating new
instances of that specific class. You then add them to the 'FFADODevice
Container' and that's it.
The DBUS server application can expose the basic Control::* types over
DBus. 'exposing' means providing RPC calls that map to the objects
functions. It doesn't even have to be DBUS. It would be possible to
implement an OSC based server too. The libcontrol stuff doesn't care.
Note that you can create 'subcontainers', i.e. a container can contain
another container, so you can create hierarchy.
I think it's a quite elegant system, and very simple to implement at the
device side. The Control::* elements are still rather basic (e.g. there
is no 'definition' of the range of Continuous or Discrete elements) and
incomplete (i'd like an enum type of control too, which I'll try and
implement soon (clock source selection)).
The code is the best example, take a look at:
especially the saffirepro is a good example, since it exercises the
complete control element stuff. Check the buildMixer() function.
I think it's a matter of days to implement mixer support through this
framework. Have fun :).