Delayed frames income with v4l2 and libArgus

I am tracking timings for my incomings frames. I am not doing any processing of frames, but still frames captured come in late (not very often, but it happens). I need to do some time-sensitive operation after I got a frame (what can have -0.5ms/+0.5ms variety, no problem) but I see big jumps, even 3ms.

This happends with v4l2 but also with libargus api.

I tried to set priority with “nice” but it didnt help out on this.
Do you have any explanation and maybe even a solution to this?

I made a graph that shows the timing between the actual and the last frame, which should be around 17500microseconds (since I am using slightly slower fps than 60).


Best regards,

1 Like

Maybe print the SOF from vi5_fops.c to confirm the frame coming consistently.

I can confirm that printing sof in vi5_fops.c, the difference in frame income is 2 microseconds max. So at this point, everything works fine. Any idea what can delay frames on the way to userspace?

Try boost the system to check.

sudo nvpmodel -m 2
sudo jetson_clocks
sudo su
echo 1 > /sys/kernel/debug/bpmp/debug/clk/vi/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/isp/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/nvcsi/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/emc/mrq_rate_locked
cat /sys/kernel/debug/bpmp/debug/clk/vi/max_rate |tee /sys/kernel/debug/bpmp/debug/clk/vi/rate
cat /sys/kernel/debug/bpmp/debug/clk/isp/max_rate | tee  /sys/kernel/debug/bpmp/debug/clk/isp/rate
cat /sys/kernel/debug/bpmp/debug/clk/nvcsi/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/nvcsi/rate
cat /sys/kernel/debug/bpmp/debug/clk/emc/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/emc/rate

echo userspace > /sys/devices/13e10000.host1x/15340000.vic/devfreq/15340000.vic/governor

echo 1 > /sys/kernel/debug/bpmp/debug/clk/vic/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/vic/state
cat /sys/kernel/debug/bpmp/debug/clk/vic/max_rate > /sys/kernel/debug/bpmp/debug/clk/vic/rate

No difference. The problem remains. I had most of these settings also on with the original test.
(jetson_clocks and MAXN mode and VIC high frequency)

Any ideas on how we can continue? Could you reproduce the problem? Do you see the possibility that this issue is fixed with real-time Linux kernel on the newest Jetpack release?

I would suggest try J5.0.2 due to the capture firmware different a lot.


I found out, that I do not have this problem capturing with MMAP instead of USERPTR. Any idea why? Will test if I can get the same low latency with MMAP as with USERPTR.