USB Bulk Transfer inside native PostFrame Callback reduces latency and jitter

[AdrianTunkin]

Observation:
Calling usb_device_bulk_transfer() inside AChoreographer_postFrameCallback_ (executed in a native, detached thread) significantly reduces both the delay and jitter of the frame callback itself.
This was measured by comparing the timestamp of the frame event (frameTimeNanos) and the actual execution time (clock_gettime(CLOCK_MONOTONIC)), with and without the USB transfer.

Setup:

1. NDK version "28.2.13676358"

2. From Java (JNI), I start a native thread (not UI) using pthread_create.

JNIEXPORT void JNICALL // Function to start native Flinger USB Daemon in separate thread
Java_com_holoshader_holoplayer_JavaToNativeLayer_startFlingerUsbDaemon(jint jfd) {
  if (is_daemon_started) return;
  is_daemon_started = true;
  efd = jfd;
  pthread_attr_init(&tattr);
  pthread_attr_setdetachstate(&tattr,PTHREAD_CREATE_DETACHED);
  pthread_create(&flingerUsbDaemon_thread, &tattr, flingerUsbDaemon, &efd); // run callbacks in separate thread
}

3. Inside this thread, I create an ALooper and bind AChoreographer_postFrameCallback.

void * flingerUsbDaemon(void *pfd) {
  mLooper = ALooper_forThread();
  if(mLooper == nullptr) mLooper = ALooper_prepare(0); // Firstly create Alooper for current thread needed by Choreographer

  if (!mLooper) {
    pthread_exit(nullptr);
  }
  ctx = usb_host_init();
  if (ctx == nullptr) {
    hard_exit(1);
  }
  // create usb device
  int ifd = *((int *) pfd);
  dev = usb_device_new("3D Dongle", ifd);
  if (dev == nullptr) {
    hard_exit(1);
  }

// [USB setup omitted] ... USB initialization and descriptor parsing ... 


  loadFunctions(); // Native Choreographer API is supported in API level 24+.
  StartChoreographer();

  while(is_daemon_started && ctx != nullptr){
    ALooper_pollOnce(-1, nullptr, nullptr, nullptr);
  }
  if (ctx != nullptr) { // clear USB resources
    usb_host_cleanup(ctx);
  }
  pthread_exit(nullptr); // stops only current thread (while keeping working parent threads and processes)
}

4. The callback runs every frame and optionally performs a USB bulk transfer to a device (commented lines).

void choreographer_callback(long frameTimeNanos, void *) {
  if(!is_daemon_started) return;

  long usb_start_time, usb_end_time;
  timespec usb_start_time_ts{}, usb_end_time_ts{};

  call_period = frameTimeNanos_prev == 0 ? 8333333L : (frameTimeNanos - frameTimeNanos_prev); // call period in nanos
  frameTimeNanos_prev = frameTimeNanos;

  clock_gettime(CLOCK_MONOTONIC, &usb_start_time_ts);
  usb_start_time = timespec_to_nanos(usb_start_time_ts);
  long callback_delay = usb_start_time - frameTimeNanos; // in nanos, how current callback is delayed from the real callback event

//  char buf_send[8] = {};
//  sprintf(buf_send, "1:%ld", 1000L);
//  if(ctx != nullptr) usb_device_bulk_transfer(dev, 1, buf_send, sizeof(buf_send), 3);

  clock_gettime(CLOCK_MONOTONIC, &usb_end_time_ts);
  usb_end_time = timespec_to_nanos(usb_end_time_ts);
  
  LOGI("TEST: call_period = %jd  callback_delay = %jd usb_delay = %jd", call_period, callback_delay, usb_end_time - usb_start_time);

  AChoreographer_postFrameCallback_(choreographer, choreographer_callback, data_stub);
}

If USB bulk transfer IS NOT called - delay and jitter are higher. Values in nano seconds, second parameter callback_delay ~ 0.6 - 0.7ms
Here is log:

06:27:30.262  I  TEST: call_period = 8330857  callback_delay = 731712 usb_delay = 77
06:27:30.270  I  TEST: call_period = 8330392  callback_delay = 610299 usb_delay = 0
06:27:30.278  I  TEST: call_period = 8330467  callback_delay = 604448 usb_delay = 0
06:27:30.287  I  TEST: call_period = 8332241  callback_delay = 615284 usb_delay = 230
06:27:30.295  I  TEST: call_period = 8330950  callback_delay = 609795 usb_delay = 0
06:27:30.303  I  TEST: call_period = 8330912  callback_delay = 597652 usb_delay = 77
06:27:30.312  I  TEST: call_period = 8329603  callback_delay = 608742 usb_delay = 231
06:27:30.320  I  TEST: call_period = 8331809  callback_delay = 793685 usb_delay = 0
06:27:30.328  I  TEST: call_period = 8329742  callback_delay = 624345 usb_delay = 77
06:27:30.337  I  TEST: call_period = 8329634  callback_delay = 622788 usb_delay = 0
06:27:30.345  I  TEST: call_period = 8330229  callback_delay = 619866 usb_delay = 77
06:27:30.353  I  TEST: call_period = 8331455  callback_delay = 620104 usb_delay = 76
06:27:30.362  I  TEST: call_period = 8331650  callback_delay = 631223 usb_delay = 0
06:27:30.370  I  TEST: call_period = 8330337  callback_delay = 616963 usb_delay = 0
06:27:30.378  I  TEST: call_period = 8330398  callback_delay = 611411 usb_delay = 77
06:27:30.387  I  TEST: call_period = 8331039  callback_delay = 654910 usb_delay = 0

If USB bulk transfer IS called - delay and jitter are lower. Values in nano seconds, second parameter callback_delay ~ 0.2 - 0.3ms
Here is log:

06:35:07.001  I  TEST: call_period = 8330598  callback_delay = 303276 usb_delay = 94846
06:35:07.009  I  TEST: call_period = 8330066  callback_delay = 261825 usb_delay = 111154
06:35:07.018  I  TEST: call_period = 8329420  callback_delay = 253328 usb_delay = 96616
06:35:07.026  I  TEST: call_period = 8330498  callback_delay = 257676 usb_delay = 97231
06:35:07.034  I  TEST: call_period = 8329878  callback_delay = 265875 usb_delay = 97616
06:35:07.043  I  TEST: call_period = 8330716  callback_delay = 260082 usb_delay = 103385
06:35:07.051  I  TEST: call_period = 8330679  callback_delay = 251327 usb_delay = 92000
06:35:07.059  I  TEST: call_period = 8330331  callback_delay = 240072 usb_delay = 99077
06:35:07.068  I  TEST: call_period = 8331145  callback_delay = 260004 usb_delay = 91308
06:35:07.076  I  TEST: call_period = 8330121  callback_delay = 261806 usb_delay = 100693
06:35:07.084  I  TEST: call_period = 8330436  callback_delay = 257294 usb_delay = 99615
06:35:07.093  I  TEST: call_period = 8329830  callback_delay = 248694 usb_delay = 98770
06:35:07.101  I  TEST: call_period = 8330036  callback_delay = 258274 usb_delay = 99692
06:35:07.109  I  TEST: call_period = 8330596  callback_delay = 287678 usb_delay = 105923
06:35:07.118  I  TEST: call_period = 8330188  callback_delay = 262720 usb_delay = 97539
06:35:07.126  I  TEST: call_period = 8329481  callback_delay = 414163 usb_delay = 129538
06:35:07.134  I  TEST: call_period = 8329302  callback_delay = 253168 usb_delay = 64693
06:35:07.143  I  TEST: call_period = 8333911  callback_delay = 281103 usb_delay = 64923
06:35:07.151  I  TEST: call_period = 8332533  callback_delay = 303109 usb_delay = 97538

5. Conclusion:
   In an isolated thread using AChoreographer_postFrameCallback_, I measured callback delay (how late the callback runs relative to vsync). The results are:

• With usb_device_bulk_transfer() inside the callback: Average delay ≈ 260,000 ns (0.26 ms), tight jitter.
  

• Without any USB call inside the callback: Average delay ≈ 620,000 ns (0.62 ms), jitter up to 0.79 ms.
  

This is counterintuitive. One would expect a blocking USB call to increase delay, but it significantly improves timing instead. Possibly due to thread/CPU warm-up, cache effects, or internal scheduler behavior triggered by I/O. Further insights are welcome.

Additional Info:

1. I also tested USB HID interrupt transfers inside the choreographer callback, but they did not reduce the callback delay or jitter. Only USB bulk transfers had a measurable effect on improving timing stability.
2. Replacing USB bulk transfer with usleep() (same duration) had no timing improvement. The effect appears specific to the USB bulk operation, not just timing delay.

[DanAlbert]

I'm not really sure what to do with this. If you want to report a bug in system behavior, go to https://b.android.com and file against the OS, probably the Framework component, or maybe System? The NDK only describes the interfaces of the OS, it doesn't define any of the behavior.

Or is this just an observation and you're not looking for any help from me?

[AdrianTunkin]

Dear, Dan.
It's an interesting feature that I'm actually using to achieve more precise timings.
I was just curious about what causes it. Wanted to get some explanation

[AdrianTunkin]

I found a phone where bulk transfer doesn't improve the latency. So the issue is probably on the system side — maybe related to the SoC hardware, USB driver, or OS-level behavior.

[enh-google]

yeah, this is not unexpected ... it's common for usb activity to clock the cpu higher for reduced irq latency (for better usb performance). this, obviously, has side-effects for other code.