root/trunk/libffado/doc/motu_firewire_protocol.txt

Notes on the FireWire protocol used by MOTU audio devices
=========================================================

Author: Jonathan Woithe
Document version: 20100914-1


Audio/MIDI data
---------------

Note: while this section focuses on the Traveler, the same basic data format
is utilised for the 828Mk2, 896HD, Ultralite and possibly other MOTU
interfaces.  The differences lie in the number of discrete audio channels
sent and perhaps the order of some channels within a data block.

Audio data is sent via iso packets.  With nothing else present on the
FireWire bus Iso channel 0 is used by the PC to send data to the MOTU while
iso channel 1 is used by the MOTU to send data to the PC.  The channels
used can be arbitarily chosen by software subject to availability as
indicated by the Isochronous Resource Manager (IRM).

The MOTU appears to utilise some ideas from IEC 61883-6.  For example, each
iso packet seems to include a CIP header (the iso packet header has the tag
field set to 0x01 to indicate the presence of the CIP).  However, the
standard is not followed completely to the finest detail.  Typical CIP
header values from the Traveler for audio data packets at a 44.1 kHz rate
with SPDIF enabled and the optical I/O ports set to ADAT mode are as
follows:

  SID = 0x02    dependent on bus topography
  DBS = 0x13    expressed in quadlets
  FN  = 0       as expected from IEC 61883-6
  QPC = 0       as expected from IEC 61883-6
  SPH = 1       indicating a source packet header is included.  IEC 61883-6
                expects SPH to be 0 for A/V transport.
  Rsv = 0
  DBC = yyy     Data block count varies from packet to packet
  FMT = 0x02    IEC 61883-6 expects this to be 0x10 for A/V data.  MOTU
                seem to be using 0x02 for their own purposes.
  FDF = 0x22    This means the data is 32 bit floating point according to
                IEC 61883-6.  The data isn't 32 bit floating point, so MOTU
                obviously use this field to mean their own thing.
  SYT = 0xffff  IEC 61883-6 says this field is the time the event is to be
                presented to the receiver.  Clearly this isn't used by MOTU.

The FDF field is interesting in that when interpreted as per IEC 61883-6, it
doesn't reflect the reality of the audio stream used by the Traveler (see
below).  One has to assume that MOTU have redefined this for their own
purposes.

The DBC field is incremented from packet to packet by the number of
data blocks contained in the packet.  At 1x rates there are nominally 8
data blocks per packet, so DBC increments by 8 between successive iso data
packets.

The DBS (Data Block Size) varies according to the sampling rate in use. On
the Travler at 1x rates (44.1 kHz, 48 kHz) it is 0x13.  At 2x rates it
reduces to 0x10 while at 4x rates it decreases again to 0x09.  Similarly the
iso data length differs according to the sampling rate: 0x268 at 1x rates
(giving 8 blocks per iso data packet), 0x408 at 2x rates (giving 16 blocks
per iso data packet) and 0x488 at 4x rates (giving 32 blocks per iso data
packet).

DBS/FDF behaves a little differently with the Ultralite interface.  At both
1x and 2x rates DBS is 19 (0x13) while FDF is still 0x22.  Based on
behaviour of earlier interfaces this would give a block size of 19*4 = 76
bytes.  However, in reality it is only 52 bytes: 4 bytes SPH, 6 bytes
MIDI/control data, 8x3 bytes analog data, 2x3 bytes SPDIF, 2x3 bytes Mix1
and 2x3 bytes padding (probably used as headphone send in transmit stream). 
It's not clear how the given DBS/FDF values relate to this block size. 
There are still 8 blocks per iso data packet at 1x rates, and 16 at 2x
rates, giving total packet sizes (including the 8 byte CIP) of 424 bytes at
1x rates and 840 at 2x rates.

The Traveler usually becomes the IRM on the FireWire bus it is plugged into;
when functioning as the IRM it also broadcasts "cycle start" packets on a
regular basis as would be expected. These appear to be as per ieee1394-1995. 
These broadcast a quadlet in the same form as the Traveler's cycle time
register with a value equal to the cycle time register at the time the
packet was submitted for transmittsion.  The format of this register is as
follows:

  bits 31-25 = seconds count (0-127)
  bits 24-12 = cycle count (0-7999)
  bits 11-0  = cycle offset (0-3071)

Each portion of the register wraps to 0 at the end of the range, causing
the next most significant component to be incremented by one.  When the
"seconds count" overflows it simply wraps to 0 without incrementing
anything.  The cycle offset is incremented by a 24.576 MHz clock.
The cycle count can be thought of as the fractional part of the current
second in units of 125 us.

The data portion of a typical iso packet to/from the Traveler contains a CIP
header and 8, 16 or 32 data blocks (depending on sampling rate) of size DBS
quadlets (DBS*4 bytes).  Empty packets are utilised periodically to maintain
the long-term average equal to the sampling interval.  For example, at 48
kHz, 3 packets with 8 datablocks are sent, followed by a single empty
packet.

The format of each data block varies according to whether a 1x, 2x or 4x
clock multiplier is in use.  At 44.1 kHz or 48 kHz (ie: a 1x clock), each
data block contains the following in this order:

  32 bit Source Packet Header (SPH) (+)
  48 bits of control/MIDI data (&)
  24 bit audio values: headphone L&R / mix1 L&R (*)
  24 bit audio values: analog channels 1-8
  24 bit audio values: AES-EBU L and R
  24 bit audio values: SPDIF L and R
  24 bit audio values: ADAT channels 1-8

At 2x clock frequencies (88.2 kHz and 96 kHz) the ADAT channels 5-8 are
dropped from the datablock, leaving the following arrangement:

  32 bit Source Packet Header (SPH) (+)
  48 bits of control/MIDI data (&)
  24 bit audio values: headphone L&R / mix1 L&R (*)
  24 bit audio values: analog channels 1-8
  24 bit audio values: AES-EBU L and R
  24 bit audio values: SPDIF L and R
  24 bit audio values: ADAT channels 1-4

At 4x clock frequencies (176.4 k kHz and 192 kHz) all digital I/O is disabled
along with the separate headphone / mix1 bus.  The resulting datablock
is formatted as follows.

  32 bit Source Packet Header (SPH) (+)
  48 bits of control/MIDI, MSB first (&)
  24 bit audio values: analog channels 1-8
  16 bits of padding (%)

Notes:
 (+) The SPH is defined in IEC 61883-6:
       Bits 31-25 = reserved
       Bits 24-12 = cycle count (0-7999)
       Bits 11-0  = cycle offset (0-3071)
 (&) These values have been observed to be almost always 0 in packets sent
     by the PC except when MIDI is sent, but for packets sent by the MOTU
     they are generally non-zero.  See below for more details on these
     bytes.
 (*) Packets from the traveler send mix1 data here; packets from the PC
     send data for the headphone channel here.
 (%) It appears the Motu pads data in a cycle using values of either 0x0000
     or 0xffff.  It appears to use a regular pattern, although the pattern
     itself appears variable.  Two patterns have been observed so far:
       * two blocks of 0xffff followed by two blocks of 0x0000.
       * a block of 0xffff followed by three blocks of 0xffff.
    The PC driver always appears to send pad values of 0x0000.

If the optical ports have been set to TOSLINK rather than ADAT, the data
sent in the iso datablocks is adjusted accordingly - the 8 (or 4) ADAT
channels and 2 coax SPDIF channels are omitted and the 2 optical TOSLINK
channels are sent in their place.

For packets from the PC to the MOTU, the timestamp given in the SPH probably
represents the cycle time at which the data given should be output by the
interface.  For packets coming from the MOTU to the PC this timestamp is
most likely the cycle time at which the data was sampled by the interface.

The cycle offset increment used for each successive datablock varies
according to the sampling frequency as one would expect.  While the
increment value is "mostly constant" it does vary by +/-1 at times.  This
would be to keep the data in sync with the audio sampling frequency in use,
as some audio sampling frequencies - those which are multiples of 44.1 kHz -
are not integral factors of the cycle offset frequency (and even those which
are sometimes deviate from the theoretical increment by 1).  The increments
seen in data coming from the Motu are generally a lot more consistent than
those coming from the PC.  It is clear from this that the audio clock is not
locked to the firefire cycle clock in any way.

The 48 bits Control/MIDI data appears to play a part in MIDI data
transmission.  When the PC is transmitting a MIDI stream to the Motu it does
so byte by byte.  A byte of midi data is sent using the first and third bytes
following a data block's SPH, forming a midi subpacket for want of a better
description.  The format of the midi subpacket appears to be

  0x0100nn

where nn is the MIDI byte being sent.  Having more than one MIDI subpacket
in a single transmitted iso data packet has never been observed; it seems
therefore that on this interface the timing of the MIDI subpackets is to
match exactly their transmission onto the wire.  Furthermore, sending data
to the MOTU at a rate faster then the hardware midi rate of 3125 bytes per
second (31250 baud with 8 bit data, 1 start bit and 1 stop bit) will cause
MIDI bytes to be dropped or corrupted in interesting ways.

For data coming from the Motu it appears that these 48 Control/MIDI bits are
used for a number of purposes, although some of the details are yet to be
worked out.  However, it appears that MIDI data is intermingled with this. 
At this stage it seems that when bit 40 is set then bits 24-31 contain a
MIDI byte.  The contents of bits 41-47 and 32-39 do not appear to be
affected by having bit 40 set, so at this stage one concludes that their
function (mostly related to Cuemix setting updates) continues even when MIDI
data is sent.  Obviously any other function of bits 24-31 is interrupted when
these bits are required for a MIDI byte.

Putting all this together, bit 40 appears to be a "MIDI byte present" bit;
if set, bits 24-31 contain a MIDI byte.  All other bits of the Control/MIDI
fields continue to function even when bit 40 is set.  If this definition is
adopted it applies equally well to both incoming and outgoing MIDI data.

It should be noted that the Traveler has never been observed to send more
than one MIDI data byte per iso packet.  Presumedly therefore the timing of
the bytes delivered by the Traveler is very close to the timing on the MIDI
wire.  However, other MOTU devices (the 828Mk2 for example) do transmit more
than one MIDI byte in a single packet.  On these devices MIDI messages must
be buffered in the device and sent in a burst once a complete message has
been received.


Audio channel locations in a frame
----------------------------------

Not surprisingly the different MOTU interfaces place channels at different
offsets within a frame.  This section attempts to document what we know
about the channel locations for various devices.

828 Mk 1:
  Analog 1-8: 10, 13, 16, 19, 22, 25, 28, 31
  SPDIF 1-2: 34, 37
  ADAT 1-4: 40, 43, 46, 49
  ADAT 5-8 (1x rates only): 52, 55, 58, 61

896HD:
  Mix L-R (in, not at 4x): 10, 13
  Phones L-R (out, not at 4x): 10, 13
  Analog 1-8 (1x/2x rate): 16, 19, 22, 25, 28, 31, 34, 37
  Analog 1-8 (4x rate): 10, 13, 16, 19, 22, 25, 28, 31
  MainOut L-R (out, 1x/2x only): 40, 43
  Unknown 1-2 (in, 1x/2x only): 40, 43
  ADAT 1-4 (1x/2x only): 46, 49, 52, 55
  ADAT 5-8 (1x only): 58, 61, 64, 67
  AES/EBU 1-2 (1x with ADAT active): 70, 73
  AES/EBU 1-2 (2x with ADAT active): 58, 61
  AES/EBU 1-2 (1x/2x with ADAT off): 46, 49

828 Mk 2:
  Mix L-R (in): 10, 13
  Phones L-R (out): 10, 13
  Analog 1-8: 16, 19, 22, 25, 28, 31, 34, 37
  Mic 1-2 (in): 40, 43
  Main L-R (out): 40, 43
  SPDIF 1-2: 46, 49
  ADAT 1-4: 52, 55, 58, 61
  ADAT 5-8 (1x rates only): 64, 67, 70, 73

Traveler:
  Mix L-R (in, 1x/2x rates only): 10, 13
  Phones L-R (out, 1x/2x rates only): 10, 13
  Analog 1-8 (1x/2x rate): 16, 19, 22, 25, 28, 31, 34, 37
  Analog 1-8 (4x rate): 10, 13, 16, 19, 22, 25, 28, 31
  AES/EBU 1-2 (1x/2x rate): 40, 43
  SPDIF/Toslink 1-2 (1x/2x rate): 46, 49
  ADAT 1-4 (1x/2x rate): 52, 55, 58, 61
  ADAT 5-8 (1x rate): 64, 67, 70, 73

Ultralite:
  Mix L-R (in): 10, 13
  Phones L-R (out): 10, 13
  Mic 1-2 (in): 16, 19
  Analog 1-2 (out): 16, 19
  Analog 3-8: 22, 25, 28, 31, 34, 37
  SPDIF 1-2 (in): 40, 43
  Main L-R (out): 40, 43
  Padding (in): 46, 49
  SPDIF 1-2 (out): 46, 49

8Pre:
  Mix L-R (in): 10, 13
  Phones L-R (out): 10, 13
  Analog 1-8 (in): 16, 19, 22, 25, 28, 31, 34, 37
  Main L-R (out): 16, 19
  Padding (out): 22, 25
  ADAT 1-8 (in): 40, 43, 46, 49, 52, 55, 58, 61
  ADAT 1-8 (out): 22, 25, 28, 31, 34, 37, 40, 43

828 Mk 3:
  Mic 1-2 (in, 1x/2x rates): 10, 13
  Phones L-R (out, 1x/2x rates): 10, 13
  Unknown 1-2 (out, 4x rates): 10, 13
  Analog 1-8: 16, 19, 22, 25, 28, 31, 34, 37
  Return 1-2 (in): 40, 43
  Main L-R (out): 40, 43
  SPDIF 1-2 (1x/2x rates): 46, 49
  Unknown (out, 4x rates): 46, 49
  Reverb 1-2 (in, 1x/2x rates): 52, 55
  [ Optical ports follow according to optical mode: first Optical-A
  channels, then optical-B channels.  Out channels start at 52, in channels
  start at 58.  At 1x rates 58/61 are "unknown" ahead of the optical
  channels, with inputs at 76/79 being unknown at 2x rates. ]

Ultralite Mk 3:
  Mix L-R (in): 10, 13
  Phones L-R (out): 10, 13
  Mic 1-2 (in): 16, 19
  Analog 1-2 (out): 16, 19
  Analog 3-8: 22, 25, 28, 31, 34, 37
  SPDIF 1-2 (in, 1x/2x rates): 40, 43
  Padding (out, 1x/2x rates): 40, 43
  SPDIF 1-2 (out, 1x/2x rates): 46, 49

Ultralite Mk 3 hybrid:
  Mix L-R (in): 10, 13
  Phones L-R (out): 10, 13
  Mic 1-2 (in): 16, 19
  Analog 1-2 (out): 16, 19
  Analog 3-8: 22, 25, 28, 31, 34, 37
  SPDIF 1-2 (in, 1x/2x rates): 40, 43
  Main L-R (out): 40, 43
  Reverb 1-2 (in, 1x/2x rates): 46, 49
  SPDIF 1-2 (out, 1x/2x rates): 46, 49
  Unknown 1-4 (in, 1x/2x rates): 52, 55, 58, 61

Traveler Mk 3:
  Mix L-R (in): 10, 13
  Phones L-R (out): 10, 13
  Analog 1-8: 16, 19, 22, 25, 28, 31, 34, 37
  AES/EBU 1-2 (1x/2x rates): 40, 43
  SPDIF 1-2 (1x/2x rates): 46, 49
  Reverb 1-2 (in, 1x rates): 52, 55
  Unknown 1-2 (in, 1x rates): 58, 61
  [ Optical port channels follow in a similar was as for the 828 Mk 3.
  The precise locations are yet to be confirmed as of 14 Sept 2010. ]


SMPTE timecode
--------------
It appears that the traveler itself has no way to generate SMPTE timecode
internally.  The SMTPE console application allows one to generate timecode,
but the timecode stops as soon as this application is exitted.

In addition, changing any of the settings in the SMPTE console does not
appear to change any hardware settings in the MOTU with the exception of the
"clock/address" control - this changes the source in a similar way to that
in the main MOTU setup program.  The obvious conclusion here is that SMTPE
generation appears to be a feature implemented in the host software.


Talkback/listenback
-------------------
These features of the Cuemix console appear to be implemented in the host
software.  Enabling either of these appears to simply set the mixer
registers to suit talkback/listenback, with the "normal" settings 
restored when talkback/listenback is disengaged.  The motu itself does not
appear to have any explicit on-board support of these modes.


Bus renaming in Cuemix console
------------------------------
The naming of the 4 mix buses provided by the Cuemix console seems to be
internal to the Cuemix console application.  Changing the mix names results
in no traffic being sent to/from the motu.


MIDI in/out
-----------
MIDI data is sent within the first 48 bytes of the data blocks within an
iso data packet.  This is described in detail in the "Audio/MIDI data" 
section.


Controlling Cuemix in pre-Mark3 models
--------------------------------------
It has been noted that some mixer settings (particularly registers 0x4yyy)
have been found to utilise "write enable" bits which when set allow their
associated part of the control register to be acted upon.  There is no
reason to think that the 0x4yyy registers are unique here; it's likely that
other control registers implement a similar idea.  It is thought that
whenever bits are seemingly set to 1 by the Cuemix console there is a stong
possibility they form some kind of enable mask.  When such values are noted
in the register description it is likely that they must be supplied as noted
if the desired register change is to be successful.  In time it is hoped that
the function of these magic settings can be deduced.

Finally, when manually changing Cuemix settings on the Motu's front panel,
the Cuemix console is observed to update its display accordingly.  The data
for these updates comes via a byte stream transmitted by the Motu using a
key/value system in the first two bytes of each data block in the iso
stream.  Within a given data block, bits 7-1 of the first byte is the key
while the second byte gives the respective value.  Recall that bit 0 of the
first byte is a "MIDI byte present" flag, indicating that the third byte in
the data block contains a MIDI data byte - refer to the "Audio/MIDI data"
section for more details.

The following describes all keys observed so far from the Traveler.  Note
that the key values reported here are for bits 7-0 of the first byte with
bit 0 (the MIDI present bit) masked to zero.

  0x04 = Some kind of timer/counter.  Details not yet identified.
  0x0c = Mix bus sync key.  The mix bus to which the next mix bus 
         parameter(s) apply to is given by bits 7-5 in the data byte.
  0x14 = channel gain value (0x00-0x80)
  0x1c = channel pan value (0x00-0x80, 0x40=centre)
  0x24 = channel control: 0x01=mute, 0x02=solo, 0x08=paired
  0x2c = mix bus gain (0x00-0x80)
  0x34 = mix bus destination/mute.  Bits 3-0 are as per "output destination"
         in register 0x0c20; bit 4 is the mute bit.
  0x3c = main out volume (0x00-0x80)
  0x44 = phones volume (0x00-0x80)
  0x4c = phones assign (values as per "output destination" in register 0x0c20)
  0x54 = at 48 kHz remains fixed at 0x00.  Purpose unknown.
  0x64 = at 48 kHz remains fixed at 0x00.  Purpose unknown.
  0x6c = +6 dB boost (analog channels 5-8 only).  Bits 4-7 = channels 5-8.
  0x74 = ref level.  Bits 4-7 = channels 5-8.  Bit set/clear = +4/-10.
  0xfc = Some kind of timer/counter.  Details not yet identified.

For many of these keys there are multiple values to communicate; for
example, for key 0x14 (channel gain) there are up to 20 values for each of 4
mix buses, corresponding to the 20 input channels available (analog 1-8,
SPDIF, AES/EDU, ADAT 1-8).  In such situations the multiple values for a
given mix bus are transmitted sequentially (each having the same key)
following a mix bus sync key which gives the mix bus to which the values
apply.

In the case of the Traveler the following sequence of keys is used.
Timing/counter events have been omitted from this sequence.  N is the number
of channels active.

  Mix bus sync key
  N channel gain keys
  Mix bus sync key
  N channel pan keys
  Mix bus sync key
  N channel control keys
  Mix bus sync key
  Mix bus gain key
  Mix bus destination key
  Main out volume key
  Phones volume key
  Phones destination key
  Input 6dB boost key
  Input reference level key

The device-wide keys are therefore seen 4 times as often as the per-mixbus
keys.

Curiously enough, the gain trim and pad settings for analog channels 1-4
use a different method to communicate their changed status; for these
settings the Motu writes to a specific address on the PC and in
response the PC reads a register from the Motu.  When a channel's gain trim
or pad setting is altered:
 * Motu sends 0x20ffffff to address offset 0x100000000 on the PC 
 * In response the PC reads register 0x0c1c from the Motu to obtain the new
   gain trim value and pad setting.


Controlling Cuemix in Mark3 models
----------------------------------
With the introduction of the "Mark3" interface models (Ultralite, Traveler,
828) MOTU completely changed the method used to control the Cuemix features
of the interface.  This was partly out of necessity - with the additional
Cuemix features being added to the "Mark3" models MOTU otherwise faced an
unbounded expansion in the number of device registers needed.

Protocol analysis of an Ultralite-mk3 was provided by MG and GQ.

The Mark3 interfaces use a variation of a key-value protocol involving block
writes to register device register 0x10000 (bus address ffc0-ffff-0001-0000
nominally.  Either 2 or 3 quadlets are written depending on the message
being sent.  For this documentation we will refer to the bytes within a
message as b00 .. b11, with b00 being the first byte sent.

Byte b00 and b01 form a heartbeat word.  Precisely how this is constructed
is not currently known, but it seems it might just be a monotomically
increasing number probably used by the device to detect missing data or
something.

Byte b02 seems to be some kind of class identifier.  Currently identified
classes are:
  0x66: Faders (including bus master), pan, input trim
  0x69: Mute/Solo, Routing selection

Specific message formats are described below.

Trim: 3 quadlet message
  b00-b01 - heartbeat
  b02     - 0x66
  b03     - channel select (0x00-0x09)
  b04     - 0x02 (select trim control)
  b05-b06 - unknown, TBA
  b07-b10 - data (big endian float, 0.0 - 24.0)
  b11     - 0x00

Reverb send: TBA

Channel faders: 3 quadlet message
  b00-b01 - heartbeat
  b02     - 0x66
  b03     - bus select (0x00-0x09)
  b04     - 0x03 (select fader control)
  b05     - channel select (0x02-0x09)
  b06     - 0x02
  b07-b10 - data (big endian float, 0.0 - 1.0)
  b11     - 0x00

Pan: 3 quadlet message
  b00-b01 - heartbeat
  b02     - 0x66
  b03     - bus select (0x00-0x09)
  b04     - 0x02 (select pan control)
  b05     - channel select (0x02-0x09)
  b06     - 0x02
  b07-b10 - data (big endian float, -1.0 - 1.0)
  b11     - 0x00
  
Bus master fader: 3 quadlet message
  b00-b01 - heartbeat
  b02     - 0x66
  b03     - bus select (0x00-0x09)
  b04-b05 - 0x02-0x00 (select bus master control)
  b06     - 0x02
  b07-b10 - data (big endian float, 0.0 - 1.0)
  b11     - 0x00
  
Bus routing: 2 quadlet message
  b00-b01 - heartbeat
  b02     - 0x69
  b03     - output select (0x00-0x06, 0xff=disabled)
  b04     - bus select (0x00-0x07)
  b05-b07 - 0x00-0x00-0x02

Mute: 2 quadlet message
  b00-b01 - heartbeat
  b02     - 0x69
  b03     - state (0x00=disable, 0x01=enable)
  b04     - bus select (0x00-0x07)
  b05     - 0x00 (select mute control)
  b06     - channel select (0x01=bus master, 0x02-0x0b)
  b07     - 0x02

Channel solo: 2 quadlet message
  b00-b01 - heartbeat          
  b02     - 0x69
  b03     - state (0x00=disable, 0x01=enable)
  b04     - bus select (0x00-0x07)
  b05     - 0x01 (select solo control)
  b06     - channel select (0x01=bus master, 0x02-0x0b)
  b07     - 0x02


Controlling sample rate
-----------------------

Sample rate is mainly controlled by the clock control register (0x0b14)
although other registers do play a part.  It seems that the front panel
sample rate control is locked out by any write to the clock control
register; once locked it is only unlockable by power cycling the MOTU or by
unplugging it from the computer.


Device identification
---------------------

The ieee1394 vendor ID field currently seems to be set to 0x000001f2 to
signify MOTU.

The ieee1394 model ID is a little more interesting.  Originally it was
thought that 0x00101800 represented the 828MkII while 0x00104800 was the
Traveler.  However, following an update to Traveler firmware 1.07 the model
ID field changed to 0x00107800.  From this it appears that the model ID
field probably does not identify the MOTU model but rather communicates the
firmware version along with other information.  It appears that bits 19-12
of the model ID are a binary-coded decimal representation of the minor
firmware version number while at least bits 23-20 (and possibly 27-20) give
the major firmware version number.  Further datapoints will be needed to
verify these details, particularly the span of the major version number.
The meaning of bits 11-0 are currently unknown; they seem to equal 0x800
in all 828MkIIs and Travelers.

The ieee1394 GUID (globally unique ID) is preserved for a given unit
across firmware updates, but is unique to each particular unit.  Therefore
it cannot be used to unambiguously differentiate between different MOTU
interfaces.  However, the unit directory version entry does appear to be set
for particular models across firmware upgrades (0x00000003 for 828MkII,
0x00000009 for Traveler).  Therefore the best bet at this stage appears to be 
a probe for a vendor ID of 0x000001f2 with one of the above version values
in the unit directory of the config ROM.  Unit directory versions for MOTU
hardware are as follows:

  0x00000001 = The original 828
  0x00000003 = 828 Mk 2
  0x00000005 = 896HD
  0x00000009 = Traveler
  0x0000000d = Ultralite
  0x0000000f = 8pre
  0x00000015 = 828 Mk 3
  0x00000019 = Ultralite Mk 3
  0x0000001b = Traveler Mk 3
  0x00000030 = Ultralite Mk 3 hybrid

Alternatively one could probe for registers known to exist on only one of
the interfaces.  The trim gain / 20 dB pad status register (0x0c1c) for
example can be used to differentiate a Traveler from an 828Mk2 since these
features are only present on the Traveler.  At this stage however the unit
version number is probably sufficient and far less complicated in the long
run.


Firmware updates
----------------

A firmware update is initiated by powering the unit up in "update" mode by
turning on while the "cursor" button is held.  After verifying "update"
mode, registers 0x010000, 0x010004, 0x010008 and 0x01000c are read; with
firmware 1.04 loaded the values returned were 0x23ba58f, 0x86e5aa30,
0xe7fb2202 and 0x4b85130d.  These match exactly the first 16 data bytes of
firmware 1.07 as downloaded to the device, so it's thought that these first
4 quadlets contain some kind of magic number signature designed to confirm
that the device really is a MOTU, or (somewhat less likely) to perhaps
confirm that the MOTU is in update mode.

Next 0x4d4f5455 ("MOTU") is written to register 0x0c00; the new firmware is
then loaded by writing to sequential registers 0x010000 - 0x019ffc and
0x01c000 - 0x02fffc. At the end of writing, 0x00 is written to register
0x0c00.

Verification is by way of reading back the firmware registers from the
device.

The process of confirming that the device is in update mode is not yet fully
understood.  In terms of the startup sequence it appears that the only
difference between normal and update modes is that register 0x0400 is set to
0x410df42 in normal mode and 0x410f3a8 when in update mode.

The Travimage.bin firmware file provided by MOTU seems to comprise some kind
of header in bytes 0x00 - 0x17, with the actual firmware data starting at
byte 0x18.  The firmware is stored in network byte order (ie: big endian)
quadlets - precisely the same format used to send them to the MOTU device. 
The file also appears to include bytes 0x01a000 - 0x01bfff even though the
traveler updater doesn't appear to send this range to the MOTU device.
The firmware file for 1.07 seems to contain 0x020000 bytes of firmware data;
given that the firmware updater writes up to register 0x02fffc the updater
must infer data values of 0xff once the file ends.


Register map
------------

MOTU registers currently known.  The base address is 0xfffff0000000.

0x0b00 - Iso streaming control
0x0b04 - Device initialisation/discovery?
0x0b08 - Device initialisation/discovery?
0x0b10 - Optical port control?
0x0b14 - clock control register
0x0b1c - 896HD register possibly related to programmable meters
0x0b24 - 896HD programmable meter register (always probed during discovery/init)
0x0b28 - copy of model_id unit directory
0x0b2c - something related to selections in mixer application
0x0c00 - firmware programming control
0x0c04 - routing / port configuration
0x0c08 - input level (for analog channels 5-8 only)
0x0c0c - "Main out" volume control
0x0c10 - Phones volume control
0x0c14 - boost controls (for analog channels 5-8 only)
0x0c18 - something related to selections in mixer application
0x0c1c - gain trim / 20 dB pad controls (for analog channels 1-4 only)
0x0c20 - mix1 routing control
0x0c24 - mix2 routing control
0x0c28 - mix3 routing control
0x0c2c - mix4 routing control
0x0c60 - ASCII name of current clock source (characters 0-3)
0x0c64 - ASCII name of current clock source (characters 4-7)
0x0c68 - ASCII name of current clock source (characters 8-11)
0x0c6c - ASCII name of current clock source (characters 12-15)
0x0c70 - gain trim / phase invert (Ultralite only, analog channels 1-4)
0x0c74 - gain trim / phase invert (Ultralite only, analog channels 5-8)
0x0c78 - gain trim / phase invert (Ultralite only, SPDIF 1 and 2)
0x4000 - mix1 gain/pan/solo/mute, analog channel 1
0x4004 - mix1 gain/pan/solo/mute, analog channel 2
0x4008 - mix1 gain/pan/solo/mute, analog channel 3
0x400c - mix1 gain/pan/solo/mute, analog channel 4
0x4010 - mix1 gain/pan/solo/mute, analog channel 5
0x4014 - mix1 gain/pan/solo/mute, analog channel 6
0x4018 - mix1 gain/pan/solo/mute, analog channel 7
0x401c - mix1 gain/pan/solo/mute, analog channel 8
0x4020 - mix1 gain/pan/solo/mute, AES-EBU 1/L
0x4024 - mix1 gain/pan/solo/mute, AES-EBU 2/R
0x4028 - mix1 gain/pan/solo/mute, SPDIF 1/L
0x402c - mix1 gain/pan/solo/mute, SPDIF 2/R
0x4030 - mix1 gain/pan/solo/mute, ADAT channel 1
0x4034 - mix1 gain/pan/solo/mute, ADAT channel 2
0x4038 - mix1 gain/pan/solo/mute, ADAT channel 3
0x403c - mix1 gain/pan/solo/mute, ADAT channel 4
0x4040 - mix1 gain/pan/solo/mute, ADAT channel 5
0x4044 - mix1 gain/pan/solo/mute, ADAT channel 6
0x4048 - mix1 gain/pan/solo/mute, ADAT channel 7
0x404c - mix1 gain/pan/solo/mute, ADAT channel 8
0x4100
 :     - mix2 gain/pan/solo/mute, order as for mix1
0x414c
0x4200
 :     - mix3 gain/pan/solo/mute, order as for mix1
0x424c
0x4300
 :     - mix4 gain/pan/solo/mute, order as for mix1
0x434c

0x010000
 :     - firmware, block 1
0x019ffc

0x01c000
 :     - firmware, block 2
0x02fffc


Register details
----------------

0x0b00 - Iso streaming control

This register is primarily for the control of iso streaming.  It has been
observed to be set to one of two values: 0x80810000 or 0xc0c10000.  The
latter value appears to activate iso streaming while the former turns it
off.  On readback bits 31 and 23 are zero no matter whether the previously
written value was 0x80810000 or 0xc0c10000.  This suggests that these two
bits are effectively "write enable" for iso receive/send configuration on
the Motu, with bits 30/22 being "iso receive/send enable" (again as viewed
by the Motu).

Experiments indicate that bits 29-24 give the iso channel number the Motu
should expect data on (ie: the PC->Motu iso channel number) while bits 21-16
specify the iso channel the Motu should send its data on (ie: the Motu->PC
iso channel number).  This makes sense since there are 64 iso channels
available on the FireWire bus requiring 6 bits to specify.  If it is then
assumed that bits 15-0 are reserved we have the following layout for
this register.

  bit 31 = enable configuration change of PC->Motu iso streaming
  bit 30 = PC->Motu iso streaming enable
  bits 29-24 = PC->Motu iso channel
  bit 23 = enable configuration change of Motu->PC iso streaming
  bit 22 = Motu->PC iso streaming enable
  bits 21-16 = Motu->PC iso channel
  bits 15-0 = reserved, always 0


0x0b04 - Device initialisation/discovery?

This register seems to come into play only during device
discovery/initialisation.  The driver writes 0xffc20001 to this register
which is accepted by the MOTU.  The purpose of this is not known.


0x0b08 - Device initialisation/discovery?

This is another register which shows up only during device
discovery/initialisation.  A value of 0x00 is written to this register which
is accepted by the MOTU.  The purpose of this is not currently understood.


0x0b10 - Optical port control?

It is not yet clear what this register does.  It plays some part in
setting the mode of the optical ports (see also register c04).

Bit 7 is set to 1 by Cuemix console whenever the optical input port is set
to "off" or "TOSLink" and is 0 if set to "ADAT".

Bit 6 is set to 1 by Cuemix console whenever the optical output port is set
to "off" or "TOSLink" and is 0 if set to "ADAT".

Bit 1 seems to be set most if not all of the time in values written by
the Cuemix console.

Originally it was thought that bit 7 might control the availability of
the 8 ADAT inputs while bit 6 controlled the ADAT outputs.  However,
subsequent tests seemed to indicate that this was not the case - setting
these bits in isolation did not affect the hardware cuemix display in
any way.

When this register is read back its value appears to be 0x00001800 no matter
what the optical inputs are set up as.


0x0b14 - clock control register

This register is used in conjunction with others (like 0x0c0-0x0c6) to
control the sample clock.  Not all bits have been identified yet.  Any write
to this register seems to lock out the front panel sample rate control until
the MOTU is turned off or the MOTU is unplugged from the computer.

The details of the clock control register are summarised below.

  bits 31-29: unknown at present.  Seem to always be set to 0.

  bit 28: unknown at present.  For 896HD this seems to be set to 1 whenever
    the sample rate, sample rate conversion or clock mode is changed.  For other
    interfaces it appears to always be set to 0.

  bit 27: in 2x or 4x clock mode, this bit indicates whether word clock out
    should follow the system clock (bit 27 set to 1) or should be forced to
    the base rate (bit 27 set to 0).

  bits 26: purpose unknown at present.  Bit 26 appears to be set in every
    write to this register for the Traveler while for the Ultralite it is
    always 0.  Behaviour on other interfaces are unknown at present.
    On the Traveler, if bit 26 is set then bits 25-24 seem to control device
    muting in some way.

    Based on other systems we currently take bit 26 to be an "enable" bit
    for bits 25-24 on the Traveler.  For other interfaces we take it to
    always be zero.

  bits 25-24: related to device muting, although behaviour differs between
    devices and is dependent in some ways on bit 26.  Bits 26-24 are toggled
    at various staged of rate changes.  On the Traveler if bit 26 is set
    then the device is muted if both bits 25 and 24 are off.  Having either
    bit set seems enough to unmute the device, but other systems seem to set
    both on.  On the Ultralite the device is muted if both bits are off
    irrespective of the setting of bit 26.  The nature of the behaviour on
    other interfaces is yet to be determined.

    Based on other systems we'll assume bits 25-24 together control device
    muting: both off means device muted, both on means device unmuted, and
    other combinations (which seem to still unmute the device in practice)
    are unknown.

  bits 23-6: unknown at present.  All bits appear to always be set to zero.

  bit 9-8: Sample rate conversion setting (896HD only, always 0 on other
    interfaces):
      0 = off
      1 = AES/EBU in
      2 = AES/EBU out slave
      3 = AES/EBU out 2x

  bits 7-6: unknown at present.  Always observered to be 0.

  bit 5: 4x rate multiplier selector
    Enables the 4x clock multiplier (giving access to 176000 Hz and 192000 Hz
    rates)

  bit 4: 2x rate multiplier selector
    Enables the 2x clock multiplier (giving access to 88200 Hz and 96000 Hz
    rates)

  bit 3: Base rate selector:
           0 = 44100 Hz
           1 = 48000 Hz

  bits 2-0: clock source:
              0 = internal (and SMTPE if in the Audio console)
              1 = ADAT optical
              2 = (coaxial) SPDIF or (optical) TOSLink
              3 = SMTPE (set only by SMTPE console)
              4 = Word clock in
              5 = ADAT 9 pin
              6 = [ reserved? ]
              7 = AES-EBU

Note: when changing the rate multipliers additional work needs to be done
involving bits 11-8 of register 0x0c04 (routing/port configuration
register), bits 6 and 7 of 0x0b10 (optical control register) and other as
yet unidentified bits of 0x0b14.  While 0x0b10 and 0x0c04 are always
written, they only seem to change value only when moving to a 4x multiplier.
to ensure the ADAT/SPDIF optical port is disabled at 4x sample rates.

The rest of the details associated with these other registers are yet to be
deduced.  Note for instance that the 0x0b10 changes only appear to affect
ADAT controls - verified by observing that the same changes to 0x0b10 are
made when the optical ports are turned off in the Audio console program.

When the clock source is changed via this register, the textual name of the
source is always sent immediately afterward to 0x0c60-0x06c.  This is used
to report the current clock as selected by the PC on the LCD via the setup
menu.  See the description of these registers for more details.

SMTPE is interesting: its distinct value (3) is configured only if one
requests SMTPE as the clock source under the SMTPE console.  Selecting SMTPE
as the source in the Audio console appears to use the "internal" setting for
bits 0-3.


0x0b1c - 896HD register associated with programmable meters

The role of this register is currently unknown.  Whenever the programmable
meters are configured via register 0x0b24, 0x0400 is written to this register
after the write to register 0x0b24.


0x0b24 - 896HD programmable meter register

Register 0x0b24 doesn't exist in the MOTU Traveler/828Mk2 hardware, but a
read request is always sent to it twice during device
discovery/initialisation.  In response these interfaces return "type_error"
with data equal to 0x40000.  The precise purpose of this is not known but it
could be part of the device probing sequence.

Register 0xb24 does however exist on the 896HD and appears to control the
programmable meters:

  bits 31-14: Unknown at present.  Always observed to be set to 0.

  bits 13-11: Peak hold time:
                000 = off
                001 = 2 sec
                010 = 4 sec
                011 = 10 sec
                100 = 1 minute
                101 = 5 minutes
                110 = 8 minutes
                111 = infinite

  bits 10-8: Clip hold time:
                000 = off
                001 = 2 sec
                010 = 4 sec
                011 = 10 sec
                100 = 1 minute
                101 = 5 minutes
                110 = 8 minutes
                111 = infinite

  bits 7-3: Unknown at present.  Always observed to be set to 0.

  bit 2: AES/EBU meter source:
          0 = AES/EBU out
          1 = AES/EBU in

  bits 1-0: Programmable meter source:
              0 = Analog out
              1 = ADAT in
              2 = ADAT out


0x0b28 - copy of model_id unit directory

This register appears to be a copy of the model_id unit directory, normally
found in config ROM register 0x0434.  The presence and contents of this
register have only been verified on the 828MkII - the driver reads this
register when a 828MkII is connected but the Traveler initialisation
sequence does not appear to read it.


0x0b2c - something related to selections in mixer application

This register has something to do with destination of the selected mix bus
in the mixer application.  When a mix bus is selected, 0xbXX is written to
this register where XX is the output destination of the selected mix bus.
The interpretation of XX is the same as for the 0x0c20 register - see below.

The point of this is not currently known.

If "Cuemix input includes computer output" is selected in cuemix console:
  0xc01 is written to register 0x0b2c
  0x001 is written to register 0x0c18

When "Cuemix input includes computer output" is turned off in cuemix console:
  0xc00 is written to register 0x0b2c
  0x000 is written to register 0x0c18

When Cuemix console is started, 0xb00 is written to register 0x0b2c after
the rest of the startup sequence is complete; some time later a value
of 0x0b02 is written.  This sequence is possibly related to the mix
inherently selected when cuemix is started; as noted above, when a mix
is selected it does cause 0xb00 to be written to.

Register 0x0b2c appears to be read-only.


0x0c00 - firmware programming control

It appears that when the MOTU is in "update" mode this register is used
to enable writing to the device's firmware area (registers 0x010000 -
0x019ffc and 0x01c000 - 0x02fffc).  Writing 0x4d4f5455 ("MOTU") seems
to enable writes to the firmware while writing 0x00 is written when the
firmware update is complete.


0x0c04 - routing / port configuration

This register appears to have something to do with routing and port
configuration.  On some devices (the Ultralite for example) this register
must be initialised to something sensible before the device will accept
streaming enable commands via the streaming control register.

Bits 7-0 control the source for the phones output.  The numbers used are
the same as for the output destination of the mix routing control (0x0c20
etc) - see below for details.

Bits 9-8 specify the mode of the optical input port:
  00 = off, 01 = ADAT, 10 = TOSLink (numbers given are in binary)
The "TOSLink" option is not available on the 896HD.  Register 0xb10 also
plays a role in setting the optical input port mode.

Bits 11-10 specify the mode of the optical output port in the same way
as for the optical input port.  Again, register 0b10 seems to play a role
in setting the optical output port mode.

Bit 24 enables the setting of the phones source.  Bit 25 probably allows the
optical modes to be set.

Bits 31-26, 23-12 are unknown at present.  They seem to always be zero.


0x0c08 - input level (for analog channels 5-8 only)

This sets the input level for analog channels 5 to 8.  The default is
+4 dBU, but this register can be used to select -10 dBU if desired.

Only bits 4-7 appear to be significant in this register when setting input
level; all other bits are set to zero.

  bit 4: analog channel 5 input level
  bit 5: analog channel 6 input level
  bit 6: analog channel 7 input level
  bit 7: analog channel 8 input level

It seems likely that bits 0-3 are reserved for analog channels 1-4
respectively.

When a channel's bit is set (the default condition) an input level of +4 dBU
is assumed.  If the bit is zero it selects an input level of -10 dBU for
the respective channel.

A write to this register sets the input level for all channels.

The MOTU mixer application ties analog channels 5/6 and 7/8 together
(presumedly as a stereo pair) and activates the input level for the pair
whenever one channel is selected (even when the channels are not "paired"). 
However, it has been verified that the input level of channels can be
individually controlled though this register.


0x0c14 - boost controls (for analog channels 5-8 only)

Bits 4-7 of this register controls the activation of an additional 6dB of
gain for analog channels 5-8.  All other bits are set to zero.

  bit 4: analog channel 5 boost
  bit 5: analog channel 6 boost
  bit 6: analog channel 7 boost
  bit 7: analog channel 8 boost

Once again, bits 0-3 are probably reserved for analog channels 1-4 if they
were ever to acquire this functionality.

When a bit is zero (the default condition) the additional 6 dB boost is not
active.  When set to 1, the boost becomes active for the respective channel.

The boost status of all 4 channels is always updated by a write to this
register.


0x0c18 - something related to selections in mixer application

If "Cuemix input includes computer output" is selected:
  0xc01 is written to register 0x0b2c
  0x001 is written to register 0x0c18

When "Cuemix input includes computer output" is turned off:
  0xc00 is written to register 0x0b2c
  0x000 is written to register 0x0c18


0x0c0c - "Main out" volume control

Bits 7-0 of this register control the device's "main out" volume (0x80 = 0 dB, 
0x00 = -inf).  Bits 31-8 appear unused at present.


0x0c10 - phones volume control

Bits 7-0 of this register control the device's phones volume (0x80 = 0 dB, 
0x00 = -inf).  Bits 31-8 appear unused at present.


0x0c1c - gain trim / 20 dB pad controls (for analog channels 1-4 only)

This register controls the trim gain and 20 dB pad available on analog
channels 1-4.  Byte 0 (the least significant byte) controls analog channel
1.  Bytes 1-3 are for analog channels 2-4 respectively.

Bit 7 in each byte appears to always be set to 1.  The effect of setting
bit 7 to 0 is currently unknown.  On write, bit 7 may be a write-enable
control.

Bit 6 of a byte controls the 20 dB pad for the channel.  When bit 6 is set
(ie: equal to 1) the pad is engaged.  When bit 6 is zero the pad is switched
out.

Bits 0-5 set the gain trim value; 0 sets a gain of 0dB (the default) while
a value of 0x35 (53) sets the maximum gain of 53 dB.  The trim gain acts
in steps of 1 dB.

It seems the gain trim and pad settings of all channels can be set with a
single write to this register.  However, if a channel's byte is written as
zero its settings remain unchanged.


0x0c20, 0x0c24, 0x0c28, 0x0c2c - mix1, mix2, mix3 and mix4 routing controls

These registers control routing for the mix buses.  The format used by the
four mix buses is the same, so only 0x0c20 (mix1 routing control) is
explicitly discussed.

  bits 31-26: function currently unknown.  All bits seem to be set to 0.
  bit 25:     enable setting of mute status and destination.
  bit 24:     enable setting of fader.
  bits 23-16: function currently unknown.  All bits seem to be set to 0.
  bits 15-13: purpose unknown.  Seems to be set to 0.
  bit 12:     mute control.  0=unmute, 1=mute.
  bits 11-8:  output destination (see below).
  bits 7-0:   mix output fader.  0x80 = 0 dB, 0x00 = -inf

The output destination is defined as follows:

  0x0 = disabled
  0x1 = headphone output
  0x2 = analog 1-2
  0x3 = analog 3-4
  0x4 = analog 5-6
  0x5 = analog 7-8
  0x6 = AES-EBU (Main-out on 896HD)
  0x7 = SPDIF (AES-EBU on 896HD)
  0x8 = ADAT 1-2
  0x9 = ADAT 3-4
  0xa = ADAT 5-6
  0xb = ADAT 7-8

Note that it is not possible to set the mute and destination status
separately - they are both set when bit 25 is set.


0x0c60, 0x0c64, 0x0c68, 0x0c6c - ASCII name of current clock source

These registers appear to hold the ASCII name of the current clock source.
If the source name is less than 16 characters it is padded with spaces
(0x20).  The most significant byte of each register holds the leftmost
character of the group of 4 characters held by a that register.  For
example, if a register needs to hold the string "ABCD", the most significant
byte will be 65 ("A").

Currently defined strings are as follows.

  "Internal        " - internal clock source
  "SMPTE           " - SMPTE syncing
  "AES-EBU         " - use clock from AES-EBU
  "SPDIF           " - clock from (coaxial) SPDIF
  "TOSLink         " - clock from (optical) TOSLink
  "Word Clock In   " - use the word clock input
  "ADAT 9-pin      " - use the 9-pin ADAT interface for the clock
  "ADAT Optical    " - sync from ADAT optical interface

When a computer is connected to the MOTU the only way to set the clock
source is from the computer - the front panel controls for this are
disabled.  The string sent via these registers is used to display the name
of the clock source as selected by the computer.  If the clock source is
changed (via register 0x0b14) but nothing is downloaded using these
registers, the "current clock source" display on the LCD via the setup menu
will be blank.

One would have thought the Motu would be smart enough to provide the display
string by itself given that it seems to manage to set the string fine by
itself when there's no PC connected and the front panel is used to change
the clock source.


0x0c70 - gain trim / phase invert (Ultralite only, analog channels 1-4)

On the Ultralite, gain trim is controlled using a different register than
with the other MOTU devices.  This register controls gain trim and phase
inversion for analog channels 1-4.  Byte 0 (the least significant byte)
controls analog channel 1.  Bytes 1-3 are for analog channels 2-4
respectively.

Bit 7 in each byte appears to always be set to 1 when changing the
corresponding channel's setting.  It therefore seems that bit 7 is a
write-enable bit for the channel's setting.

Bit 6 of a byte controls the phase inversion setting.  When set (ie: equal
to 1) phase inversion is active.  When bit 6 is zero phase inversion is not
enagaged.

Bits 0-5 set the gain trim value; 0 sets a gain of 0dB (the default).  The
maximum gain available is determined by the type of channel.  For analog
channels 1-2 (the mic inputs), the maximum effective setting is 0x18 (24).
For analog channels 3-8 the maximum is 0x12 (18) while for SPDIF channels
the maximum is 0x0c (12).  The value written is in dB - thus each gain trim
control operates in steps of 1 dB.

Setting a channel's byte to zero causes its settings to remain unchanged. 
This allows any combination of the 4 channels to be changed without
interference to those not being changed.


0x0c74 - gain trim / phase invert (Ultralite only, analog channels 5-8)

This register operates as described for 0x0c70 except it controls analog
channes 5 to 8.  The least significant byte corresponds to analog channel 5.


0x0c78 - gain trim / phase invert (Ultralite only, SPDIF 1 and 2)

This register operates as described for 0x0c70 except it controls SPDIF 1
and SPDIF 2.  The least significant byte corresponds to SPDIF 1.  Bytes 2
and 3 are currently unused and should always be set to zero when writing to
this register.


0x4y00-0x4y4c (y=0-3) - gain/pan/solo/mute registers

These registers control the fader, pan, mute and solo settings for a given
input channel in each of the 4 mix buses.  y=0 is mix1, y=1 is mix2, y=2 is
mix3 and y=3 is mix4.

  Bit 31:     enable setting of pan
  Bit 30:     enable setting of gain
  Bit 29:     enable setting of bit 21
  Bit 28:     enable setting of bit 20
  Bit 27:     enable setting of pairing
  Bit 26:     enable setting of bit 18
  Bit 25:     enable setting of solo
  Bit 24:     enable setting of mute
  Bit 23:     seems to be unsettable; set to zero
  Bit 22:     seems to be unsettable; set to zero
  Bit 21:     can be set to 1 but no effect apparent
  Bit 20:     can be set to 1 but no effect apparent
  Bit 19:     activate pairing
  Bit 18:     can be set to 1 but no effect apparent
  Bit 17:     channel solo.  0=solo off, 1=solo on.
  Bit 16:     channel mute.  0=unmuted, 1=muted.
  Bits 15-8:  pan.  0x40=0 (centre), 0x80=+64 (right), 0x00=-64 (left)
  Bits 7-0:   gain.  0x00 = -inf, 0x80 = 0 dB.

When reading these registers in normal operation, bits 31-27 and bits 23-18
seem to be all zero while bits 26-24 are all 1.  The Cuemix console however
appears to set bits 31-30 and zero bits 29-18.  In other words, a typical
read-back value might be 0x0700406a while to actually set the mixer to this
one would need to use a value of 0xc300406a.  It seems likely that at least
some of the bits have different meanings when read and written; for instance
there doesn't seem to be much point in bits 24-26 being set on readback
given the above definitions, but they are.

If channel pairing is to be activated it must be set in both channels which
form a stereo pair.  However, paired channels are still controlled
individually by the mixer registers - for example, if channels 1 and 2 are
paired it is still possible to raise channel 1's volume in mix1 by writing 
only to register 0x4000.  In other words, the device does not enforce linked
controls when channels are paired.  The "paired" flag is really just a hint
to the mixer at the end of the day.


Gain and pan value-dB mappings for the Traveler
===============================================

The following gain map runs from 0x00 (-inf) to 0x80 (0 dB).  The dB values
were taken directly off the Cuemix console application.

Gain steps (dB): -inf, -84, -72, -65, -60, -56, -53, -50, -48, -46, -44, 
  -43, -41, -39.7, -38.4, -37.2, -36.1, -35.1, -34.1, -33.1, -32.2, -31.4,
  -30.6, -29.8, -29.1, -28.4, -27.7, -27.0, -26.4, -25.8, -25.2, -24.6, 
  -24.1, -23.5, -23.0, -22.5, -22.0, -21.5, -21.1, -20.6, -20.2, -19.8,
  -19.4, -19.0, -18.6, -18.2, -17.8, -17.4, -17.0, -16.7, -16.3, -16.0,
  -15.6, -15.3, -15.0, -14.7, -14.4, -14.1, -13.8, -13.5, -13.2, -12.9,
  -12.6, -12.3, -12.0, -11.8, -11.5, -11.2, -11.0, -10.7, -10.5, -10.2,
  -10.0, -9.8, -9.6, -9.3, -9.1, -8.8, -8.6, -8.4, -8.2, -7.9, -7.7, -7.5,
  -7.3, -7.1, -6.9, -6.7, -6.5, -6.3, -6.1, -5.9, -5.7, -5.5, -5.4, -5.2,
  -5.0, -4.8, -4.6, -4.5, -4.3, -4.1, -3.9, -3.7, -3.6, -3.4, -3.3, -3.1,
  -3.0, -2.8, -2,6, -2.5, -2.3, -2.2, -2.0, -1.9, -1.7, -1.6, -1.4, -1.3,
  -1.1, -1.0, -0.8, -0.7, -0.6, -0.4, -0.3, -0.1, 0.0

Pan: (approximate findings)
  full pan on: +3 dB gain
  0: 0 dB
  20/64 pan off: -3 dB
  40/64 pan off: -6 dB
  55/64 pan off: -15 dB
  59/64 pan off: -24 dB
  full pan off: -inf gain

Pan dB map.  This table runs from value 0 (pan full left) to 0x80 (pan
full right).  The gain values are for a left channel signal.
  2.505, 2.505, 2.505, 2.499, 2.499, 2.492, 2.486, 2.479, 2.473, 2.460,
  2.453, 2.440, 2.427, 2.414, 2.400, 2.387, 2.367, 2.347, 2.331, 2.308,
  2.288, 2.267, 2.241, 2.220, 2.194, 2.166, 2.139, 2.105, 2.078, 2.044,
  2.016, 1.982, 1.940, 1.905, 1.870, 1.828, 1.786, 1.743, 1.700, 1.657,
  1.607, 1.563, 1.512, 1.461, 1.409, 1.358, 1.298, 1.245, 1.185, 1.124,
  1.063, 1.001, 0.931, 0.868, 0.797, 0.725, 0.653, 0.580, 0.507, 0.424,
  0.341, 0.265, 0.257, 0.087, 0.000,
  -0.087, -0.176, -0.274, -0.373, -0.473, -0.584, -0.687, -0.801, -0.916,
  -1.033, -1.151, -1.271, -1.403, -1.526, -1.662, -1.800, -1.940, -2.083,
  -2.239, -2.386, -2.548, -2.713, -2.881, -3.058, -3.240, -3.437, -3.614,
  -3.814, -4.018, -4.228, -4.457, -4.678, -4.920, -5.168, -5.489, -5.688,
  -5.969, -6.259, -6.568, -6.889, -7.222, -7.568, -7.928, -8.327, -8.722,
  -9.160, -9.621, -10.108, -10.624, -11.205, -11.810, -12.460, -13.182,
  -13.971, -14.886, -15.855, -16.976, -18.264, -19.819, -21.715, -24.143,
  -27.526, -33.143, -inf

dB factors for values of 0, 1 and 2 are all 2.505 dB while those for pan
values of 3 and 4 are both 0.499.  This is because the voltage variation
across each of these groups of values was below the resolution of the meter
used to measure the voltages (0.001 Vrms).  One can probably safely assume
that the actual variation across these groups is approximately linear, so
"corrected" dB values for the first 5 pan values can probably be taken to be
  2.508, 2.505, 2.504, 2.501, 2.499

The pan map was measured by injecting a 0.992 Vrms sine wave at 308 Hz into
analog1 input channel of the Motu.  Channel 1's -20 dB pad was switched in
to avoid overloading the preamp and a gain trim of +11 dB was used. This
combination resulted in a signal of 0.999 Vrms being emitted from analog1
output with the analog1's fader set to 0 dB.

The output RMS voltage was then measured for each setting of the pan
control.  Resolution of these measurements was 0.001 Vrms.  The dB gain
value was calculated relative to the centre pan position using

  dB = 20log10(V/ref)

where ref was the voltage measured with the pan control set to the centre
(ie: a pan value of 0x40).

A frequency of approximately 300 Hz was chosen since this was firmly within
the flat response region of the multimeter used for measuring the voltage.
If the frequency drifted slightly the frequency response of the meter would
therefore not artificially change the voltage measurement.

The input signal was generated using a precision audio signal generator. 
The amplitude is tightly regulated and did not change for the duration of
these tests.

The meter used was not able to measure voltages below 0.004 Vrms.  This was
a limitation of the meter - it was not an additive offset which affected
voltage measurements.

Putting all this together it is expected that the dB values for the pan map
are accurate to at least 1 decimal place.