Right now, making very large latency-sensitive USB reads is done by giving interface.read() a hint with the amount of expected data, which causes it to use a buffer that large. Unfortunately, the following sequence still results in a FIFO underflow:

1. interface.read(512, hint=512*1000) is called
2. device returns a single 512-byte packet, interface.read returns
3. processing starts; bus is idle (no IN-BULK-NAK)
4. device queues 2 (4) more 512-byte packets, filling FX2 FIFO
5. interface.read(512, hint=512*1000) is called again

Given how small the FX2+device FIFO are (at most a 2+30 KB on UP5K), the maximum fill rate (up to 30 KB per millisecond), and the OS scheduling latency (at best, a few milliseconds), if we get a context switch anywhere between steps 3 and 5, a FIFO underflow is unavoidable at the maximum fill rate, and becomes linearly less likely at fractions of maximum fill rate. This can be easily demonstrated with the shugart-floppy applet at higher read redundancies.

Thus, we have to teach the software to pipeline USB reads. Up to 30 MB/s of reads should definitely be doable in Python if no particular processing is done (shugart-floppy just appends reads to a buffer), and possibly even with processing.