Re: XB 200 - Firmware Update
Posted: Sun Jul 20, 2014 12:45 pm
Hi Simon,
I think that switching to the sync interface would be a great idea, even if the async i/f was working fine for the following reasons:
It's simpler to use and maintain.
If you don't need to really have full control over buffer management for very low-latency, the extra complexity doesn't buy you much. The sync interface spawns a worker thread under the hood to take care of all the buffer management. You can just call it and receive and arbitrary number of samples.
It's more foregiving.
With the async interface, you cannot do any heavy processing or major I/O in the callbacks without risking losing samples, especially with higher sample rates. With the sync interface, you have N buffers worth of time to read out and process your data before you hit an overrun.
With respect to the async issues you're seeing...
The major changes since the last version you were using largely consisted of holding a per-device lock while executing a callback, which would prevent two simultaneous RX or TX callbacks from occurring during full-duplex operation.
Are you doing any substantial processing or other operations in the callbacks? I'm wondering if you just happened to have ample time previously, but the aforementioned change someone resulted in a smaller window of time? Based upon the screenshot and obeservations you shared...it really sounds like the symptoms I've seen where buffers are getting dropped.
The wiki describes a way to use the CLI to check for dropped samples by having the FPGA replace samples with a 32-bit counter value, as Brian noted. This might be a good "sanity check" to perform along with the other tests I mentioned a few posts back.
Note that the sync interface is built atop of the async interface -- if there's something very wrong with the async interface, the former will not work. Any info (e.g., verbose logs) you can provide from async failures would help us to diagnose issues that we may not be currently exposing in our tests.
Lastly, I apologize if you feel that we're not giving you enough time this weekend, and can understand any frustration. We're really trying to squeeze 50 hours into 48 in order to get some tasks completed and work toward a stable release. If you continue having problems, one or more of us devs can schedule a Skype call sometime next week. (Bear in mind, a number of us work dayjobs until 6-7 Eastern Time, so we'll probably need to set up something in the early morning for us, or very late for you.)
With that said, I personally find that I can generally only be useful and helpful when I'm given sufficient information to review and understand ahead of time, such as verbose logs, code snippets, etc.
Best regards,
Jon
I think that switching to the sync interface would be a great idea, even if the async i/f was working fine for the following reasons:
It's simpler to use and maintain.
If you don't need to really have full control over buffer management for very low-latency, the extra complexity doesn't buy you much. The sync interface spawns a worker thread under the hood to take care of all the buffer management. You can just call it and receive and arbitrary number of samples.
It's more foregiving.
With the async interface, you cannot do any heavy processing or major I/O in the callbacks without risking losing samples, especially with higher sample rates. With the sync interface, you have N buffers worth of time to read out and process your data before you hit an overrun.
With respect to the async issues you're seeing...
The major changes since the last version you were using largely consisted of holding a per-device lock while executing a callback, which would prevent two simultaneous RX or TX callbacks from occurring during full-duplex operation.
Are you doing any substantial processing or other operations in the callbacks? I'm wondering if you just happened to have ample time previously, but the aforementioned change someone resulted in a smaller window of time? Based upon the screenshot and obeservations you shared...it really sounds like the symptoms I've seen where buffers are getting dropped.
The wiki describes a way to use the CLI to check for dropped samples by having the FPGA replace samples with a 32-bit counter value, as Brian noted. This might be a good "sanity check" to perform along with the other tests I mentioned a few posts back.
Note that the sync interface is built atop of the async interface -- if there's something very wrong with the async interface, the former will not work. Any info (e.g., verbose logs) you can provide from async failures would help us to diagnose issues that we may not be currently exposing in our tests.
Lastly, I apologize if you feel that we're not giving you enough time this weekend, and can understand any frustration. We're really trying to squeeze 50 hours into 48 in order to get some tasks completed and work toward a stable release. If you continue having problems, one or more of us devs can schedule a Skype call sometime next week. (Bear in mind, a number of us work dayjobs until 6-7 Eastern Time, so we'll probably need to set up something in the early morning for us, or very late for you.)
With that said, I personally find that I can generally only be useful and helpful when I'm given sufficient information to review and understand ahead of time, such as verbose logs, code snippets, etc.
Best regards,
Jon
