I am trying to get highly accurate time stamping of the audio stream and jitter seems to be a problem. I need 1 millisecond or lower delay between the time stamps of two devices running the “mic_record_file” example. The two devices are synchronised according to IEEE 1588 PTP. I placed my time request (chrono::high_resolution_clock) above the microphone_array.read() function. I believe a RT patch will solve this problem. Otherwise, any help appreciated.
One of our hardware engineers looked into a bit and seems to think preempt_rt can’t achieve that resolution. However, he believes a timer in the FPGA could potentially help you there.
Feel free to take a look and ask more questions. In the meantime, we’ll ask our hardware team for pointers on this.
I would much appreciate the pointers on FPGA timer.
However, I am curious if a preempt_rt can be be achieved with the matrix kernel modules. I have tried a few times but it seem to fail when compiling from sources according to the guide here
When does the microphone collect the first sample? From what I understand, the .read() function reads a delayed buffer. Therefore, time stamping before the read() function may not necessarily be the timestamp of the first sample. I also time stamped the beginning and the end of the file which on average come out to be 10.20s where it should be 10.24s. What may be the cause of this?
@Samreen I am a beginner in FPGA and had no luck with it. Are you still chasing the hardware team for pointers?
Apologies for the delayed response.
Could you clarify the question about the time stamp? Why should it be 10.24s?
The hardware team said a counter must be written in Verilog and connected to the wishbone bus. I am also an FPGA beginner but I found these posts here and here about writing counters that could be helpful.
All of our components are connected to the wishbone, seems they have some setup in system.v and then each component is connected through the files in each of their folders here. Maybe you can draw parallels from there with a
If you fork our MATRIX Creator FPGA code and add/make edits to the code, I will see if our hardware engineers can take a look over to see if it generally makes sense.