I2S protocol - common mistakes checklist

I am staring at the board, the schematic, and my code.  I press the button.  A squeal comes from the left channel, only.  Urgh.  I am in the land of debugging I2S protocol.  Here are some notes:

Use the logic analyzer even though I am reluctant to drag it out.  But when I look at it, the fifteen minutes it takes me take to solder the test points and set it up are probably better than the hour that I spent poking at code.  Unless, of course, my solder points cause problems (like pulling up and disconnecting the trace).  I will try to avoid those!

Second, here is my major checklist.  I think almost all of my bugs could be traced to a mis-setting of one of these, either on master or slave:

1. Master and slave - who is who?  The master sets the frame and bitclock, and sends these continuously.  The slave sends data - and should automatically sync to the master's bitclock.  I initially forgot to set the MCU as master.  Nothing worked.
2. Frequency - if you are using a PLL to generate the sampling frequency (FS), it is possible to set this wrong, like I did (I revered the word order of the registers, ugh).  The easy sanity check is that the frame cycle (high low) is indeed a total of 50usec (if at 22.05kHz) long or ~25usec (if at 44.1kHz).
3. Word length - I default to 16 bits.  This is the number of bits per one channel of one sample (e.g. for left and right samples it takes 32 bits total).  
4. Frame length (or bitclock speed e.g. 32x FS).  This is the length of the frame used to transmit the words.  I used a bitclock speed of 32 bits/frame, which means that for each frame two 16 bit words, one for the left and one for the right channel, are sent.  If the frame is wider (for some reason you can use wider frames but I'm not sure why you'd do this) you then have to worry about left and right justification.  If the frame length is wrong (e.g. 64 bits) then it may show up as just a single channel.
5. Byte order.  The SGTL5000 takes data big-endian (most significant byte) first.  Understand whether the driver will take care of byte order (e.g. flip from little endian data that DMA puts into the register to big-endian) for you or if you need to reverse your data.  If you get byte order wrong everything will sound like white noise as the low order bits contain essentially random noise.
6. Signed or unsigned - the symptom of this is that a sine wave sounds like a square wave.  
7. Rising/falling edge data transfer - easy to see in the analyzer.
8. First bit comes one clock after frame sync, or on frame sync - also easy to check in the analyzer.
9. DMA transfer request number.  If your -stereo- sound is 1 second long at 22.05KHz and 16 bits, it is 22050 * 2 * (2 bytes) = 88200 bytes long, and will require 44100 transfers.  I had to double check my memory buffer code to get this right.