While pro audio is respectably monogamous to iOS—its first-love mobile platform—the world overwhelmingly runs with Android. Worldwide, Android accounts for 84.7 percent of smartphones1 and at least 60 percent of tablets, and rising.2
Android OS—with thousands of available app options—currently offers no reasonable tools for its users who may want to, for example, use their tablets to capture multi-microphone/multi-track performance sessions, record overdubs, effect/edit tracks, mix, and distribute audio productions without horribly bad audio I/O latency. Yet there’s an iOS app for that—dozens actually, and those perform spectacularly.
Meanwhile Audour and Harrison MixBus are each fine DAWs available on Linux OS, the open architecture OS (with the cute penguin mascot) that shared its processing kernel with Android (branded with the little green robot with antennas).
The Latency Hurdle
Overcoming a best-case scenario 20-millisecond full round-trip I/O latency in tablets seems easy enough—that is, if the best case scenario would be as low and consistent. Yet the fact is, audio latency inherent in Android devices varies terribly, based on each manufacturer’s own added code and the accompanying, inherent variances; expect latencies of 250 to 300 milliseconds, regularly and randomly. This is simply unacceptable for audio production tools and an issue that Google, Android’s current developer, will have to make a greater priority to solve with an updated API* as well as some form of enforced standards. After all, some tablets process audio at 48 kHz, other “smart” devices at 32 kHz, while games often use 24 kHz and streaming audio is widely variable (QuickTime, for example, uses rates ranging from 8 kHz to 48 kHz). Thus Android audio requires latency-causing resampling code.3 Or, tablet manufacturers must work around current Android code using other means. Or, possible still, third-party pro audio industry Android advocates could provide some interesting work-arounds.
Google now manages the world’s most popular mobile OS in history. To be fair, Pro Audio’s specific needs in new Android code is obviously down a long list of other priorities, yet that’s not to say Google isn’t concerned about audio I/O latency. Who opens the Android gate into such pro audio development? Is Android’s market dominance even that attractive to pro audio product developers, or—possibly more poignant—is pro quality audio production an attractive market to tablet manufacturers?
I recently spoke with two experts also interested in this topic: Paul Davis, developer/programmer of Audour, the JACK Audio Connection Kit**, and second-earliest programmer for Jeff Bezos’ Amazon.com; and Ben Loftis, designer/engineer and developer of the MixBus DAW for Harrison Consoles.
Davis is a DAW expert with quite an interesting and scenic viewpoint.
“There’s a historical background to this, and that problem goes back to the guys that worked on the APIs and libraries that application developers use,” begins Davis. “They didn’t really care about low latency audio. In a world that’s derived from UNIX-types of operating systems and that didn’t mutate in the way Apple did it, there are essentially two models for interacting with audio hardware. One is a push model; one is a pull model.”
“In the push model, the application is responsible for deciding, ‘hey, I have a big chunk of samples and I want to send it out to the device right now and it’s going to get played.’ It’s a nice, simple design that works really well for all the traditional UNIX audio applications where you just want to make a beat, play one audio file, etc. This is not so good for low latency in general because of loads of buffering between the application and the hardware.”
“The pull model actually wasn’t pioneered by Apple but they were the first company to impose it on application developers when they switched to Core Audio with OS X. With this model, it’s easy to get very low latency. Of course, you can lay other things on top; it’s easy to write high latency stuff on top of the pull model. All the low-latency systems—ASIO, Core Audio, and systems like JACK, which sit on top of those—use a pull model.”
“In developing Android, they either didn’t know this, or didn’t care. So, all of the audio APIs in Android became push-based. The idea is, ‘I’m an application. I have some audio playback. I just need a pathway through to the device.’ In Android, historically, the model was Java—high-level languages, applications that need boatloads of buffering. Up until 2-3 years ago, that’s the reason why Android sucked. Recently, this has begun to change.
“Google has a relatively small team focused on trying to redesign the core audio layers inside Android, and they have made some significant progress so far.”
Apple said to their developers, ‘We don’t care how much this is going to disrupt your other application designs. With Core Audio, this is how audio applications have to be written, end of story.’ My impression is that Android management, whatever that means, really doesn’t want to turn around and announce this kind of change.”
Loftis dove into the Linux pool 12 years ago. “We first started with Linux when we changed our automation system from Apple to a system called BeOS, which marketed itself as the multimedia operating system,” recalls Loftis. “TASCAM, RADAR (iZ Technology), Harrison, Level Control Systems, Roland and several others bought into the idea that BeOS was going to be the next big multimedia platform—the replacement for Mac. That didn’t happen so we got into Linux development.”
Upon Android’s burgeoning success just a couple of years ago, Linux audio folks like Loftis were stoked. “The thought was, ‘If we can put JACK on Android, then all this cool software we’ve written—metering and recording, MIDI, virtual instruments and synthesizers—could get immediately ported over. They found that Android’s infrastructure was incapable, raised a fuss, started a mailing list and hammered on Google to address the issue. They have tried to address some of these things, so that users can use Android for ‘semi-pro audio,’ but there’s a lot of existing hardware and things that make it hard to backtrack. The fact of the matter is, the underlying protocol is unidirectional only; it’s not a record/playback system. You have separate record and playback systems with separate clocks. So, when Google announced that this was what you’re going to get, everyone (in pro audio) just said, ‘forget it, then.’”
But wouldn’t “audio-optimized” Android tablets open up music production to a much larger audience, further nurturing and growing next generation audio content creators? Possibly, agrees Loftis, but “it’s hard for me to make a really cool app because even with Samsung’s changes, the performance of Android isn’t as good as iOS. I would be motivated if it was as good, but I would still have to consider that only those with the latest Samsung tablet could run it.”
Rather than apps, perhaps the future of Android in pro audio is Android-enhanced hardware. “A USB front-end is already costing more than a tablet or computer,” poses Loftis. “The next step is, you buy your USB I/O device with Android on it, which costs nothing to license. Suddenly you can do everything any other tablet can do: drag and drop, wi-fi, use a keyboard, etc. It’s definitely an interesting prospect for hardware manufacturers.
If Amazon can sell a cheap tablet for, say, $50, they’re being made for $20. A company could have them made and put their software in; users could pull it out of the slot, it would be company branded and the company would have a lot more control over it—that is, if it isn’t just about the iPad. As controllers, Android tablets are already superior because they’re cheaper, customizable with better battery life, Wi-Fi range, or any number of features.”
Filling The Void
It’s arguable that Android, the most accessible OS in consumer electronics history, could allow for more pro audio products to, for example, assist budding producers who already have an Android tablet, or for those who could more easily afford an Android machine. And despite how much we all love iOS, a little competition is never a bad thing. But for now, the competition is still in the locker room.
Footnotes: 1 “Android, iOS Gobble Up Even More Global Smartphone Share,” PC World (http://www.pcworld.com/article/2465045/android-ios-gobble-up-even-more-g…); 2 “Gartner Analysts: 2.5B PCs, Tablets And Mobiles Will Be Shipped in 2014, 1.1B Of Them On Android,” TechCrunch http://techcrunch.com/2014/01/07/gartner-2-5b-pcs-tablets-and-mobiles-wi…); 3 “Sample rates and resampling: Why can’t we all just agree?” Google I/O 2014 (https://www.google.com/events/io/io14videos/17fb53da-42e0-e311-b297-0015…); * Application programming interface, specifically audio I/O software http://en.wikipedia.org/wiki/Application_programming_interface; ** The JACK Audio Connection Kit is Linux audio/MIDI software, a soundcard server for Linux, iOS/OSX and Windows: http://en.wikipedia.org/wiki/JACK_Audio_Connection_Kit. Meanwhile, the iOS exclusive AudioBus, is in V.2.