Its starting to have that abandoned feel. I haven’t seen much from hisilicon about this in quite a while.
For (1), there is some discussion here about mono, but I haven’t had a chance to actually try it out since its priority has fallen significantly for me – I’ve implemented software workarounds;
Other sample rates are possible with a driver update. I’ve done so here;
Your (3) is invalid. Your calculation only shows the MINIMUM PERMISSIBLE bit clock. It is allowed to be much higher. In fact, 3 MHz is what you will normally see in use for hardware that supports 32 bit sample sizes. The transmitter may only fill in the 16 most significant bits, and the receiver will only pay attention to those 16 bits, the rest will be 0’s and discarded. But more significantly, if the two sides are operating at different sample sizes (which often happens if one or both sides is non-programmable), then the data still makes sense.
The actual key to the transmission is the WORD CLOCK, which defines where valid data begins. The receiver takes the WC transition as the trigger to begin reading bits from the data line, counted by the bit clock. When it finishes reading the sample, it waits any number of bit clocks until the next WC transition.