I think 'integer mode' means that the computer is running on the clock of the DAC
Sorry, but part of that white paper is a faith healer's recipe, call it snake oil, or just call it marketing blurb! The DAC of your RME devices are *not* slaved to the computer's clock, the audio device either is its own Master clock or is synchronized from an external clock. And yes, digital gain means to lower dynamic range, but starting from 144 dB the relevance to practice is a whole different story.
Both Firewire and USB run in ISOCHRONOUS mode with RME interfaces (afaik). And this only means the method by which data is transported between computer and interface and has nothing to do with the audio interface's DAC clock!
The interface gets packets of data with a size defined by the sample-buffer. It doesn't matter at all if those packets are transferred jittery or not, they are read into the internal buffer of the interface and processed from there. The only thing that matters is that the next packet/buffer arrives in time before the interface plays the next buffer. For example, if you are using 64 samples buffer then the next 64 samples need to be transported completely before the current 64 sampled are finished being played. If the transport is not completed in time you get dropouts, if it is finished in time the interface plays the buffer using its own clock source.
Again: It doesn't matter how jittery the data transport is or is not, the only thing that matters is that the data arrives in time!
a mode called "Non-mixable linear PCM interleaved 24bits big endian Signed Integer", given the DAC's driver is offering this.
Currently my debug info for the FF 400 says : "Mixable linear PCM Interleaved 32bits little endian Float".
My guess is that this "non-mixable" mode is similar to ASIO in that it circumvents the CoreAudio mixer. I didn't know this was possible?! It may or may not have an impact on low latency audio performance, so it could be interesting from that perspective. But as long as you are only sending one audio signal per audio channel I don't see how it would have any impact on audio quality.
It simply doesn't matter whether you are sending 24-bit integer to the driver or 32-bit floating point, both represent the same digital values once the 32-bit floating point has been converted back to 24-bit integer! So as long as you are not mixing another software's output over the same channel the output of your audio application (usually working at 32 or 64-bit floating point itself) will reach the RME driver bit-correct.
Matthias, feel free to correct me! HeadScratch 
