KE5FX,
Yea, you have the right idea. We don’t really specify an exact number of buffers in the API, but you could think of it as about 200 buffers. We chunk the data up into ~1ms chunks maximum and pipeline them. Internally it’s handled as a couple large circular buffers with arbitrary indexes into them. The USB DMA transfers control the flow of the data through the pipeline. Whenever the API blocks on submit I/Q, it’s because the API is waiting for the next DMA xfer to complete and free up more space in the pipeline.
As long as you are submitting I/Q data at a rate faster than your specified sample rate, the API will always have ~200ms of data to absorb any delays.
We chose the 1ms chunk/buffer size because the API needs to upsample and correct the I/Q data before being transferred, which usually means one or more FIR filters need to be run over the data. The small buffer size ensures data keeps moving through pipeline in a ‘continuous’ fashion but is still few enough buffers per second to keep delays associated with thread synchronization primitives to a negligible amount.
Let me know if you have more questions!
Andrew
