Latency Issues?

Questions and discussions about the Xillybus IP core and drivers

Latency Issues?

Postby DeltaLux »

Vivado 2016.2
Ubuntu 16.04.1
AC701

Custom IP core utilizing 2 separate dual access memory.
1) bulk data
2) control data


Basically, I am trying to make a low latency sound card using xillybus. Total data rate of data written to the FPGA is 0.7056 MB/s, but I am trying to write 8192 Byes at 86 Hz intervals. In terms of audio programming this chuck of data (8192 Bytes) is considered a "period". On the FPGA, I store 2 periods worth of data. The C-program sits in a loop reading control_data until it signals more data is needed (4 Bytes at a time, basically just increments this 32 bit number when done with a period (half of the 2 periods of storage)). The problem is that sometimes it isn't fast enough and completely misses a few periods before more data is written. The FPGA continuously loops through the 2 periods, so if data isn't written in time it will re-read over old data. Completely unacceptable for my application. At worst a missed period per hour would be ok.

Any help or suggestions would be greatly appreciated. Also, I am not necessarily sure if the problem is xillybus per se, but I need help determining the root of the problem.

Thank you,

Richard
DeltaLux
 
Posts: 4
Joined:

Re: Latency Issues?

Postby support »

Hello,

I suppose this is a follow-up on this post:

viewtopic.php?f=4&t=464

I would, again, suggest to work with FIFOs as I suggested in the previous post. In order to keep control on the latency, I would suggest maintaining a counter of the number of samples (not chunks) that have been consumed by the FPGA, and keep reading that one instead. This way, the software can compare how much it has sent vs. how much has been consumed, and always have a view on how much is buffered. Needless to say, this counter must be reset when the respective stream is closed (easily done using the *_open ports exposed by Xillybus).

The easy way is to connect this counter to a 32-bit stream's data input port, tie that port's "empty" line to zero, and ignore all other ports. Making sure the stream is synchronous (setting the use to e.g. "Short message transport"), when 4 bytes are read from the stream, they reflect the current situation of the counter. I suppose this is what you did.

Now all the software needs to do, is to read the counter's value, and write the number of samples that maintain the desired buffering amount.

As for avoiding delays in the PC-to-FPGA stream, make sure it's asynchronous, and use zero-write calls to push the data towards the FPGA. See http://xillybus.com/doc/xillybus-latency

When done this way, the only possible reason for drop-outs is CPU starvation on your C program. If you're running it on a fullblown Linux system, there are all kind of things that can happen that may halt your execution. Even silly things, such as status messages on the console for debugging, which are prevented from being written because they go to a console window, which is in turn frozen by some desktop graphics effect being stuck for a short while.

Regards,
Eli
support
 
Posts: 802
Joined:

Re: Latency Issues?

Postby DeltaLux »

So exactly how does one write data without any write calls?
DeltaLux
 
Posts: 4
Joined:

Re: Latency Issues?

Postby support »

Of course there must be write calls. I don't see where that idea came from.

Maybe the term "zero-write calls" was confusing? This refers to a write call with zero bytes, which is a signal to push the data already written with regular write() calls immediately towards the FPGA (and not wait 10 ms if a DMA buffer is partially filled).

Regards,
Eli
support
 
Posts: 802
Joined:


Return to Xillybus

cron