Powered by Squarespace
« iFretless Guitar Updated with Overdrive | Main | iOS Update Vol. 44: iRig HD & Setlists »

Inter-app Audio Again

Although the initial slide revealing Inter-app Audio in iOS 7 was easy to dismiss, having failed to materialize when they promised this in iOS 6, this time around it seems like the real deal. Several developers, frustrated with Apple's draconian NDA, are flat out breaking their non-disclosure and speaking somewhat openly about the contents of the SDK.

In an effort to get ahead of the rumors that we saw last year, and before anyone announces the death of Audiobus, JACK or even Auria, I want to compile what we actually know.

The official public word:

Leaked iOS 8 Concept Art

This doesn't really tell us a lot, and the use cases here sound confusing. What in the hell is the difference between publish audio streams and, uses the combination of those streams to compose a song? Fortunately that isn't all we have to go on!

Almost immediately after the release of the SDK an anonymous poster commented here with the official private word. This has been confirmed by three other sources, so I feel I have even better journalistic integrity posting this than CNN.

The official private word:

From the dev member center:

Inter-App Audio

The Audio Unit framework (AudioUnit.framework) adds support for Inter-App Audio, which enables the ability to send MIDI commands and stream audio between apps on the same device. For example, you might use this feature to record music from an app acting as an instrument or use it to send audio to another app for processing. To vend your app’s audio data, publish a AURemoteIO instance as an audio component that is visible to other processes. to use audio features from another app, use the audio component discovery interfaces in iOS 7.

This Audio Unit phrase gives a good indication of what Apple has in mind for this technology. It is important to keep in mind that this is a technology; not a product like Audiobus and JACK. Audio Units (AU) are the plug-in format used by Logic, Apple's professional DAW, similar to RTAS, VST, AAX, etc. It is just a proprietary Apple format for plugin architecture. AUs didn't kill any of the other formats.

The inclusion of MIDI commands, and the ability to launch other apps, makes this sound like a tool for offline-rendering. For instance you could sequence your DAW app to load up an effect app, send it some audio and perhaps some parameters for how that audio should be effected, and then it collects the results. This is just an example, but that seems a lot different from what we're doing now with Audiobus and JACK today.

It is unclear at this time how this will actually be implemented or what sort of advantages it can offer. There are persistent rumors of a Logic for iPad, but the way that private blurb if phrased it sounds like they are opening this up for other DAW apps to use. Without getting any developers in trouble, I will just say that there is excitement about the possibilities here. This isn't a replacement for Audiobus, this is something else all together. The only thing we know for sure is that Apple are trying to keep their lead over other mobile OSes, by continuing to advance the platform well ahead of them all.

Update: After this article went up I was contacted by a dev I know and trust. He provided the following on the condition of anonymity.

Hi Tim, just read your blog post. I see this more as an opportunity for developers to implement a DAW hosting AU-Instruments via inter-app-audio. If I were Steinberg, that would be my focus for Cubasis. And probably the GB version will be ready for iOS 7.

There are example projects in the SDK which give the working code for this. A little host, an instrument "plugin" app and an effect "plugin" app. Both can be instantiated from the host app like you do in Cubase, Logic whatever. Apple would not spread this example if they wouldn't like to see this scenario.

The important point here, that this solves the sandbox problem: The sandbox concept of iOS was prohibiting loadable plugins which are not contained in the app like Auria does. However, with the idea of inter-app-audio this is solved. The instrument app published its own AU to any app it wants. The host checks about which AUs are there and remotely instantiate this app.

The MIDI connection and rendering is of course realtime. The only point unclear is, wether there is also support for plugin parameters, preset loading and persistency. But this could be easily added.

So, this IS much more powerful than Jack and AudioBus, I'm sorry to say. AudioBus of course could base its own engine on the Apple technology, but it gains nothing. In fact, AudioBus then is competing more with Cubasis, i.e. AudioBus is then just another host, and in that respect it is weak compared to Cubasis, GB etc. AudioBus/Jack loose the technology advantage of audio inter-app streaming.

Excellent insights! Note that although this does mean Audiobus will loose its monopoly, it does not lose its uses.

Reader Comments (23)

So if I understood correctly, AU will be very low-level within the OS, perhaps out-performing "higher"-level apps such as JACK or Audiobus. Apps will be able to take advantage of these AUs as a function/procedure if properly coded as plugins. In the end these AUs will be one-time "plugins" requested by any controlling app (DAW or not...).

In any case,can you still look at this as "complementary" or as a "substitute"... er... product?

If I understood correctly, it seems like a substitute. And if and when Audiobus/JACK takes advantage of those new AUs they will (kind of) undermine their own reason to exist. For if they use the AUs why do you need Audiobus/JACK in the first place, if they don't, won't apps that use AUs perform better?

And in the end, don't all other music app developers have incentives to adopt the AU features? And what does this mean for Audiobus and JACK?

Auria will live to fight another day with Cubasis, together with a new frenemy called Ableton against... er... Garageband, I mean... Logic :)

Cheers,
h79

June 11, 2013 | Unregistered Commenterhoyas79

I think you mentioned even ipad 2 can download ios7,if so i will wait & see what others have to say on that as everytime theres a update for older devices there always seems to be some downsides-battery drains quicker,some apps have to change for new system,few bugs appear that take time e.t.c.

June 11, 2013 | Unregistered CommenterIAP

I read your anonymous dev update, and well, if true then it pretty much sums it up for Audiobus and JACK. They have to out-innovate Apple, (i.e.: with multiple devices/routes/channels - Bluetooth does not count!!!).

All kidding aside, Audiobus is a formidable app, a breakthrough and a victim of its own success. I don't have much experience with JACK.

In the long run, I think the smart thing to do is to sell to Apple if they haven't tried that already.

Best,
h79

June 11, 2013 | Unregistered Commenterhoyas79

As far as I can see, this is just a technology for inter-app audio, it does not replace Audiobus or JACK but it opens up the technology for "everyone" so Audiobus and JACK looses their monopolies. I don't know yet how connections are handled, but I'm quite sure there will still be a need for host apps like Audiobus that simply let you connect apps together without being a full DAW app. Also, it may set a standard that could merge Audiobus and JACK (and other hosts/patchbays coming in the future), all apps supporting this new technology can work together, which is very nice.

June 11, 2013 | Unregistered CommenterJonatan Liljedahl

What is interesting about this is that this could mean that all the latency issues AB experienced while writing their app could be dealt with and buffer size concerns could simply fade into the background if Apple have coded this in a decent way!

I guess some apps will just continue to put out audio via audiobus, some will take advantage of the mufti-channel abilities of iOS 7 and AB will be able to spread their wings and allow multiple channels - looks like win all round, but we will see hey :)

June 11, 2013 | Unregistered CommenterSteve

To me this sounds like a replacement for the core hack that made Audiobus happen, not Audiobus the product. AB dudes are smart and creative and will continue to innovate on top of it, I'm sure.

Anyone know/able to share why the AB team were WWDC VIPs? Feel like that would tell us a lot.

June 11, 2013 | Unregistered CommenterWill

Here is a not very informative thread with a couple of comments ( more like "no comment" ) from Sebastian
http://forum.audiob.us/discussion/1245/inter-app-audio-again

June 11, 2013 | Unregistered CommenterZymos

Agree with Will

AudioBus solved the basic problem via a hack since the core did not offer a way at that time.
Now there is a API whose purpose might be different and bigger and it's trying to solve the bigger problem I guess
Audio routing a la AB might not be needed but there would still be a need for audio management or maybe a mixer and AudioBus as a product can still be transformed to play those roles
I think we are going to see a lot of "plugin as an App" releases
The core API would have its adv of being faster and natively implemented

Exciting times surely ... Maybe GB will be replacing cubasis !!

June 11, 2013 | Unregistered CommenterPat

Michael from ATastyPixel just tweeted he had a meeting with the iOS Core Audio team before sitting in on the inter-app audio session at WWDC... There has to be something good in the plans for Audiobus. I can't wait!

June 11, 2013 | Unregistered Commenterhx

Wait, that was an official @AudiobusApp tweet, even better :-)

June 11, 2013 | Unregistered CommenterHx

Ha, yes it is official! https://twitter.com/AudiobusApp/status/344534072766394368

After meeting with Apple's CoreAudio team we're sitting in the Inter-App Audio session, taking it all in. Lots of good stuff!

Glad to hear they like what they're seeing!

June 11, 2013 | Registered CommenterTim Webb

Excellent news :)

June 11, 2013 | Unregistered CommenterSteve

even if they build a wormhole into the inter-apple space, methinks we're still gonna need that trusty transporter beam with its coordinate system (url scheme) on occasion.

June 11, 2013 | Unregistered Commentera1

Let's not forget the MIDI ....we need Rocksolid supertight masterclock synced global IOS core prioritisation .......or however you bus your midi triggered audio its gonna be jittery !
Hopefully Audiobus guys were making this point at the meeting after recognising there are Ios 6 midi / clock timing issues over last couple of months on their forum .

June 11, 2013 | Unregistered Commentersparkle

Please check out our statement regarding Inter-App Audio in iOS 7
http://audiobus.tumblr.com/post/52745280295/on-inter-app-audio-in-ios-7

June 11, 2013 | Unregistered CommenterSebastian Dittmann

It would seem to me this could give Audiobus a chance to develop as a kind of AU "wrapper", giving AU characteristics to any app with Audiobus support and allowing them to integrate as an AU pluging within a host.

Just my first thought, I obviously know nothing. VST Wrappers have been used for years in the desktop environment.

June 11, 2013 | Unregistered CommenterDeltacaster

Wow, just read the latest post from Sebastian (thanks for the pointer) and the update to the main post...

... Who's for a big boost in audio processing in the iPad 5? :)

June 11, 2013 | Unregistered CommenterSteve

@Deltacaster

That's a good idea, but I wonder if the "wrapper" so to speak would be the app itself, which would also make itself available as an AU plug-in just like many desktop synth plug-ins which offer a "stand-alone" version in addition to being available in Logic as a plug-in.

Either way, this is some awesome news, and its great to see Apple continue to push the envelope of this mobile platform they've created, inching closer and closer to desktop type functionality. The way mobile processors are progressing, the only thing holding this tech back is the lack of horsepower, which will be rectified in the next few years thanks to our trusty old friend Moore's Law. :D

June 11, 2013 | Unregistered Commentergatearray

Another idea is that Audiobus could make complex chains of apps like Magma from Nomad, and have it only take up one track in cubasis/Auria/Logic.

June 12, 2013 | Unregistered CommenterHogo

Hi guys, this all sounds good for iOS music, I have a stupid question here though.

When people use the acronym API in reference to iOS apps, do the generally mean

Application Program Interface?

Application Programming Interface,

or probably Application Platform Interface

or maybe Application Process Integration?

??

June 12, 2013 | Unregistered Commenternetz

@netz

http://en.wikipedia.org/wiki/Application_programming_interface

:)

June 12, 2013 | Unregistered CommenterSteve

A normal file system would be the best update. On android phones and tablets, although it has much fewer good programs for music, at least you can write something, render to .wav, then copy the file straight into another music apps sample folder, or make a new folder and place it there.
Writing electronic music you end up with large amounts of samples which need to be used in multiple programs and should be arranged into folders, for example 100 different drum machines with 100 one shot samples each. At the moment you need to have all that in each separate app, and all samples in one folder! You cant even make your own folder....heirarchical folder system has been availiable since MSDOS, I dont know why they should need to take it away now. All this stuff about emailing files to yourself, dropbox etc. is straight bullshit...On android stuff its simply plug in USB, drag and drop, make any folder you please, any music program can access those files. You dont need to have that same folder in every app you might want to use those samles in. so ios7 seems like its still crippled

June 13, 2013 | Unregistered Commenterpingguogongsishasile

+1 @pinggu

Although the excellent AudioShare app addresses a lot of these issues - recommended!

June 13, 2013 | Unregistered CommenterSteve
Comments for this entry have been disabled. Additional comments may not be added to this entry at this time.