Callback from native Java to Unity's C# script has some weird (latency?) issue

I'm developing a Unity plugin that uses BLE to communicate with some device. I have implementation for both Windows (using P/Invoke to this device's SDK) and Android, which uses Unity's helper classes for interfacing with the JVM. The device's SDK in Java has a callback for incoming new data, the callback looks like this:

 @Override
 public void onDeviceData(BluetoothDevice device, byte[] data) {
     
 }

I've implemented a class that inherits Unity's AndroidJavaProxy to register a callback handler from the C# side:

 class Callbacks : AndroidJavaProxy
 {
     ConcurrentQueue<byte[]> IncomingMessages { get; private set; }

     public Callbacks()
         : base("com.example.sdk.SdkCallbacks")
     {
         IncomingMessages = new ConcurrentQueue<byte[]>();
     }

     void onDeviceData(AndroidJavaObject device, byte[] data)
     {
         IncomingMessages.Enqueue(data);
     }
 }

I have a script in the scene that deques this data in the Update() function like so:

 while (!_device.IncomingMessages.IsEmpty)
 {
     byte[] data;

     if (_device.IncomingMessages.TryDequeue(out data))
     {
         // do something with the data
     }
 }

In my specific case I'm using the data coming from the device to move a point on the screen (think "wireless mouse").

That works pretty well, until I need to get high-rate data from the device (About ~60 callbacks per second with the data parameter containing an array of ~30 bytes). At first everything looks okay, but after a few seconds the point starts to lag heavily behind the actual input from the device, and the lag only gets bigger with time.

I've tried checking if the IncomingMessages queue is getting too big which would mean the producer outpace the consumer by a lot, causing an ever-increasing delay, but that was not the case, IncomingMessages.Count always shows 0-2.

This does not happen when running the code on Windows and using the device's SDK from a regular Android app also works well.

Can this be a marshaling overhead between the JNI and the CLR runtimes? Or something similar?

If so, is there anything I can do about it? I know Unity has another way of communicating between native and the scripting runtime with UnitySendMessage but I'm not sure if that won't have the same problem.