root/trunk/libffado/doc/motu_firewire_protocol.txt

Revision 1085, 41.9 kB (checked in by jwoithe, 15 years ago)

MOTU: Name channel pair control widgets in mixer. Disable channel pair widgets for the moment since they are not implemented.
MOTU: In mixer python glue code, renamed pan object handlers to generic control handlers since they can be used for more than just the pan controls.
Fix minor grammar issues in registration dialog.
In registration module, ensure the ffado configuration directory exists before trying to save information into it. The test is still a bit rough and could be made more robust.
ffadomixer: explicitly set the size of the toplevel tab widget to that of the mixer it contains. Without this for me on Qt 3.3.8 the ffado mixer window is created way too small. The solution is a bit hacky and could possibly do with refinement.
ffadomixer: don't include the generic mixer controls for MOTU devices since they don't give us anything useful yet and could be a source of confusion for users.

Line 
1 Notes on the firewire protocol used by MOTU audio devices
2 =========================================================
3
4 Author: Jonathan Woithe
5 Document version: 20080501-1
6
7
8 Audio/MIDI data
9 ---------------
10
11 Audio data is sent via iso packets.  With nothing else present on the
12 firewire bus Iso channel 0 is used by the PC to send data to the MOTU while
13 iso channel 1 is used by the MOTU to send data to the PC.  The channels
14 used can be arbitarily chosen by software subject to availability as
15 indicated by the Isochronous Resource Manager (IRM).
16
17 The MOTU appears to utilise some ideas from IEC 61883-6.  For example, each
18 iso packet seems to include a CIP header (the iso packet header has the tag
19 field set to 0x01 to indicate the presence of the CIP).  However, the
20 standard is not followed completely to the finest detail.  Typical CIP
21 header values from the Traveler for audio data packets at a 44.1 kHz rate
22 with SPDIF enabled and the optical I/O ports set to ADAT mode are as
23 follows:
24
25   SID = 0x02    dependent on bus topography
26   DBS = 0x13    expressed in quadlets
27   FN  = 0       as expected from IEC 61883-6
28   QPC = 0       as expected from IEC 61883-6
29   SPH = 1       indicating a source packet header is included.  IEC 61883-6
30                 expects SPH to be 0 for A/V transport.
31   Rsv = 0
32   DBC = yyy     Data block count varies from packet to packet
33   FMT = 0x02    IEC 61883-6 expects this to be 0x10 for A/V data.  MOTU
34                 seem to be using 0x02 for their own purposes.
35   FDF = 0x22    This means the data is 32 bit floating point according to
36                 IEC 61883-6.  The data isn't 32 bit floating point, so MOTU
37                 obviously use this field to mean their own thing.
38   SYT = 0xffff  IEC 61883-6 says this field is the time the event is to be
39                 presented to the receiver.  Clearly this isn't used by MOTU.
40
41 The FDF field is interesting in that when interpreted as per IEC 61883-6, it
42 doesn't reflect the reality of the audio stream used by the Traveler (see
43 below).  One has to assume that MOTU have redefined this for their own
44 purposes.
45
46 The DBC field is incremented from packet to packet by the number of
47 data blocks contained in the packet.  At 1x rates there are nominally 8
48 data blocks per packet, so DBC increments by 8 between successive iso data
49 packets.
50
51 The DBS (Data Block Size) varies according to the sampling rate in use. At
52 1x rates (44.1 kHz, 48 kHz) it is 0x13.  At 2x rates it reduces to 0x10
53 while at 4x rates it decreases again to 0x09.  Similarly the iso data length
54 differs according to the sampling rate: 0x268 at 1x rates (giving 8 blocks
55 per iso data packet), 0x408 at 2x rates (giving 16 blocks per iso data
56 packet) and 0x488 at 4x rates (giving 32 blocks per iso data packet).
57
58 The Traveler usually becomes the IRM on the firewire bus it is plugged into;
59 when functioning as the IRM it also broadcasts "cycle start" packets on a
60 regular basis as would be expected. These appear to be as per ieee1394-1995.
61 These broadcast a quadlet in the same form as the Traveler's cycle time
62 register with a value equal to the cycle time register at the time the
63 packet was submitted for transmittsion.  The format of this register is as
64 follows:
65
66   bits 31-25 = seconds count (0-127)
67   bits 24-12 = cycle count (0-7999)
68   bits 11-0  = cycle offset (0-3071)
69
70 Each portion of the register wraps to 0 at the end of the range, causing
71 the next most significant component to be incremented by one.  When the
72 "seconds count" overflows it simply wraps to 0 without incrementing
73 anything.  The cycle offset is incremented by a 24.576 MHz clock.
74 The cycle count can be thought of as the fractional part of the current
75 second in units of 125 us.
76
77 The data portion of a typical iso packet to/from the Traveler contains a CIP
78 header and 8, 16 or 32 data blocks (depending on sampling rate) of size DBS
79 quadlets (DBS*4 bytes).  Empty packets are utilised periodically to maintain
80 the long-term average equal to the sampling interval.  For example, at 48
81 kHz, 3 packets with 8 datablocks are sent, followed by a single empty
82 packet.
83
84 The format of each data block varies according to whether a 1x, 2x or 4x
85 clock multiplier is in use.  At 44.1 kHz or 48 kHz (ie: a 1x clock), each
86 data block contains the following in this order:
87
88   32 bit Source Packet Header (SPH) (+)
89   48 bits of control/MIDI data (&)
90   24 bit audio values: headphone L&R / mix1 L&R (*)
91   24 bit audio values: analog channels 1-8
92   24 bit audio values: AES-EBU L and R
93   24 bit audio values: SPDIF L and R
94   24 bit audio values: ADAT channels 1-8
95
96 At 2x clock frequencies (88.2 kHz and 96 kHz) the ADAT channels 5-8 are
97 dropped from the datablock, leaving the following arrangement:
98
99   32 bit Source Packet Header (SPH) (+)
100   48 bits of control/MIDI data (&)
101   24 bit audio values: headphone L&R / mix1 L&R (*)
102   24 bit audio values: analog channels 1-8
103   24 bit audio values: AES-EBU L and R
104   24 bit audio values: SPDIF L and R
105   24 bit audio values: ADAT channels 1-4
106
107 At 4x clock frequencies (176.4 k kHz and 192 kHz) all digital I/O is disabled
108 along with the separate headphone / mix1 bus.  The resulting datablock
109 is formatted as follows.
110
111   32 bit Source Packet Header (SPH) (+)
112   48 bits of control/MIDI, MSB first (&)
113   24 bit audio values: analog channels 1-8
114   16 bits of padding (%)
115
116 Notes:
117  (+) The SPH is defined in IEC 61883-6:
118        Bits 31-25 = reserved
119        Bits 24-12 = cycle count (0-7999)
120        Bits 11-0  = cycle offset (0-3071)
121  (&) These values have been observed to be almost always 0 in packets sent
122      by the PC except when MIDI is sent, but for packets sent by the MOTU
123      they are generally non-zero.  See below for more details on these
124      bytes.
125  (*) Packets from the traveler send mix1 data here; packets from the PC
126      send data for the headphone channel here.
127  (%) It appears the Motu pads data in a cycle using values of either 0x0000
128      or 0xffff.  It appears to use a regular pattern, although the pattern
129      itself appears variable.  Two patterns have been observed so far:
130        * two blocks of 0xffff followed by two blocks of 0x0000.
131        * a block of 0xffff followed by three blocks of 0xffff.
132     The PC driver always appears to send pad values of 0x0000.
133
134 If the optical ports have been set to TOSLINK rather than ADAT, the data
135 sent in the iso datablocks is adjusted accordingly - the 8 (or 4) ADAT
136 channels and 2 coax SPDIF channels are omitted and the 2 optical TOSLINK
137 channels are sent in their place.
138
139 For packets from the PC to the MOTU, the timestamp given in the SPH probably
140 represents the cycle time at which the data given should be output by the
141 interface.  For packets coming from the MOTU to the PC this timestamp is
142 most likely the cycle time at which the data was sampled by the interface.
143
144 The cycle offset increment used for each successive datablock varies
145 according to the sampling frequency as one would expect.  While the
146 increment value is "mostly constant" it does vary by +/-1 at times.  This
147 would be to keep the data in sync with the audio sampling frequency in use,
148 as some audio sampling frequencies - those which are multiples of 44.1 kHz -
149 are not integral factors of the cycle offset frequency (and even those which
150 are sometimes deviate from the theoretical increment by 1).  The increments
151 seen in data coming from the Motu are generally a lot more consistent than
152 those coming from the PC.
153
154 The 48 bits Control/MIDI data appears to play a part in MIDI data
155 transmission.  When the PC is transmitting a MIDI stream to the Motu it does
156 so byte by byte.  A byte of midi data is sent using the first and third bytes
157 following a data block's SPH, forming a midi subpacket for want of a better
158 description.  The format of the midi subpacket appears to be
159
160   0x0100nn
161
162 where nn is the MIDI byte being sent.  Having more than one MIDI subpacket
163 in a single transmitted iso data packet has never been observed; it seems
164 therefore that on this interface the timing of the MIDI subpackets is to
165 match exactly their transmission onto the wire.  Furthermore, sending data
166 to the MOTU at a rate faster then the hardware midi rate of 3125 bytes per
167 second (31250 baud with 8 bit data, 1 start bit and 1 stop bit) will cause
168 MIDI bytes to be dropped or corrupted in interesting ways.
169
170 For data coming from the Motu it appears that these 48 Control/MIDI bits are
171 used for a number of purposes, although some of the details are yet to be
172 worked out.  However, it appears that MIDI data is intermingled with this.
173 At this stage it seems that when bit 40 is set then bits 24-31 contain a
174 MIDI byte.  The contents of bits 41-47 and 32-39 do not appear to be
175 affected by having bit 40 set, so at this stage one concludes that their
176 function (mostly related to Cuemix setting updates) continues even when MIDI
177 data is sent.  Obviously any other function of bits 24-31 is interrupted when
178 these bits are required for a MIDI byte.
179
180 Putting all this together, bit 40 appears to be a "MIDI byte present" bit;
181 if set, bits 24-31 contain a MIDI byte.  All other bits of the Control/MIDI
182 fields continue to function even when bit 40 is set.  If this definition is
183 adopted it applies equally well to both incoming and outgoing MIDI data.
184
185 It should be noted that the Traveler has never been observed to send more
186 than one MIDI data byte per iso packet.  Presumedly therefore the timing of
187 the bytes delivered by the Traveler is very close to the timing on the MIDI
188 wire.  However, other MOTU devices (the 828Mk2 for example) do transmit more
189 than one MIDI byte in a single packet.  On these devices MIDI messages must
190 be buffered in the device and sent in a burst once a complete message has
191 been received.
192
193
194 SMPTE timecode
195 --------------
196 It appears that the traveler itself has no way to generate SMPTE timecode
197 internally.  The SMTPE console application allows one to generate timecode,
198 but the timecode stops as soon as this application is exitted.
199
200 In addition, changing any of the settings in the SMPTE console does not
201 appear to change any hardware settings in the MOTU with the exception of the
202 "clock/address" control - this changes the source in a similar way to that
203 in the main MOTU setup program.  The obvious conclusion here is that SMTPE
204 generation appears to be a feature implemented in the host software.
205
206
207 Talkback/listenback
208 -------------------
209 These features of the Cuemix console appear to be implemented in the host
210 software.  Enabling either of these appears to simply set the mixer
211 registers to suit talkback/listenback, with the "normal" settings
212 restored when talkback/listenback is disengaged.  The motu itself does not
213 appear to have any explicit on-board support of these modes.
214
215
216 Bus renaming in Cuemix console
217 ------------------------------
218 The naming of the 4 mix buses provided by the Cuemix console seems to be
219 internal to the Cuemix console application.  Changing the mix names results
220 in no traffic being sent to/from the motu.
221
222
223 MIDI in/out
224 -----------
225 MIDI data is sent within the first 48 bytes of the data blocks within an
226 iso data packet.  This is described in detail in the "Audio/MIDI data"
227 section.
228
229
230 Controlling Cuemix
231 ------------------
232 It has been noted that some mixer settings (particularly registers 0x4yyy)
233 have been found to utilise "write enable" bits which when set allow their
234 associated part of the control register to be acted upon.  There is no
235 reason to think that the 0x4yyy registers are unique here; it's likely that
236 other control registers implement a similar idea.  It is thought that
237 whenever bits are seemingly set to 1 by the Cuemix console there is a stong
238 possibility they form some kind of enable mask.  When such values are noted
239 in the register description it is likely that they must be supplied as noted
240 if the desired register change is to be successful.  In time it is hoped that
241 the function of these magic settings can be deduced.
242
243 Finally, when manually changing Cuemix settings on the Motu's front panel,
244 the Cuemix console is observed to update its display accordingly.  The data
245 for these updates comes via a byte stream transmitted by the Motu using a
246 key/value system in the first two bytes of each data block in the iso
247 stream.  Within a given data block, bits 7-1 of the first byte is the key
248 while the second byte gives the respective value.  Recall that bit 0 of the
249 first byte is a "MIDI byte present" flag, indicating that the third byte in
250 the data block contains a MIDI data byte - refer to the "Audio/MIDI data"
251 section for more details.
252
253 The following describes all keys observed so far from the Traveler.  Note
254 that the key values reported here are for bits 7-0 of the first byte with
255 bit 0 (the MIDI present bit) masked to zero.
256
257   0x04 = Some kind of timer/counter.  Details not yet identified.
258   0x0c = Mix bus sync key.  The mix bus to which the next mix bus
259          parameter(s) apply to is given by bits 7-5 in the data byte.
260   0x14 = channel gain value (0x00-0x80)
261   0x1c = channel pan value (0x00-0x80, 0x40=centre)
262   0x24 = channel control: 0x01=mute, 0x02=solo, 0x08=paired
263   0x2c = mix bus gain (0x00-0x80)
264   0x34 = mix bus destination/mute.  Bits 3-0 are as per "output destination"
265          in register 0x0c20; bit 4 is the mute bit.
266   0x3c = main out volume (0x00-0x80)
267   0x44 = phones volume (0x00-0x80)
268   0x4c = phones assign (values as per "output destination" in register 0x0c20)
269   0x54 = at 48 kHz remains fixed at 0x00.  Purpose unknown.
270   0x64 = at 48 kHz remains fixed at 0x00.  Purpose unknown.
271   0x6c = +6 dB boost (analog channels 5-8 only).  Bits 4-7 = channels 5-8.
272   0x74 = ref level.  Bits 4-7 = channels 5-8.  Bit set/clear = +4/-10.
273   0xfc = Some kind of timer/counter.  Details not yet identified.
274
275 For many of these keys there are multiple values to communicate; for
276 example, for key 0x14 (channel gain) there are up to 20 values for each of 4
277 mix buses, corresponding to the 20 input channels available (analog 1-8,
278 SPDIF, AES/EDU, ADAT 1-8).  In such situations the multiple values for a
279 given mix bus are transmitted sequentially (each having the same key)
280 following a mix bus sync key which gives the mix bus to which the values
281 apply.
282
283 In the case of the Traveler the following sequence of keys is used.
284 Timing/counter events have been omitted from this sequence.  N is the number
285 of channels active.
286
287   Mix bus sync key
288   N channel gain keys
289   Mix bus sync key
290   N channel pan keys
291   Mix bus sync key
292   N channel control keys
293   Mix bus sync key
294   Mix bus gain key
295   Mix bus destination key
296   Main out volume key
297   Phones volume key
298   Phones destination key
299   Input 6dB boost key
300   Input reference level key
301
302 The device-wide keys are therefore seen 4 times as often as the per-mixbus
303 keys.
304
305 Curiously enough, the gain trim and pad settings for analog channels 1-4
306 use a different method to communicate their changed status; for these
307 settings the Motu writes to a specific address on the PC and in
308 response the PC reads a register from the Motu.  When a channel's gain trim
309 or pad setting is altered:
310  * Motu sends 0x20ffffff to address offset 0x100000000 on the PC
311  * In response the PC reads register 0x0c1c from the Motu to obtain the new
312    gain trim value and pad setting.
313
314
315 Controlling sample rate
316 -----------------------
317
318 Sample rate is mainly controlled by the clock control register (0x0b14)
319 although other registers do play a part.  It seems that the front panel
320 sample rate control is locked out by any write to the clock control
321 register; once locked it is only unlockable by power cycling the MOTU or by
322 unplugging it from the computer.
323
324
325 Device identification
326 ---------------------
327
328 The ieee1394 vendor ID field currently seems to be set to 0x000001f2 to
329 signify MOTU.
330
331 The ieee1394 model ID is a little more interesting.  Originally it was
332 thought that 0x00101800 represented the 828MkII while 0x00104800 was the
333 Traveler.  However, following an update to Traveler firmware 1.07 the model
334 ID field changed to 0x00107800.  From this it appears that the model ID
335 field probably does not identify the MOTU model but rather communicates the
336 firmware version along with other information.  It appears that bits 19-12
337 of the model ID are a binary-coded decimal representation of the minor
338 firmware version number while at least bits 23-20 (and possibly 27-20) give
339 the major firmware version number.  Further datapoints will be needed to
340 verify these details, particularly the span of the major version number.
341 The meaning of bits 11-0 are currently unknown; they seem to equal 0x800
342 in all 828MkIIs and Travelers.
343
344 The ieee1394 GUID (globally unique ID) is preserved for a given unit
345 across firmware updates, but is unique to each particular unit.  Therefore
346 it cannot be used to unambiguously differentiate between different MOTU
347 interfaces.  However, the unit directory version entry does appear to be set
348 for particular models across firmware upgrades (0x00000003 for 828MkII,
349 0x00000009 for Traveler).  Therefore the best bet at this stage appears to be
350 a probe for a vendor ID of 0x000001f2 with one of the above version values
351 in the unit directory of the config ROM.  Unit directory versions for MOTU
352 hardware are as follows:
353
354   0x00000001 = The original 828
355   0x00000003 = 828 Mk 2
356   0x00000005 = 896HD
357   0x00000009 = Traveler
358   0x0000000d = Ultralite
359   0x0000000f = 8pre
360
361 Alternatively one could probe for registers known to exist on only one of
362 the interfaces.  The trim gain / 20 dB pad status register (0x0c1c) for
363 example can be used to differentiate a Traveler from an 828Mk2 since these
364 features are only present on the Traveler.  At this stage however the unit
365 version number is probably sufficient and far less complicated in the long
366 run.
367
368
369 Firmware updates
370 ----------------
371
372 A firmware update is initiated by powering the unit up in "update" mode by
373 turning on while the "cursor" button is held.  After verifying "update"
374 mode, registers 0x010000, 0x010004, 0x010008 and 0x01000c are read; with
375 firmware 1.04 loaded the values returned were 0x23ba58f, 0x86e5aa30,
376 0xe7fb2202 and 0x4b85130d.  These match exactly the first 16 data bytes of
377 firmware 1.07 as downloaded to the device, so it's thought that these first
378 4 quadlets contain some kind of magic number signature designed to confirm
379 that the device really is a MOTU, or (somewhat less likely) to perhaps
380 confirm that the MOTU is in update mode.
381
382 Next 0x4d4f5455 ("MOTU") is written to register 0x0c00; the new firmware is
383 then loaded by writing to sequential registers 0x010000 - 0x019ffc and
384 0x01c000 - 0x02fffc. At the end of writing, 0x00 is written to register
385 0x0c00.
386
387 Verification is by way of reading back the firmware registers from the
388 device.
389
390 The process of confirming that the device is in update mode is not yet fully
391 understood.  In terms of the startup sequence it appears that the only
392 difference between normal and update modes is that register 0x0400 is set to
393 0x410df42 in normal mode and 0x410f3a8 when in update mode.
394
395 The Travimage.bin firmware file provided by MOTU seems to comprise some kind
396 of header in bytes 0x00 - 0x17, with the actual firmware data starting at
397 byte 0x18.  The firmware is stored in network byte order (ie: big endian)
398 quadlets - precisely the same format used to send them to the MOTU device.
399 The file also appears to include bytes 0x01a000 - 0x01bfff even though the
400 traveler updater doesn't appear to send this range to the MOTU device.
401 The firmware file for 1.07 seems to contain 0x020000 bytes of firmware data;
402 given that the firmware updater writes up to register 0x02fffc the updater
403 must infer data values of 0xff once the file ends.
404
405
406 Register map
407 ------------
408
409 MOTU registers currently known.  The base address is 0xfffff0000000.
410
411 0x0b00 - Iso streaming control
412 0x0b04 - Device initialisation/discovery?
413 0x0b08 - Device initialisation/discovery?
414 0x0b10 - Optical port control?
415 0x0b14 - clock control register
416 0x0b24 - non-existent register probed during discovery/initialisation
417 0x0b28 - copy of model_id unit directory
418 0x0b2c - something related to selections in mixer application
419 0x0c00 - firmware programming control
420 0x0c04 - routing / port configuration
421 0x0c08 - input level (for analog channels 5-8 only)
422 0x0c14 - boost controls (for analog channels 5-8 only)
423 0x0c18 - something related to selections in mixer application
424 0x0c1c - gain trim / 20 dB pad controls (for analog channels 1-4 only)
425 0x0c20 - mix1 routing control
426 0x0c24 - mix2 routing control
427 0x0c28 - mix3 routing control
428 0x0c2c - mix4 routing control
429 0x0c60 - ASCII name of current clock source (characters 0-3)
430 0x0c64 - ASCII name of current clock source (characters 4-7)
431 0x0c68 - ASCII name of current clock source (characters 8-11)
432 0x0c6c - ASCII name of current clock source (characters 12-15)
433 0x4000 - mix1 gain/pan/solo/mute, analog channel 1
434 0x4004 - mix1 gain/pan/solo/mute, analog channel 2
435 0x4008 - mix1 gain/pan/solo/mute, analog channel 3
436 0x400c - mix1 gain/pan/solo/mute, analog channel 4
437 0x4010 - mix1 gain/pan/solo/mute, analog channel 5
438 0x4014 - mix1 gain/pan/solo/mute, analog channel 6
439 0x4018 - mix1 gain/pan/solo/mute, analog channel 7
440 0x401c - mix1 gain/pan/solo/mute, analog channel 8
441 0x4020 - mix1 gain/pan/solo/mute, AES-EBU 1/L
442 0x4024 - mix1 gain/pan/solo/mute, AES-EBU 2/R
443 0x4028 - mix1 gain/pan/solo/mute, SPDIF 1/L
444 0x402c - mix1 gain/pan/solo/mute, SPDIF 2/R
445 0x4030 - mix1 gain/pan/solo/mute, ADAT channel 1
446 0x4034 - mix1 gain/pan/solo/mute, ADAT channel 2
447 0x4038 - mix1 gain/pan/solo/mute, ADAT channel 3
448 0x403c - mix1 gain/pan/solo/mute, ADAT channel 4
449 0x4040 - mix1 gain/pan/solo/mute, ADAT channel 5
450 0x4044 - mix1 gain/pan/solo/mute, ADAT channel 6
451 0x4048 - mix1 gain/pan/solo/mute, ADAT channel 7
452 0x404c - mix1 gain/pan/solo/mute, ADAT channel 8
453 0x4100
454  :     - mix2 gain/pan/solo/mute, order as for mix1
455 0x414c
456 0x4200
457  :     - mix3 gain/pan/solo/mute, order as for mix1
458 0x424c
459 0x4300
460  :     - mix4 gain/pan/solo/mute, order as for mix1
461 0x434c
462
463 0x010000
464  :     - firmware, block 1
465 0x019ffc
466
467 0x01c000
468  :     - firmware, block 2
469 0x02fffc
470
471
472 Register details
473 ----------------
474
475 0x0b00 - Iso streaming control
476
477 This register is primarily for the control of iso streaming.  It has been
478 observed to be set to one of two values: 0x80810000 or 0xc0c10000.  The
479 latter value appears to activate ISO streaming while the former turns it
480 off.  On readback bits 31 and 23 are zero no matter whether the previously
481 written value was 0x80810000 or 0xc0c10000.  This suggests that these two
482 bits are effectively "write enable" for iso receive/send configuration on
483 the Motu, with bits 30/22 being "iso receive/send enable" (again as viewed
484 by the Motu).
485
486 Experiments indicate that bits 29-24 give the iso channel number the Motu
487 should expect data on (ie: the PC->Motu iso channel number) while bits 21-16
488 specify the iso channel the Motu should send its data on (ie: the Motu->PC
489 iso channel number).  This makes sense since there are 64 iso channels
490 available on the firewire bus requiring 6 bits to specify.  If it is then
491 assumed that bits 15-0 are reserved we have the following layout for
492 this register.
493
494   bit 31 = enable configuration change of PC->Motu iso streaming
495   bit 30 = PC->Motu iso streaming enable
496   bits 29-24 = PC->Motu iso channel
497   bit 23 = enable configuration change of Motu->PC iso streaming
498   bit 22 = Motu->PC iso streaming enable
499   bits 21-16 = Motu->PC iso channel
500   bits 15-0 = reserved, always 0
501
502
503 0x0b04 - Device initialisation/discovery?
504
505 This register seems to come into play only during device
506 discovery/initialisation.  The driver writes 0xffc20001 to this register
507 which is accepted by the MOTU.  The purpose of this is not known.
508
509
510 0x0b08 - Device initialisation/discovery?
511
512 This is another register which shows up only during device
513 discovery/initialisation.  A value of 0x00 is written to this register which
514 is accepted by the MOTU.  The purpose of this is not currently understood.
515
516
517 0x0b10 - Optical port control?
518
519 It is not yet clear what this register does.  It plays some part in
520 setting the mode of the optical ports (see also register c04).
521
522 Bit 7 is set to 1 by Cuemix console whenever the optical input port is set
523 to "off" or "TOSLink" and is 0 if set to "ADAT".
524
525 Bit 6 is set to 1 by Cuemix console whenever the optical output port is set
526 to "off" or "TOSLink" and is 0 if set to "ADAT".
527
528 Bit 1 seems to be set most if not all of the time in values written by
529 the Cuemix console.
530
531 Originally it was thought that bit 7 might control the availability of
532 the 8 ADAT inputs while bit 6 controlled the ADAT outputs.  However,
533 subsequent tests seemed to indicate that this was not the case - setting
534 these bits in isolation did not affect the hardware cuemix display in
535 any way.
536
537 When this register is read back its value appears to be 0x00001800 no matter
538 what the optical inputs are set up as.
539
540
541 0x0b14 - clock control register
542
543 This register is used in conjunction with others (like 0x0c0-0x0c6) to
544 control the sample clock.  Not all bits have been identified yet.  Any write
545 to this register seems to lock out the front panel sample rate control until
546 the MOTU is turned off or the MOTU is unplugged from the computer.
547
548 The details of the clock control register are summarised below.
549
550   bits 31-28: unknown at present.  Seem to always be set to 0.
551
552   bit 27: in 2x or 4x clock mode, this bit indicates whether word clock out
553     should follow the system clock (bit 27 set to 1) or should be forced to
554     the base rate (bit 27 set to 0).
555
556   bits 26-6: unknown at present.  Bit 26 appears to be set in every write to
557     this register.  Bits 25 and 24 are toggled at various stages when the
558     rate is changed and seem to both be set at times when iso data streaming
559     is enabled.  Other bits appear to always be set to zero.
560
561   bit 5: 4x rate multiplier selector
562     Enables the 4x clock multiplier (giving access to 176000 Hz and 192000 Hz
563     rates)
564
565   bit 4: 2x rate multiplier selector
566     Enables the 2x clock multiplier (giving access to 88200 Hz and 96000 Hz
567     rates)
568
569   bit 3: Base rate selector:
570            0 = 44100 Hz
571            1 = 48000 Hz
572
573   bits 2-0: clock source:
574               0 = internal (and SMTPE if in the Audio console)
575               1 = ADAT optical
576               2 = (coaxial) SPDIF or (optical) TOSLink
577               3 = SMTPE (set only by SMTPE console)
578               4 = Word clock in
579               5 = ADAT 9 pin
580               6 = [ reserved? ]
581               7 = AES-EBU
582
583 Note: when changing the rate multipliers additional work needs to be done
584 involving bits 11-8 of register 0x0c04 (routing/port configuration
585 register), bits 6 and 7 of 0x0b10 (optical control register) and other as
586 yet unidentified bits of 0x0b14.  While 0x0b10 and 0x0c04 are always
587 written, they only seem to change value only when moving to a 4x multiplier.
588 to ensure the ADAT/SPDIF optical port is disabled at 4x sample rates.
589
590 The rest of the details associated with these other registers are yet to be
591 deduced.  Note for instance that the 0x0b10 changes only appear to affect
592 ADAT controls - verified by observing that the same changes to 0x0b10 are
593 made when the optical ports are turned off in the Audio console program.
594
595 When the clock source is changed via this register, the textual name of the
596 source is always sent immediately afterward to 0x0c60-0x06c.  This is used
597 to report the current clock as selected by the PC on the LCD via the setup
598 menu.  See the description of these registers for more details.
599
600 SMTPE is interesting: its distinct value (3) is configured only if one
601 requests SMTPE as the clock source under the SMTPE console.  Selecting SMTPE
602 as the source in the Audio console appears to use the "internal" setting for
603 bits 0-3.
604
605
606 0x0b24 - non-existent register probed during discovery/initialisation
607
608 Register 0x0b24 doesn't exist in the MOTU hardware, but a read request is
609 sent to it twice during device discovery/initialisation.  In response the
610 MOTU returns "type_error" with data equal to 0x40000.  The precise purpose
611 of this is not known.
612
613
614 0x0b28 - copy of model_id unit directory
615
616 This register appears to be a copy of the model_id unit directory, normally
617 found in config ROM register 0x0434.  The presence and contents of this
618 register have only been verified on the 828MkII - the driver reads this
619 register when a 828MkII is connected but the Traveler initialisation
620 sequence does not appear to read it.
621
622
623 0x0b2c - something related to selections in mixer application
624
625 This register has something to do with destination of the selected mix bus
626 in the mixer application.  When a mix bus is selected, 0xbXX is written to
627 this register where XX is the output destination of the selected mix bus.
628 The interpretation of XX is the same as for the 0x0c20 register - see below.
629
630 The point of this is not currently known.
631
632 If "Cuemix input includes computer output" is selected in cuemix console:
633   0xc01 is written to register 0x0b2c
634   0x001 is written to register 0x0c18
635
636 When "Cuemix input includes computer output" is turned off in cuemix console:
637   0xc00 is written to register 0x0b2c
638   0x000 is written to register 0x0c18
639
640 When Cuemix console is started, 0xb00 is written to register 0x0b2c after
641 the rest of the startup sequence is complete; some time later a value
642 of 0x0b02 is written.  This sequence is possibly related to the mix
643 inherently selected when cuemix is started; as noted above, when a mix
644 is selected it does cause 0xb00 to be written to.
645
646 Register 0x0b2c appears to be read-only.
647
648
649 0x0c00 - firmware programming control
650
651 It appears that when the MOTU is in "update" mode this register is used
652 to enable writing to the device's firmware area (registers 0x010000 -
653 0x019ffc and 0x01c000 - 0x02fffc).  Writing 0x4d4f5455 ("MOTU") seems
654 to enable writes to the firmware while writing 0x00 is written when the
655 firmware update is complete.
656
657
658 0x0c04 - routing / port configuration
659
660 This register appears to have something to do with routing and port
661 configuration.
662
663 Bits 7-0 control the source for the phones output.  The numbers used are
664 the same as for the output destination of the mix routing control (0x0c20
665 etc) - see below for details.
666
667 Bits 9-8 specify the mode of the optical input port:
668   00 = off, 01 = ADAT, 10 = TOSLink (numbers given are in binary)
669 The "TOSLink" option is not available on the 896HD.  Register 0xb10 also
670 plays a role in setting the optical input port mode.
671
672 Bits 11-10 specify the mode of the optical output port in the same way
673 as for the optical input port.  Again, register 0b10 seems to play a role
674 in setting the optical output port mode.
675
676 Bit 24 enables the setting of the phones source.  Bit 25 probably allows the
677 optical modes to be set.
678
679 Bits 31-26, 23-12 are unknown at present.  They seem to always be zero.
680
681
682 0x0c08 - input level (for analog channels 5-8 only)
683
684 This sets the input level for analog channels 5 to 8.  The default is
685 +4 dBU, but this register can be used to select -10 dBU if desired.
686
687 Only bits 4-7 appear to be significant in this register when setting input
688 level; all other bits are set to zero.
689
690   bit 4: analog channel 5 input level
691   bit 5: analog channel 6 input level
692   bit 6: analog channel 7 input level
693   bit 7: analog channel 8 input level
694
695 It seems likely that bits 0-3 are reserved for analog channels 1-4
696 respectively.
697
698 When a channel's bit is set (the default condition) an input level of +4 dBU
699 is assumed.  If the bit is zero it selects an input level of -10 dBU for
700 the respective channel.
701
702 A write to this register sets the input level for all channels.
703
704 The MOTU mixer application ties analog channels 5/6 and 7/8 together
705 (presumedly as a stereo pair) and activates the input level for the pair
706 whenever one channel is selected (even when the channels are not "paired").
707 However, it has been verified that the input level of channels can be
708 individually controlled though this register.
709
710
711 0x0c14 - boost controls (for analog channels 5-8 only)
712
713 Bits 4-7 of this register controls the activation of an additional 6dB of
714 gain for analog channels 5-8.  All other bits are set to zero.
715
716   bit 4: analog channel 5 boost
717   bit 5: analog channel 6 boost
718   bit 6: analog channel 7 boost
719   bit 7: analog channel 8 boost
720
721 Once again, bits 0-3 are probably reserved for analog channels 1-4 if they
722 were ever to acquire this functionality.
723
724 When a bit is zero (the default condition) the additional 6 dB boost is not
725 active.  When set to 1, the boost becomes active for the respective channel.
726
727 The boost status of all 4 channels is always updated by a write to this
728 register.
729
730
731 0x0c18 - something related to selections in mixer application
732
733 If "Cuemix input includes computer output" is selected:
734   0xc01 is written to register 0x0b2c
735   0x001 is written to register 0x0c18
736
737 When "Cuemix input includes computer output" is turned off:
738   0xc00 is written to register 0x0b2c
739   0x000 is written to register 0x0c18
740
741
742 0x0c1c - gain trim / 20 dB pad controls (for analog channels 1-4 only)
743
744 This register controls the trim gain and 20 dB pad available on analog
745 channels 1-4.  Byte 0 (the least significant byte) controls analog channel
746 1.  Bytes 1-3 are for analog channels 2-4 respectively.
747
748 Bit 7 in each byte appears to always be set to 1.  The effect of setting
749 bit 7 to 0 is currently unknown.  On write, bit 7 may be a write-enable
750 control.
751
752 Bit 6 of a byte controls the 20 dB pad for the channel.  When bit 6 is set
753 (ie: equal to 1) the pad is engaged.  When bit 6 is zero the pad is switched
754 out.
755
756 Bits 0-5 set the gain trim value; 0 sets a gain of 0dB (the default) while
757 a value of 0x35 (53) sets the maximum gain of 53 dB.  The trim gain acts
758 in steps of 1 dB.
759
760 It seems the gain trim and pad settings of all channels can be set with a
761 single write to this register.  However, if a channel's byte is written as
762 zero its settings remain unchanged.
763
764
765 0x0c20, 0x0c24, 0x0c28, 0x0c2c - mix1, mix2, mix3 and mix4 routing controls
766
767 These registers control routing for the mix buses.  The format used by the
768 four mix buses is the same, so only 0x0c20 (mix1 routing control) is
769 explicitly discussed.
770
771   bits 31-26: function currently unknown.  All bits seem to be set to 0.
772   bit 25:     enable setting of mute status and destination.
773   bit 24:     enable setting of fader.
774   bits 23-16: function currently unknown.  All bits seem to be set to 0.
775   bits 15-13: purpose unknown.  Seems to be set to 0.
776   bit 12:     mute control.  0=unmute, 1=mute.
777   bits 11-8:  output destination (see below).
778   bits 7-0:   mix output fader.  0x80 = 0 dB, 0x00 = -inf
779
780 The output destination is defined as follows:
781
782   0x0 = disabled
783   0x1 = headphone output
784   0x2 = analog 1-2
785   0x3 = analog 3-4
786   0x4 = analog 5-6
787   0x5 = analog 7-8
788   0x6 = AES-EBU
789   0x7 = SPDIF
790   0x8 = ADAT 1-2
791   0x9 = ADAT 3-4
792   0xa = ADAT 5-6
793   0xb = ADAT 7-8
794
795 Note that it is not possible to set the mute and destination status
796 separately - they are both set when bit 25 is set.
797
798
799 0x0c60, 0x0c64, 0x0c68, 0x0c6c - ASCII name of current clock source
800
801 These registers appear to hold the ASCII name of the current clock source.
802 If the source name is less than 16 characters it is padded with spaces
803 (0x20).  The most significant byte of each register holds the leftmost
804 character of the group of 4 characters held by a that register.  For
805 example, if a register needs to hold the string "ABCD", the most significant
806 byte will be 65 ("A").
807
808 Currently defined strings are as follows.
809
810   "Internal        " - internal clock source
811   "SMPTE           " - SMPTE syncing
812   "AES-EBU         " - use clock from AES-EBU
813   "SPDIF           " - clock from (coaxial) SPDIF
814   "TOSLink         " - clock from (optical) TOSLink
815   "Word Clock In   " - use the word clock input
816   "ADAT 9-pin      " - use the 9-pin ADAT interface for the clock
817   "ADAT Optical    " - sync from ADAT optical interface
818
819 When a computer is connected to the MOTU the only way to set the clock
820 source is from the computer - the front panel controls for this are
821 disabled.  The string sent via these registers is used to display the name
822 of the clock source as selected by the computer.  If the clock source is
823 changed (via register 0x0b14) but nothing is downloaded using these
824 registers, the "current clock source" display on the LCD via the setup menu
825 will be blank.
826
827 One would have thought the Motu would be smart enough to provide the display
828 string by itself given that it seems to manage to set the string fine by
829 itself when there's no PC connected and the front panel is used to change
830 the clock source.
831
832
833 0x4y00-0x4y4c (y=0-3) - gain/pan/solo/mute registers
834
835 These registers control the fader, pan, mute and solo settings for a given
836 input channel in each of the 4 mix buses.  y=0 is mix1, y=1 is mix2, y=2 is
837 mix3 and y=3 is mix4.
838
839   Bit 31:     enable setting of pan
840   Bit 30:     enable setting of gain
841   Bit 29:     enable setting of bit 21
842   Bit 28:     enable setting of bit 20
843   Bit 27:     enable setting of pairing
844   Bit 26:     enable setting of bit 18
845   Bit 25:     enable setting of solo
846   Bit 24:     enable setting of mute
847   Bit 23:     seems to be unsettable; set to zero
848   Bit 22:     seems to be unsettable; set to zero
849   Bit 21:     can be set to 1 but no effect apparent
850   Bit 20:     can be set to 1 but no effect apparent
851   Bit 19:     activate pairing
852   Bit 18:     can be set to 1 but no effect apparent
853   Bit 17:     channel solo.  0=solo off, 1=solo on.
854   Bit 16:     channel mute.  0=unmuted, 1=muted.
855   Bits 15-8:  pan.  0x40=0 (centre), 0x80=+64 (right), 0x00=-64 (left)
856   Bits 7-0:   gain.  0x00 = -inf, 0x80 = 0 dB.
857
858 When reading these registers in normal operation, bits 31-27 and bits 23-18
859 seem to be all zero while bits 26-24 are all 1.  The Cuemix console however
860 appears to set bits 31-30 and zero bits 29-18.  In other words, a typical
861 read-back value might be 0x0700406a while to actually set the mixer to this
862 one would need to use a value of 0xc300406a.  It seems likely that at least
863 some of the bits have different meanings when read and written; for instance
864 there doesn't seem to be much point in bits 24-26 being set on readback
865 given the above definitions, but they are.
866
867 If channel pairing is to be activated it must be set in both channels which
868 form a stereo pair.  However, paired channels are still controlled
869 individually by the mixer registers - for example, if channels 1 and 2 are
870 paired it is still possible to raise channel 1's volume in mix1 by writing
871 only to register 0x4000.  In other words, the device does not enforce linked
872 controls when channels are paired.  The "paired" flag is really just a hint
873 to the mixer at the end of the day.
874
875
876 Gain and pan value-dB mappings for the Traveler
877 ===============================================
878
879 The following gain map runs from 0x00 (-inf) to 0x80 (0 dB).  The dB values
880 were taken directly off the Cuemix console application.
881
882 Gain steps (dB): -inf, -84, -72, -65, -60, -56, -53, -50, -48, -46, -44,
883   -43, -41, -39.7, -38.4, -37.2, -36.1, -35.1, -34.1, -33.1, -32.2, -31.4,
884   -30.6, -29.8, -29.1, -28.4, -27.7, -27.0, -26.4, -25.8, -25.2, -24.6,
885   -24.1, -23.5, -23.0, -22.5, -22.0, -21.5, -21.1, -20.6, -20.2, -19.8,
886   -19.4, -19.0, -18.6, -18.2, -17.8, -17.4, -17.0, -16.7, -16.3, -16.0,
887   -15.6, -15.3, -15.0, -14.7, -14.4, -14.1, -13.8, -13.5, -13.2, -12.9,
888   -12.6, -12.3, -12.0, -11.8, -11.5, -11.2, -11.0, -10.7, -10.5, -10.2,
889   -10.0, -9.8, -9.6, -9.3, -9.1, -8.8, -8.6, -8.4, -8.2, -7.9, -7.7, -7.5,
890   -7.3, -7.1, -6.9, -6.7, -6.5, -6.3, -6.1, -5.9, -5.7, -5.5, -5.4, -5.2,
891   -5.0, -4.8, -4.6, -4.5, -4.3, -4.1, -3.9, -3.7, -3.6, -3.4, -3.3, -3.1,
892   -3.0, -2.8, -2,6, -2.5, -2.3, -2.2, -2.0, -1.9, -1.7, -1.6, -1.4, -1.3,
893   -1.1, -1.0, -0.8, -0.7, -0.6, -0.4, -0.3, -0.1, 0.0
894
895 Pan: (approximate findings)
896   full pan on: +3 dB gain
897   0: 0 dB
898   20/64 pan off: -3 dB
899   40/64 pan off: -6 dB
900   55/64 pan off: -15 dB
901   59/64 pan off: -24 dB
902   full pan off: -inf gain
903
904 Pan dB map.  This table runs from value 0 (pan full left) to 0x80 (pan
905 full right).  The gain values are for a left channel signal.
906   2.505, 2.505, 2.505, 2.499, 2.499, 2.492, 2.486, 2.479, 2.473, 2.460,
907   2.453, 2.440, 2.427, 2.414, 2.400, 2.387, 2.367, 2.347, 2.331, 2.308,
908   2.288, 2.267, 2.241, 2.220, 2.194, 2.166, 2.139, 2.105, 2.078, 2.044,
909   2.016, 1.982, 1.940, 1.905, 1.870, 1.828, 1.786, 1.743, 1.700, 1.657,
910   1.607, 1.563, 1.512, 1.461, 1.409, 1.358, 1.298, 1.245, 1.185, 1.124,
911   1.063, 1.001, 0.931, 0.868, 0.797, 0.725, 0.653, 0.580, 0.507, 0.424,
912   0.341, 0.265, 0.257, 0.087, 0.000,
913   -0.087, -0.176, -0.274, -0.373, -0.473, -0.584, -0.687, -0.801, -0.916,
914   -1.033, -1.151, -1.271, -1.403, -1.526, -1.662, -1.800, -1.940, -2.083,
915   -2.239, -2.386, -2.548, -2.713, -2.881, -3.058, -3.240, -3.437, -3.614,
916   -3.814, -4.018, -4.228, -4.457, -4.678, -4.920, -5.168, -5.489, -5.688,
917   -5.969, -6.259, -6.568, -6.889, -7.222, -7.568, -7.928, -8.327, -8.722,
918   -9.160, -9.621, -10.108, -10.624, -11.205, -11.810, -12.460, -13.182,
919   -13.971, -14.886, -15.855, -16.976, -18.264, -19.819, -21.715, -24.143,
920   -27.526, -33.143, -inf
921
922 dB factors for values of 0, 1 and 2 are all 2.505 dB while those for pan
923 values of 3 and 4 are both 0.499.  This is because the voltage variation
924 across each of these groups of values was below the resolution of the meter
925 used to measure the voltages (0.001 Vrms).  One can probably safely assume
926 that the actual variation across these groups is approximately linear, so
927 "corrected" dB values for the first 5 pan values can probably be taken to be
928   2.508, 2.505, 2.504, 2.501, 2.499
929
930 The pan map was measured by injecting a 0.992 Vrms sine wave at 308 Hz into
931 analog1 input channel of the Motu.  Channel 1's -20 dB pad was switched in
932 to avoid overloading the preamp and a gain trim of +11 dB was used. This
933 combination resulted in a signal of 0.999 Vrms being emitted from analog1
934 output with the analog1's fader set to 0 dB.
935
936 The output RMS voltage was then measured for each setting of the pan
937 control.  Resolution of these measurements was 0.001 Vrms.  The dB gain
938 value was calculated relative to the centre pan position using
939
940   dB = 20log10(V/ref)
941
942 where ref was the voltage measured with the pan control set to the centre
943 (ie: a pan value of 0x40).
944
945 A frequency of approximately 300 Hz was chosen since this was firmly within
946 the flat response region of the multimeter used for measuring the voltage.
947 If the frequency drifted slightly the frequency response of the meter would
948 therefore not artificially change the voltage measurement.
949
950 The input signal was generated using a precision audio signal generator.
951 The amplitude is tightly regulated and did not change for the duration of
952 these tests.
953
954 The meter used was not able to measure voltages below 0.004 Vrms.  This was
955 a limitation of the meter - it was not an additive offset which affected
956 voltage measurements.
957
958 Putting all this together it is expected that the dB values for the pan map
959 are accurate to at least 1 decimal place.
Note: See TracBrowser for help on using the browser.