From left: JACK, on iPad, and Audiobus, on iPhone (now with fresh support from GarageBand). JACK does more; Audiobus does less, but in a way that may be clearer to certain users. Why both can survive. JACK image courtesy developers; Audiobus image (CC-BY) T.A. Walker.

From left: JACK, on iPad, and Audiobus, on iPhone (now with fresh support from GarageBand). JACK does more; Audiobus does less, but in a way that may be clearer to certain users. Why both can survive. JACK image courtesy developers; Audiobus image (CC-BY) T.A. Walker.

It always has to be complicated, doesn’t it? You just want to sit on your couch with your iPhone or iPad and finish some music, by recording that drum machine and a bass line into a multitrack song in a different app. And then, after months of this site saying the way to do that was something called Audiobus, everyone is suddenly talking about something called JACK, too. Ah, standards.

All of this had some wondering if JACK even has a shot, with Audiobus already out there. Even Apple has come onboard, as of last week, with the announcement that GarageBand would support Audiobus. At US$5, with versatile multitrack arrangement features, GarageBand is ideal for recording from Audiobus-compatible sources, which now include Animoog, ThumbJam, Samplr, DM1, and the Korg lineup, among others. (Apple even specifically mentioned those in a note on the upgrade.)

So with Audiobus succeeding, JACK will fail, right? I don’t think so. I think we may see both “standards” evolve, and that, contrary to first appearances, they may fit different needs and use cases.

First, some important points in favor of successful JACK adoption:

  • JACK-compatible apps are coming, starting this week. JACK-compatible apps are coming. It’s only been days since the announcement, and already imminent support has been announced for ThumbJam, Live Guitar, the innovative Audulus modular, Audio Filter, and DrumJam. We expect these apps by the end of this week. Those apps may sound familiar, because:
  • An app can easily add support for both JACK and Audiobus. Already, apps with Audiobus support are also adding JACK support. (More on why that may make sense in a moment.) Because you launch the JACK or Audiobus app first, then load these other apps, they will simply use whichever audio system is available. If a user uses neither, apps just operate like normal iOS apps. I’ve confirmed with JACK developer Christian Schoenebeck that you can support both. In fact, he tells CDM, “most of the upcoming third party apps with JACK support already support Audiobus, and they will continue to support Audiobus, of course. So there is absolutely no conflict.” Christian tells us more news, plus a forum, will be online in the coming days. Follow the iOS app page or Twitter tag #jackaudio / @crudebyte for the latest updates.
  • Adding JACK support is dead simple. To add JACK support to your app, we’re talking about downloading the free SDK, dropping it into a project, and then adding a few lines of code. You could literally spend more time reading and commenting on this article than adding support, assuming the rest of your app is running smoothly in regards to audio. The step of adding JACK itself, then, is unlikely to be an obstacle. In fact, JACK support implementation I find easier than Audiobus – and you get more features (sync, MIDI, data, not just audio).

Which Bus Should You Ride?

modulus

thumbjam

Days after the announcement, Audulus and ThumbJam are announcing JACK support – and they already support Audiobus. Some very cool stuff to play with.

But let’s back up. If the idea is that both apps can easily support JACK and Audiobus, and some already can, we return to the more important question: why would you want to support two different means of connecting audio?

Developers tells me interoperability between JACK and Audiobus is a possibility for the future. In the meantime, though, let’s assume you use the two separately. Audiobus and JACK each have specific advantages.

For simple audio connections between apps, Audiobus helps reach a broad audience. Audiobus’ simple source / effect / recorder structure, and focus on audio, may be too rigid for some users, but it can be a selling point for others. Part of the appeal of iPads and iPhones is in attracting new people to music making. Those users may intuitively want to connect different apps – recording a vocoder vocal line into a looper, for instance – but they may not need something much fancier than that. They may not even know what MIDI is, or need complex connections between apps. Here, Audiobus excels. It makes the flow of audio, effects, and recording clear and has a friendly, attractive user interface well suited to that audience. And…

Audiobus does a good job of evangelizing the idea of connecting apps. With an elegant website and documentation, a showcase for compatible apps, and active social channels (Facebook, Twitter, and a mailing list), Audiobus is actively getting the word out to new users. Some developers will wisely support Audiobus just to attract new people to their apps. (I think JACK can learn from this, too, but the niches remain a bit different – see my previous point.)

When your needs outgrow Audiobus, nothing can touch JACK. The reverse is true: JACK is the more powerful tool. Audiobus routes audio between apps, but it’s limited to basic connections, and it doesn’t do other kinds of data. JACK does audio, but also sync, MIDI, and data copy/paste. And connections of any of these elements in JACK can be more powerful, running between apps in any combination you like.

JACK is free. Not all developers may relish the idea of pointing users to an app they have to buy to make those connections. JACK is free. Audiobus (normally US$9.99, on sale now for $4.99) isn’t. And JACK uses the same free and open source technology found on desktop systems, so while “open standard” I think isn’t quite right (open source and “de facto” standard, to be precise), JACK is something developers can easily support.

Again, consider the landscape:

Inter-app audio: Audiobus, JACK. (JACK offers more flexible connections.)
Inter-app MIDI: via Code Audio, or JACK. (JACK makes it easy to see graphically how you’re connected.)
Sync: WIST (Wireless Sync-Start, from KORG), or JACK.
Arbitrary data transfer: AudioCopy and AudioPaste, or JACK.

JACK is the only tool that does all of these things with one technology, it has the most open approach to the SDK, and it allows more flexible implementation of all four of these functions than any of the competing technologies alone. Users get it for free. Developers get it for free. And it’s easy to implement.

Audiobus, meanwhile, still has a place as a tool that charges a few bucks for the convenience of audio connectivity that’s really simple to end users, for people who don’t need all those fancy features.

It’s impossible not to notice that this is a lot to implement for a developer making a $2 app. But it’s also creating an ecosystem in which $2 apps can more easily thrive.

Bottom line, my guess: Audiobus will be a good choice for newcomers to inter-app audio; JACK will be the preferred solution for more advanced users. Smart developers will take the time to implement both, and certainly at least JACK. (Even if your users don’t need it, I think you as the developer may get more pleasure out of using your own app!)

And both Audiobus and JACK can gain from each other. Apart from sharing any engineering insights, I think JACK could learn from Audiobus’ nice UI design and app showcase. Audiobus could benefit from working together with JACK’s more powerful features.

More Resources

JACK is only days old; Audiobus has a three-month head start on iOS. So here are some tutorials on the Audiobus side.

My colleague Chris Breen takes GarageBand with Audiobus for a spin.

A new beginners’ guide vid:

Beatmaker MIDI used to sync Audiobus apps:

The Amazing Audio Engine is an open source sound engine for iOS with built-in Audiobus support (no surprise, as it’s from one of the creators of Audiobus).

The Big Picture: Addendum

I have to say, I think that this in general can be good for the open source ecosystem on one hand, and for music developers making their apps more useful with minimal effort on the other. For instance, with our libpd library, we now can allow people to work with Pd to target something as far apart as an iPad and a Raspberry Pi with the same visual Pure Data patch. JACK on iOS means that very easily that Pd patch could get recorded into another app on an iPad; JACK on desktop means you could route it to a DAW like Ardour. JACK and libpd each use similar interfaces for routing audio to and from the hardware interface, so these create friendly, consistent APIs developers can use to get glitch-free audio between apps on lots of platforms.

For users, it means that increasingly, we see music making environments in which software tools are flexible, easy to inter-connect, and designed for specific tasks, rather than the rigid DAW + plug-in architecture that has dominated desktop music making for years.

And that gets us back to your couch and your music. I hope in coming months, this helps you get more done there.

  • papernoise

    As I said previously, if they come up with the iOS equivalent of JackSession on Linux the whole mobile music making buiness will have gotten a whole lot more interesting! So this, apart from the things you mentioned in the article, is probably the most interesting part of JACK hitting iOS. I opens the door to some new possibilities.
    Just so you know what I mean: http://tangostudio.tuxfamily.org/en/documentations/jacksession

    • PaulDavisTheFirst

      jacksession is not linux specific. it is a protocol. the jack app on iOS is where you would expect to find a session manager implementation.

    • Jeremy Achey

      Jack fell into serious issues with iOs 7,
      it said in their article at crudebyte it was because Apple implemented a policy with the new O.S. where IPC mechanisms are now blocked for
      all third party apps.
      Inter-app seems to be having no such difficulty, which leads me to wonder if it really is a licensing issue with Apple. there seems to be a back door for IPC mechanisms only those within the franchise are allowed to use leaving many third party developers in the lurch and keeping Apples franchise/monopoly hedged.

  • djhokey

    I think either solution is acceptable provided that the app developers provide the same type of support across different devices for the same app. I’m looking at you Propellerhead and Rebirth/Rebirth for iPad.

    • http://pkirn.com/ Peter Kirn

      I can’t imagine why you wouldn’t do that. Is another another case apart from ReBirth? Code base for the iPad and iPhone versions there is atypically different, I believe.

    • djhokey

      That’s a good question. I tend to avoid ones that have more features on the iPad only version. ReBirth for iPad has Audiobus support but the iPod/iPhone version does not. I can understand implementing certain features because you have more screen real estate to work with, but the connectivity should be the same across all devices.

  • Fash

    And what about tabletop? The IMPC is amazing but only works inside tabletop

  • jmp909

    i’m just hoping there’ll be *something* that’s accepted as standard that allows all apps to sync & record through a shared fixed buffer. currently if i try recording a drumloop from one app into garageband for instance there’s going to be some latency delay, and the trim tool is far from ideal for closing up on the sample and getting to the actual start of it (unlike Beatmaker’s editor) to remove this initial latency delay. I’d be happy for an increased latency during record so I could just get the wave start to actually record at the start of the track. Half the apps dont even support VirtualMidi Sync (Korg i’m looking at you!), which means trying to get the 2 apps in sync for recording from that is a matter of trial and error…. i’m sure a few months down the line this may be different though if people keep pushing for Jack/AudioBus/VirtualMidi/Sync support on the forums.

    • PaulDavisTheFirst

      it is not true that streaming audio between apps adds latency.

      JACK was designed to be synchronous (all client apps work on the same piece of audio “at the same time”) and low latency (routing audio via JACK adds no extra latency compared to a single application (though less cycles are available for processing, just a little bit).

    • jmp909

      Hi, I didn’t mean latency from routing, I meant from the amount of CPU usage for sound generation. Both apps need to do their job, so I’m saying having increased latency for that is an acceptable trade off, at least for recording output from one to the other. Or for sequenced playback rather than live interaction.

      Thanks for the info though, I guess that’s what you’re saying JACK is designed to achieve.

  • http://twitter.com/TheAlterEkHo AlterEkho

    Jack may fall if :
    its not adopted widely like Audiobus;
    Audiobus adds the midi