RME Fireface800 protocol notes ============================== Author: Jonathan Woithe Date: 24 March 2008 Introduction ------------ This document contains random notes made while observing the protocol used by the RME Fireface 800 interface. This document is not necessarily all that coherent but fully documents what is seen on the bus when various actions are carried out. For a distilled version of our current knowledge of the protocol please refer to rme_config_register_map.txt. The information contained here was observed from a Fireface 800 device: RME vendor ID: 0x000a35 GUID: 0x0093e1daf1 Node capabilities: 0x0083c0 Unit spec ID: 0x0a35 Sw version number: 0x0001 Model ID: 0x101800 Setting device configuration options in general ----------------------------------------------- It seems that generally device configuration is effected by writing 0x0c bytes to register 0xfc88f014. However, the existing drivers do much more than just this. For example, when setting DDS inactive (which doesn't appear significantly different to setting it active): Read 0x10 @ 0x801c0000: 01c000b1 a0001001 ffffffff ffffffff Read @ 0xfffff0000410: 0x93e1daf1 Read 0x10 @ 0x801c0000: 01c000b0 a0001001 ffffffff ffffffff Read @ 0xfffff0000410: 0x93e1daf1 Read 0x10 @ 0x801c0000: 01c000b0 a0001001 ffffffff ffffffff Read @ 0xfffff0000410: 0x93e1daf1 Read @ 0xfffff000040c: 0xa3500 Write 0xfc88f000: 0000ac44 Read 0x10 @ 0x801c0000: 01c000b1 80001001 ffffffff ffffffff Read @ 0xfffff0000410: 0x93e1daf1 Read 0x10 @ 0x801c0000: 01c000b1 80001001 ffffffff ffffffff Read @ 0xfffff0000410: 0x93e1daf1 Read 0x10 @ 0x801c0000: 01c000b0 80001001 ffffffff ffffffff Read @ 0xfffff0000410: 0x93e1daf1 Read 0x10 @ 0x801c0000: 01c000b0 80001001 ffffffff ffffffff Read @ 0xfffff0000410: 0x93e1daf1 Read 0x10 @ 0x801c0000: 01c000b1 80001001 ffffffff ffffffff Read @ 0xfffff0000410: 0x93e1daf1 When setting to 48k: Read 0x10 @ 0x801c0000: 01c000b0 a0001001 ffffffff ffffffff Read @ 0xfffff0000410: 0x93e1daf1 Read 0x10 @ 0x801c0000: 01c000b0 a0001001 ffffffff ffffffff Read @ 0xfffff0000410: 0x93e1daf1 Read 0x10 @ 0x801c0000: 01c000b0 a0001001 ffffffff ffffffff Read @ 0xfffff0000410: 0x93e1daf1 Read 0x10 @ 0x801c0000: 01c000b0 a0001001 ffffffff ffffffff Read @ 0xfffff0000410: 0x93e1daf1 Read 0x10 @ 0x801c0000: 01c000b1 a0001001 ffffffff ffffffff Read @ 0xfffff0000410: 0x93e1daf1 Read @ 0xfffff000040c: 0xa3500 Write 0xfc88f000: 0000bb80 Read 0x10 @ 0x801c0000: 01c000c0 a0001007 ffffffff ffffffff Read @ 0xfffff0000410: 0x93e1daf1 Read 0x10 @ 0x801c0000: 01c000c0 a0001007 ffffffff ffffffff Read @ 0xfffff0000410: 0x93e1daf1 Read 0x10 @ 0x801c0000: 01c000c0 a0001007 ffffffff ffffffff Read @ 0xfffff0000410: 0x93e1daf1 Read 0x10 @ 0x801c0000: 01c000bf a0001007 ffffffff ffffffff Read @ 0xfffff0000410: 0x93e1daf1 Read 0x10 @ 0x801c0000: 01c000c0 80001007 ffffffff ffffffff Read @ 0xfffff0000410: 0x93e1daf1 Read 0x10 @ 0x801c0000: 01c000c0 a0001007 ffffffff ffffffff Read @ 0xfffff0000410: 0x93e1daf1 When using the "course" control, the frequency seems to be set by: Read quadlet @ 0xfffff000040c: 0xa3500 Write @ 0xfc88f000 Each write to 0xfc88f000 seems to be preceeded by a read of 0xfffff000040c, resulting in a value of 0xa3500. Before and after this is a variable number of repeats of the sequence block read of 0x10 bytes (4 quadlets) at 0x801c0000 quadlet read at 0xfffff0000410 These reads seem to be some kind of status check on the device. However, there doesn't seem to be any consistent pattern as to when the write is performed relative to changes in these registers, nor does the process terminate in response to a particular setting of these registers. It seems that most if not all parameter settings are done with this pattern of reads above and below the actual write which (presumedly) activates the respective change. Looking for patterns, consider the settings of quadlets 0 and 1 in the last block from 0x801c0000 before the respective set operation finishes: 32k: 01c00080 80001003 44.056: 01c000b1 a0001001 44.144: 01c000b0 80001001 44.1: 01c000b1 80001001 45.937: 01c000b8 a0001001 46.080: 01c000b8 80001007 47.952: 01c000c0 a0001007 48: 01c000c0 a0001007 48.048: 01c000c0 a0001007 mult 2x-1x: t=866835 01c0017f 8000100f 876846 01c00180 8000100f 377579 01c00180 8000100f t=512691 write t=868285 01c000c0 80001007 878299 01c000c0 80001007 379027 01c000c0 80001007 mult 2x-4x: t=278863 01c00180 a000100f 769567 01c00180 a000100f 779580 01c00180 a000100f 280315 01c00180 a000100f t=536803 write t=771004 01c002ff a0001017 781034 01c00300 a0001017 281784 01c00300 a0001017 mult 4x-1x: t=784082 01c00300 a0001017 794099 01c00300 a0001017 294837 01c00300 a0001017 t=753719 write t=785530 01c000c0 a0001007 795553 01c000c0 a0001007 296297 01c000c0 a0001007 786993 01c000c0 a0001007 797001 01c000c0 a0001007 mult 4x-2x: 01c00300 80001017 01c00300 80001017 write 01c00180 8000100f 01c00180 a000100f 01c00180 a000100f 01c00180 a000100f DDS active: 01c000b1 a0001001 01c000b1 a0001001 01c000b0 a0001001 write 01c000b0 a0001001 01c000b0 80001001 01c000b1 a0001001 01c000b0 80001001 01c000b1 80001001 01c000b1 80001001 DDS inactive: 01c000b1 a0001001 01c000b0 a0001001 01c000b0 a0001001 write 01c000b1 80001001 01c000b1 80001001 01c000b0 80001001 01c000b0 80001001 01c000b1 80001001 Before and after settings: x - 32k: - 01c00080 80001003 32-44.1: 01c00080 80001003 - 01c000b1 80001001 44.1-48: 01c000b0 a0001001 - 01c000c0 a0001007 48-96: 01c000c0 a0001007 - 01c00180 8000100f 48-192: 01c000c0 a0001007 - 01c00300 80001017 96-192: 01c00180 a000100f - 01c00300 a0001017 96-48: 01c00180 8000100f - 01c000c0 80001007 192-48: 01c00300 a0001017 - 01c000c0 a0001007 192-96: 01c00300 80001017 - 01c00180 a000100f (jitter in bit 0 of 1st quadlet, and possibly bit 29 of 2nd quadlet) For now there's little we can do - we'll ignore these additional reads (or maybe just do a few token ones of our own) and see how far we get. It seems that some clock rate information is included in here, but not the complete picture. Perhaps the base rate is available here, but little else. In fact there doesn't appear to be anywhere which conveys the device's rate back to the PC; the PC seemingly sets the rate to its desired rate and then effectively caches the sample rate. Buffer sizes ------------ All settings: 0xfc88f014 = 00000810 0000035e c400101f It seems that device configuration is not affected by this setting. Obviously *some* setting is sent to the device whenever the buffer size is changed though. Clock mode ---------- Master: 0xfc88f014 = 00000810 0000035e c400101f Autosync: 0xfc88f014 = 00000810 0000035e c400101e DDS (Frequency setting) ----------------------- 32k: 0xfc88f000 = 00007d00 (32000) 44.056: 0xfc88f000 = 0000ac18 (44056) 44.144: 0xfc88f000 = 0000ac70 (44144) 44.1k: 0xfc88f000 = 0000ac44 (44100) 45.937: 0xfc88f000 = 0000b371 (45937) 46.080: 0xfc88f000 = 0000b400 (46080) 47.952: 0xfc88f000 = 0000bb50 (47952) 48k: 0xfc88f000 = 0000bb80 (48000) 48.048: 0xfc88f000 = 0000bbb0 (48048) Multiplier (base freq of 48k): 1-2: 0xfc88f000 = 00017700 (96000) 2-1: 0xfc88f000 = 0000bb80 (48000) 2-4: 0xfc88f000 = 0002ee00 (192000) 1-4: 0xfc88f000 = 0002ee00 (192000) 4-2: 0xfc88f000 = 00017700 (96000) 4-1: 0xfc88f000 = 0000bb80 (48000) Set DDS active: 0xfc88f000 = 0000ac44 Set DDS inactive: 0xfc88f000 = 0000ac44 To set the RME Fireface800 frequency, write the actual frequency to register 0xfc88f000. Setting DDS active doesn't appear to make any changes to the actual hardware. Input level ----------- +4dBU: 0xfc88f014 = 00000810 0000035e c400101f -10dBV: 0xfc88f014 = 00000820 0000035f c400101f lo-gain: 0xfc88f014 = 00000808 0000035c c400101f Inputs ------ #1 set front: 0xfc88f014 = 00000810 00000b5a c400101f #1 set front+rear: 0xfc88f014 = 00000810 00000b5e c400101f #1 set rear: 0xfc88f014 = 00000810 0000035e c400101f #7 set front: 0xfc88f014 = 00010810 0000033e c400101f #7 set front+rear: 0xfc88f014 = 00020810 0000037e c400101f #7 set rear: 0xfc88f014 = 00000810 0000035e c400101f #8 set front: 0xfc88f014 = 00000810 000002de c400101f #8 set front+rear: 0xfc88f014 = 00000810 000003de c400101f #8 set rear: 0xfc88f014 = 00000810 0000035e c400101f Instrument options ------------------ none-drive: 0xfc88f014 = 00000a10 0000015e c400101f none-lim: 0xfc88f014 = 00000810 0000035e c400101f none-sp_emu: 0xfc88f014 = 00000814 0000035e c400101f *-none: 0xfc88f014 = 00000810 0000035e c400101f "Lim" would appear to be a software setting since the hardware setting for "lim" seems to be the same as for "none". Output level ------------ +4dBU: 0xfc88f014 = 00000810 0000035e c400101f -10dBV: 0xfc88f014 = 00001010 0000034e c400101f hi-gain: 0xfc88f014 = 00000410 00000356 c400101f Phantom ------- mic 7 on: 0xfc88f014 = 00000811 0000035e c400101f mic 8 on: 0xfc88f014 = 00000890 0000035e c400101f mic 9 on: 0xfc88f014 = 00000812 0000035e c400101f mic 10 on: 0xfc88f014 = 00000910 0000035e c400101f SPDIF in -------- coax: 0xfc88f014 = 00000810 0000035e c400101f ADAT2: 0xfc88f014 = 00000810 0000035e c400121f SPDIF out --------- ADAT2: 0xfc88f014 = 00000810 0000035e c400111f emphasis: 0xfc88f014 = 00000810 0000035e c400105f non-audio: 0xfc88f014 = 00000810 0000035e c400109f professional: 0xfc88f014 = 00000810 0000035e c400103f Sync reference source --------------------- ADAT1: 0xfc88f014 = 00000810 0000035e c400001f ADAT2: 0xfc88f014 = 00000810 0000035e c400041f SPDIF: 0xfc88f014 = 00000810 0000035e c4000c1f TCO: 0xfc88f014 = 00000810 0000035e c400141f Wordclock: 0xfc88f014 = 00000810 0000035e c400101f Unit options ------------ Start with all options on. Turn each of separately: -checkinput: 0xfc88f014 = 00000810 0000035e c400101f -interleaved: 0xfc88f014 = 00000810 0000035e c400101f -syncalign: 0xfc88f014 = 00000810 0000035e c400101f -tms: 0xfc88f014 = 00000810 0000035e 8400101f This tends to indicate that TMS is the only "unit option" which affects the hardware. All the others would appear to be software features. Word clock ---------- Single speed on: 0xfc88f014 = 00000810 0000035e c400301f Single speed off: 0xfc88f014 = 00000810 0000035e c400101f Streaming start --------------- Frequency was 44100 Hz. Playback: Read from 0xfffff000040c: 0xa3500 Read from 0xfffff000040c: 0xa3500 Write 0x0c bytes to 0x20000001c: 0000ac44 0000e000 0000001c Read 0x10 bytes from 0x801c0000: 81c000b0 80001001 00000001 00000001 Write quadlet to 0x200000028: 0x1c000000 Write 0x70 bytes to 0x801c0000: 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000000 00000000 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001 Recording: Reads from 0x801c0000 and 0xfffff0000410 as for parameter setting. 0x801c0000 = 81c000b0 80001001 00000001 00000001 0xfffff0000410 = 0x93e1daf1 Read from 0xfffff000040c: 0xa3500 Read quadlet from 0x801c0000: 81c000b1 Read from 0xfffff000040c: 0xa3500 Read quadlet from 0x801c0000: 81c000b1 Read from 0xfffff000040c: 0xa3500 Read from 0xfffff000040c: 0xa3500 Write 0x0c bytes to 0x20000001c: 0000ac44 0000e000 0000001c Read 0x10 bytes from 0x801c0000: 81c000b0 a0001001 00000001 00000001 Write quadlet to 0x200000028: 0x1c000000 Read 0x10 bytes from 0x801c0000: 81c000b0 80001001 00000001 00000001 Read from 0xfffff0000410: 0x93e1daf1 ... Streaming end ------------- Frequency was 44100 Hz. Playback: Write 0x0c bytes to 0x200000034: 00000000 00000000 00000000 Write 0x70 bytes to 0x801c0000: 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001 Read quadlet from 0xfffff000040c: 0xa3500 Recording: Reads from: 0x801c0000 = 81c000b1 80001001 00000001 00000001 0xfffff0000410 = 0x93e1daf1 Write 0x0c bytes to 0x200000034: 00000000 00000000 00000000 More reads from 0x801c0000 and 0xfffff0000410 Streaming data format --------------------- The PC functions as the IRM and thus provides the cycle timer. The packets do not contain an SPH. It is not clear how device synchronisation is done. Channels are sent in Fireface numeric order: Analog 1-10, spdif, ADAT1 1-8, ADAT2 1-8 (a total of 28 channels). Each sample is 32 bits, seemingly ordered least significant byte first. By default iso channel 0 is for PC->Fireface800 data and channel 1 carries Fireface800->PC audio data. In an example capture, packets carrying 6 frames were observed, reportedly at 44.1 kHz. Packets of varying lengths were observed (0x230, 0x2a0 from the PC, a constant 0x310 from the Fireface800). It is not known how the device maintains the correct flow of packets for the various odd-ball frequencies it supports. It appears that in certain iso cycles an iso packet is simply not sent in order to resync, but how either side knows when to do this is a mystery at present. The quadlets in a packet normally used by a CIP header seem to correspond to analog1+2.