So I’ve implemented the Android USB Accessory API such that I can plug in my phone to my laptop running linux and it puts the phone into USB Accessory mode. Then I can access the accessory, open it, and begin reading an writing to it. My code looks almost identical to the example in the documentation. The main difference is that I’m using separate read and write methods and accessing them via JNI from native code.
Here’s where it gets interesting. After successfully reading/writing for a second or two, the bulk transfer writes from my laptop starts giving timeout errors and then the read call to the USB Accessory in Android throws an IOException with the ENODEV error code. This is with the cable still connected and UsbManager still lists the Accessory in the list, and I still have permission for it.
To add to the oddness of it, I discovered that if I put a 100ms sleep in the read loop, the problem basically goes away (though it still happens on occasion). Having the sleep in there is not just a horrible kludge, but it introduces an intolerable latency into my app. The lower the sleep time, the less effective the hack is, to where it’s ineffective at 10ms of sleep time.
I’m transmitting around 20-30kbps of real-time data using bulk transfers (but not so real-time that a bulk transfer won’t suffice), and the transfer size ranges from 50 to 800 bytes at about 20-30Hz. Could it be a limitation of USB? I don’t have a ton of experience with it, so I’m basically treating it about the same as a network socket. Should I queue up smaller messages and send them off together in less frequent but larger transfers? Is there a problem with small, high-ish frequency bulk transfers? I’ll look into this, but I’m basically grasping at straws here.
Hardware:
- Laptop is running Ubuntu 10.04 and using libusb 1.0.0.
- Phone is Galaxy Nexus S running stock Android 4.1.2.
So, while I still don’t understand everything that is going on, implementing a double-buffering scheme fixed my problem.
I discovered that a Java Android App reading at full speed had no issues with the ENODEV problem, which lead me to the conclusion that the Java Native Interface was the root of my problems.
Previously, I was reading from the UsbAccessory directly from methods called from the JNI in a polling fashion. Something about the transition from native code to Java and then from Java down to the native Android kernel apparently made everything grumpy.
My fix was to read/write to the UsbAccessory from Java-only threads (no JNI calls) and then buffer that data to read/write from the methods called by JNI.
Seems to work like a charm. Before I was getting send timeouts very consistently on the accessory side, and then eventually the IOExeception on the Android side as outlined above, and now I get no timeouts, no IOExceptions. I’m still a little curious what exactly causes that behavior, but I suspect it requires strong JNI Kung-fu to understand.