Continuous streaming w/VSG60A

I was curious about how the streaming mechanism works on the VSG60A. The API manual doesn’t go into much detail on the streaming model, but it does say, “If the buffer is full and vsgSubmitIQ() is called, the function blocks until space is available in the buffer.”

I assume there are really two (or more) buffers, such that the first two calls to vsgSubmitIQ() will run without blocking. Subsequent calls would then block until at least one buffer becomes available, allowing the app to refill that buffer while the other one is still playing — correct?

Otherwise, if there’s only one stream buffer, is it still possible to support seamless streaming of arbitrary amounts of baseband data from the host?

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

Thanks much, Andrew, that’s what I thought.

[Author]

Posts