So, I've been running some tests trying to see why my Unity scene with one moving cube on one plane still feels sluggish when I'm playing it on the Ouya. I'm using the newest version of the Unity plugin from github, using Unity's Input API, and I'm not using legacy input. I don't have a high-framerate camera, so for testing I used audio.
I set up a simple scene with an audio sample and a listener, and set the audio (a generated middle C tone) to go off 500ms after either the press of a keyboard button or the Ouya controller's primary joystick hitting 1.0 on one axis. I tested by recording the sound of me hitting the key/joystick, and measuring the time to the tone, and then subtracted 500ms. (I originally had the audio sample play immediately, but I'd read that using PlayDelayed() would queue the audio and play it at an exact time. Unfortunately it did not, but the results in comparison the my PC's response time are the same either way.)
After several tries, here are the average response times:
Now, I think I can attribute the original 154ms of the PC to the fact that playing audio at an exact time is something that's just hard. If I had that camera, I'd give Unity the benefit of the doubt and say it could probably draw something on the screen faster than that in response to input. I did set Unity's audio settings to "best latency," but maybe there's some other settings or method of playing audio I'm missing that would reduce this time.
What I'm having trouble with is the Ouya taking 67ms longer to respond to the exact same input from the same wired keyboard in the same scene. On top of that, introducing the Ouya's wireless controller adds another 58ms of lag, for a total of an extra 125ms. The joystick test is even a little generous, because the value of the axis hits 1.0 before the stick clashes against the rim.
I understand some strides have been made recently in reducing input latency, and I really hate to be a downer since you've just made an improvement, but is this still something that's being actively worked on? Is this as good as it's going to get? Is it something inherent in using Android?
Or maybe I'm just doing something wrong; I would love it if I am, because to me this is still a pretty unacceptable amount of input lag. Is anyone else experiencing this?
Not yet, I will run some more tests tonight. All my 360 controllers are wireless, but I do have the usb adapter for that so I can get that going. I've got to break out my laptop, which has a bluetooth adapter, so I can test the PS3 and Ouya controller with it. I would expect the PS3 controller to have a response time similar to the Ouya controller, given that they're both bluetooth, but we'll see.
Also, that scene in the video runs at pretty constant 22fps on my ouya, and the input lag also still seems to be present there as well. I've seen you mention before that you had it running at 60fps; was that on the ouya or another device/in the editor?
I just added PS3 times, and they pretty much the same as the keyboard times, the most surprising part being that the PS3 controller has an almost identical response time wired and wireless. Which leaves me to wonder why the Ouya's controller takes so much longer when it also communicates over bluetooth.
You never answered my question, though: is input response time still something that's being worked on, in the Unity plugin or otherwise? I really want this console to succeed, and I want to develop games for it, but I also want to know that its problems are being resolved. This is one problem that the Ouya seems to get a lot of (in this case justified) criticism for, and unlike some other potential issues, it's one you guys have control over.
There is something we can try from the Unity game engine. But you need the latest 4.1.4 and then we need to run Unity as a native activity. That requires some android.manifest and OuyaUnityApplication.java changes. The result is the lowest latency we can get out of the engine.
That sounds promising, I'd love to give it a try when it's available. I actually did not know an update past 4.1.3f3 was out yet, but now that I look I can see 4.1.5 is available, so I'll grab that, and I've already got the NDK installed.
Hey can I get a link to your test APK. I have access to run it on the engineering build and we can check for latency. If you want to zip up your whole test Unity project and send it to me, I wouldn't mind. :)
Definitely, I'll send it right over! It's a really simple scene and project, cube moves around to raw joystick axis data and beeps after a delay when you press the right arrow or right on the joystick. But I figured that was enough to test for latency, since the sound goes off at a known time, and you can easily see when the cube reaches its edge vs. when you reach the edge of the joystick.
Thanks, I'm glad to hear it's a high priority! I wish I could figure out why Unity won't play a sound at an exact time to make it more accurate in determining the amount of lag caused by the OS, but it still gives some useful data this way too.
I read in another thread that your latest controller firmware eliminates axis snapping, so it seems like you're no longer processing any input on the controller before sending it. Does this help bridge that gap in response time between the Ouya controller and the PS3 controller, or is that another issue?
I sent you the link to a zip on my Dropbox in a pm, did it not show up? Sorry I'll try your email instead.
I would think so too, but I can't seem to get it to happen that way. On my PC, if I set the cube to move on a key press and set the sound to play at the same time, you can definitely tell the cube is moving before the sound plays, and it's 154ms after the key is actually pressed .
That sounds like it would work perfectly, setting the volume's gotta be a much faster operation than Play(). I'll set that up when I get home from work to tonight and see what kind of results I can get, because that would hopefully rule out any chance that the android build of the unity engine is just slower to start playing an audio sample than the PC build.
Seeing something happen instantly is so subjective though. :P That's why I wish I had a high speed camera to capture the actual delay between input and draw time, but I think your idea with setting the volume will work just as well.
If the response time of the wired keyboard turns out to be the same between ouya build and pc build, the only thing left to fix will be the ouya controller's latency, which I can definitely feel while just watching that cube move around.
Alright well, after using that code, and some tweaks to it, I still can't get it to play back sound, or even adjust the volume on an already playing clip anywhere near instantly. On the PC it still takes about 154ms, and 212ms on the OUYA. So, I don't think I can actually be sure how much of that gap is just how long Android takes to process a change in sound vs my PC, or how much of it is caused by the Ouya/using the SDK vs NDK, etc. If you do get a version of the Unity plugin going that builds native, I would love to test it and see if it reduces that gap.
At this point though the only thing I can really be certain of is that the OUYA's wireless controller is about 60ms slower than another bluetooth controller.
I was thinking maybe play a certain low pitch when the stick is at the origin and high pitch at the edge. That way in the recording you can do a precise measurement.
Changing the pitch seems to suffer from the same delay, unfortunately.
It seems like any change I make to the audio will always have that.
Which is weird, I feel like I'm still missing something with this. How
would you make an accurate rhythm game with a constant 150ms delay in playing sounds? I
mean I've used sound in Unity before but I guess I've never measured
that gap until now.
aust
Posts: 13Member
Comments
OUYA Inc | Android Developer
Skype: tgraupmann_prey
http://github.com/ouya/docs
http://github.com/ouya/ouya-sdk-examples
Check out the latest docs for your game engine: [setup] [adobe air] [android] [clickteam fusion] [construct 2] [corona] [libGDX] [game maker] [html5] [marmalade] [monogame] [unity] [unreal]
Use caution when setting [persistent wireless mode].
OUYA Inc | Android Developer
Skype: tgraupmann_prey
http://github.com/ouya/docs
http://github.com/ouya/ouya-sdk-examples
Check out the latest docs for your game engine: [setup] [adobe air] [android] [clickteam fusion] [construct 2] [corona] [libGDX] [game maker] [html5] [marmalade] [monogame] [unity] [unreal]
Use caution when setting [persistent wireless mode].
You never answered my question, though: is input response time still something that's being worked on, in the Unity plugin or otherwise? I really want this console to succeed, and I want to develop games for it, but I also want to know that its problems are being resolved. This is one problem that the Ouya seems to get a lot of (in this case justified) criticism for, and unlike some other potential issues, it's one you guys have control over.
OUYA Inc | Android Developer
Skype: tgraupmann_prey
http://github.com/ouya/docs
http://github.com/ouya/ouya-sdk-examples
Check out the latest docs for your game engine: [setup] [adobe air] [android] [clickteam fusion] [construct 2] [corona] [libGDX] [game maker] [html5] [marmalade] [monogame] [unity] [unreal]
Use caution when setting [persistent wireless mode].
OUYA Inc | Android Developer
Skype: tgraupmann_prey
http://github.com/ouya/docs
http://github.com/ouya/ouya-sdk-examples
Check out the latest docs for your game engine: [setup] [adobe air] [android] [clickteam fusion] [construct 2] [corona] [libGDX] [game maker] [html5] [marmalade] [monogame] [unity] [unreal]
Use caution when setting [persistent wireless mode].
I read in another thread that your latest controller firmware eliminates axis snapping, so it seems like you're no longer processing any input on the controller before sending it. Does this help bridge that gap in response time between the Ouya controller and the PS3 controller, or is that another issue?
OUYA Inc | Android Developer
Skype: tgraupmann_prey
http://github.com/ouya/docs
http://github.com/ouya/ouya-sdk-examples
Check out the latest docs for your game engine: [setup] [adobe air] [android] [clickteam fusion] [construct 2] [corona] [libGDX] [game maker] [html5] [marmalade] [monogame] [unity] [unreal]
Use caution when setting [persistent wireless mode].
I would think so too, but I can't seem to get it to happen that way. On my PC, if I set the cube to move on a key press and set the sound to play at the same time, you can definitely tell the cube is moving before the sound plays, and it's 154ms after the key is actually pressed .
OUYA Inc | Android Developer
Skype: tgraupmann_prey
http://github.com/ouya/docs
http://github.com/ouya/ouya-sdk-examples
Check out the latest docs for your game engine: [setup] [adobe air] [android] [clickteam fusion] [construct 2] [corona] [libGDX] [game maker] [html5] [marmalade] [monogame] [unity] [unreal]
Use caution when setting [persistent wireless mode].
OUYA Inc | Android Developer
Skype: tgraupmann_prey
http://github.com/ouya/docs
http://github.com/ouya/ouya-sdk-examples
Check out the latest docs for your game engine: [setup] [adobe air] [android] [clickteam fusion] [construct 2] [corona] [libGDX] [game maker] [html5] [marmalade] [monogame] [unity] [unreal]
Use caution when setting [persistent wireless mode].
If the response time of the wired keyboard turns out to be the same between ouya build and pc build, the only thing left to fix will be the ouya controller's latency, which I can definitely feel while just watching that cube move around.
OUYA Inc | Android Developer
Skype: tgraupmann_prey
http://github.com/ouya/docs
http://github.com/ouya/ouya-sdk-examples
Check out the latest docs for your game engine: [setup] [adobe air] [android] [clickteam fusion] [construct 2] [corona] [libGDX] [game maker] [html5] [marmalade] [monogame] [unity] [unreal]
Use caution when setting [persistent wireless mode].
At this point though the only thing I can really be certain of is that the OUYA's wireless controller is about 60ms slower than another bluetooth controller.
OUYA Inc | Android Developer
Skype: tgraupmann_prey
http://github.com/ouya/docs
http://github.com/ouya/ouya-sdk-examples
Check out the latest docs for your game engine: [setup] [adobe air] [android] [clickteam fusion] [construct 2] [corona] [libGDX] [game maker] [html5] [marmalade] [monogame] [unity] [unreal]
Use caution when setting [persistent wireless mode].