We've been hearing a lot lately from some of you who aren't getting the results you feel you should when using Triggertrap Flash Adapter. The most common problem is that the flash is firing well after your balloon has popped or splash has settled. The truth of the matter is, this is no fault of your own. It's just not quite possible. Let's try to explain why.
How the audio buffer in smart devices works
The sound trigger needs to do two things: it listens for the sound (of course), then it sends a trigger signal to the dongle. Triggertrap Mobile sends this as a coded audio signal. This means we have both an audio input and an audio output whenever we trigger.
Audio output on both iOS and Android uses a buffer. This is essentially a queue of audio data, representing a fraction of a second of sound. Generated audio is fed in one end, then sent out of the other as it's played. The reason that the OS does this is to avoid glitches when playing. If something briefly interrupts the audio, there's still enough data in the buffer to keep playing uninterrupted. It's a bit like how skip protection used to work on old CD players, but much shorter.
The downside to this is that there is a slight delay when we first start playing, while the buffer is filled. This isn't a problem in most situations: you won't notice a hundred millisecond or so delay when you start playing an mp3, but it's a big deal for cases like ours where we need a quick response. A 100ms buffer would mean that when we send the trigger signal, we have to wait 100ms for it to make its way through the buffer - a lifetime in the world of high speed photography.
How it works on iOS
Apple's iOS lets developers request a smaller buffer size. However this is just a request, and for various reasons the OS may not grant one that's the size you request. There doesn't seem to be a pattern to whether it grants it, but it seems to allow smaller buffers more often for newer devices (which makes sense). We request the shortest possible buffer for the sensor modes, but longer buffers for other modes to avoid glitches when taking long exposures. If iOS is being generous, we can get buffer sizes of around 2ms. If we're unlucky, they're around 20-25ms. The audio input is very fast, so it's not a bottleneck, and so this translates to trigger times of less than 5ms if we're lucky, and around 25ms if we're not. This is still a lot faster than the old version of Triggertrap for iOS before our speed improvements in June, which was was taking a frankly epic 60ms to trigger.
How it works on Android
Android works a little differently, but the concepts are similar. We still have the buffer, but Android is far less compliant when it comes to sizes. In most cases it won't give a buffer any shorter than hundreds of ms.
This seems to be because of the way tasks are scheduled in Android, meaning audio isn't given as high a priority as it needs for small buffers to be usable. Add to this an input buffer that's over 50ms in many cases. This means that even in a best case scenario we're unlikely to get latencies of much under 100ms.
So, what's the problem?
The old version of the app (before we made the big speed improvements) was getting around 60ms, and some of our favourite user photos, such as the strawberry splash you see here, were taken with the old version of the app. This means that a lot of cool high speed ideas like splashes and broken glass will still be achievable with the Android app. Really high speed photographs like balloons with air in them, not so much.
In other words, because of the way that the Android system works, Android devices simply aren't fast enough for some of our users' high speed photography needs.
What's next for Android?
The problem of audio latency in Android is something Google are aware of, and their own engineers have given talks about their own problems in trying to work around this. They're also working on improving performance in the OS.
However this isn't something that we can work around. As of now, we're at the limit of what we can do to improve Android latency.
I'm not happy about this. What now?
When we first launched the Android app we didn't include the sound trigger because we weren't happy with the speed that could be achieved with it. This is down to the way audio is handled in Android, and depends massively on the device and the version of Android that you're running. However, we had a lot of Android users saying that they still wanted the sound trigger, even if it wasn't super fast, which is why we put it in a few months ago. Unfortunately this has led to some disappointment among users whose phones aren't fast enough.
I think it's safe to say we messed up, and should've been clearer when selling the Flash Adapters that Android was a potential problem. With that in mind, we have updated all of the shop descriptions to be clear about this.
If you can't see yourself finding the flash adapter useful, drop us an email at firstname.lastname@example.org with your order details and we'll sort you out. We're really sorry about this and are happy to accept returns in exchange for a refund.
A couple of tips for taking high speed shots on a slower device (it is possible!):
- Use a pellet gun, and put the phone near the gun, not the object - The time that it takes for the pellet to travel to the object gives the phone time to trigger, so try and give yourself at least a metre when possible. The further the pellet has to travel, the more time you give your phone to allow the audio buffer and trigger the camera, so this may be worth a little experimentation!
Even if you do decide to ask for a refund, we would advise holding onto those Flash Adapters. First of all, iOS devices have a much smaller and more predictable latency, so if there is a particular project idea you are absolutely desperate to try out then you could always try and borrow a tablet or iPod touch for the day in order to achieve the high speed results you are after.