Yeah one approach is that BLE-Gamepad library supports gpio pins as button inputs, so in theory I could get a baseline of what the Bluetooth stack of the library is by soldering the jst connector to connect the Arduino (that triggers the button presses and measures the result from the Mister SNAC port).
Otherwise I'd basically have to develop my own controller code to port onto various Bluetooth stacks for testing, but that seems like more than I want to do right now.
Without more testing it's hard to say. I don't want say it's the hardware without proof, but would require a much deeper dive into esp32 and c++ than I want to do right now.
It's really hard to judge without additional testing, I'm always more likely to blame my code than hardware. My guess would be something in the stack, be it my code or the library that puts it above a frame but that kind of investigation is more than I want a hobby project to be.
18ms is okay but for a lot of retro content, it's running 60fps. That means it's one frame is 50/3ms, aka 16.6666ms. Sub 1 frame is good enough, 18ms is not in my opinion.
There probably could be some optimization in the translation, such as passing the controller object as a reference when checking the state of the buttons, rather than doing two loops to read the state and act on it. But I doubt that is the source of the largest latency since this is compiled to run at 240mhz (I did some additional testing at 80 as well, about the same results). I'm using a d1 mini off alliexpress so not the highest quality but I wouldn't expect a huge performance hit.
So in this case it's my own code to read the state of the controller and using the ble-gamepad library, which uses NimBLE under the hood. There could be some optimizations but getting to be under 10ms probably is going to use a lot of time I could just be playing games.
Inside