Changeset 1490

11/27/08 21:06:35 (15 years ago)

Further updates to device documentation files.



  • trunk/libffado/doc/rme_notes/rme_config_register_map.txt

    r1444 r1490  
    4 Version: 0.3 
     4Version: 0.4 
    55Author: Jonathan Woithe 
    6 Date: 15 November 2008 
     6Date: 27 November 2008 
    4646and then caches the sample rate locally. 
     48In terms of multipliers the RME treats sample rates greater than 112000 Hz 
     49as 4x rates, with rates greater than 56000 Hz as 2x rates.  Rates less than 
     5030000 Hz and greater than 210000 Hz are invalid. 
    4953Configuration registers 1, 2 and 3 
    6266Configuration register 1 (FF800: 0xfc88f014): 
    64   bits 31-8: unknown, set to 0 
     68  bits 31-18: unknown, set to 0 
    6569  bits 17-16: Phones level: 
    6670    00 = +4 dBu 
     142Waiting for device flash 
     145To preserve the device's settings across power cycles the settings are 
     146stored in a flash memory on the device.  This is read during driver 
     147initialisation to ensure the driver's status agrees with that of the device. 
     149When interacting with the device's flash memory one must wait for the 
     150completion of an operation before attempting another.  The location of the 
     151"device busy" flag differs between the FF400 and FF800. 
     153On the FF800 is part of the quadlet register at 0x801c0004 (part of the 
     154read-only status register block beginning at 0x801c0000).  The device is 
     155ready to accept another command when bit 30 is set. 
     157On the FF400 the wait state is found by reading a quadlet from CBR+8*4. 
     158If this quadlet is zero the FF400 is ready to accept another command. 
     160Most device flash operations have a minimum time to complete.  There's no 
     161point in polling the device busy flag until at least this much time has 
    138165Streaming control registers 
    203230Audio/midi data is sent and received on isochronous channels previously 
    204 configured by the driver.  It seems the data is sent with one channel per 
    205 quadlet.  The audio data is a 24 bit integer stored in the most-significant 
    206 3 bytes of a quadlet.  The LSB (low byte) of certain channels in the stream 
    207 sent by the Fireface is used to send synchronising information: 
     231configured by the driver.  On a dedicated bus with nothing else present, the 
     232stream to the fireface is sent on iso channel 0 while data from the fireface 
     233is sent on iso channel 1. 
     235No CIP header is included in the iso data packet.  Fireface data follows 
     236immediately after the standard 2-quadlet firewire iso packet header. 
     238Each iso packet contains a number of samples across all 28 device channels. 
     239For 1x rates, 7 samples per channel seem to be sent.  Thus the size of  
     240the data portion of a 1x iso packet is 28*4*7 = 784, with a total packet 
     241size being 784 + 8 = 792. 
     243The data is sent with one audio channel per quadlet.  The audio data is a 24 
     244bit integer stored in the most-significant 3 bytes of a quadlet.  The LSB 
     245(low byte) of certain channels in the stream sent by the Fireface is used to 
     246send synchronising information: 
    209248  Low byte of channel 6 = current frame 
    213252  Low byte of channel 0 = tx buffer size, low byte 
    214253  Low byte of channel 5 = tx buffer size, high byte 
     254  Low byte of channel 2 & 3 = unknown (midi?) 
     256The low byte data from channels 0-7 is repeated in channels 8-15 and 16-23 
     257respectively, with channels 24-27 containing the low byte data from channels 
     2580-3.  This repetition holds for the low bytes of channels 2-3 in all data 
     259seen so far, it might not necessarily be the case in general - it depends 
     260what the low byte data from channels 2 and 3 are used for. 
     262The rx sample counter appears to be used to detect missed samples.  The 
     263current frame and phase from a received packet is used in conjunction with 
     264the stored values of these from the previous frame to track the phase of 
     265the audio clock. 
     267A "frame" consists of a fixed number of samples across all channels of the 
     268device.  At 1x rates this appears to be 7, but it might not be fixed.  Even 
     269though this is the same as the number of samples per channel per packet, a 
     270given packet can experience a change in the "current frame" part way 
     271through.  In other words, the "current frame" is not necessarily constant 
     272for all samples in a packet. 
    275333In each 28-element array the channel data appears in standard fireface 
     337Host LED 
     340The "host" LED of the FF800 is controlled by a dedicated register at 
     3410x200000324.  Note that this register address goes beyond the 32-bit