Occasionally the new interface Transmit returns with a zero count of samples. I guess this can happen when the internally used timeout of one second is exhausted.
My question is how to deal with this fact properly. What I have already tried:
immediately try again
have the thread sleep 10ms or 100ms and try again
None of the both worked. The problem only got worse.
I understand that this could be an irrecoverably error and the current packet has to be aborted. The question than arises, what should follow?
Do I need to tear down the stream? (This would also involve the rx side.)
Do I need to reinitialize the device?
Should the whole process be stopped and restarted?
Yes, that is what you should do, if the transmitted samples are 0, try again.
Transmit() returns 0, if the internal buffers are already full, so no more samples can be queued. It is recoverable, you just need to try again until some samples will be actually transmitted to RF and some buffers will be free again.
When using timestamps synchronization, if the sent packet has a timestamp that’s very far in to the future, it will essentially block the transmit path, until that specified time. You would end up filling the internal buffers, and they would remain full until that first packet is actually transmitted to RF. If you become blocked by such timestamp, It’s enough just to stop the stream, that clears FIFOs and hardware internal state, tear down is not required.
If your used timestamp type is samples ticks, check if the timestamp is not negative, it would underflow and become very large number, that would block the transmision path.
I scheduled a sleep of 100ms before trying again, in a loop but the loop was not ended. I tried for several seconds before I eventually killed the process.
What puzzles me is that sometimes the sending runs for minutes (before I intentionally stop), and at other times it fails early. The load of the PC is the same in both circumstances.
