Patchfield introduces concepts of JACK audio server to Android

Peter Brinkmann, a developer from Google, introduced a new audio framework for Android called Patchfield.

The new library makes use of some features of pre-existing JACK audio server such as dvanced connectivity.

In a nutshell, Patchfield reuses the cornerstone idea of JACK — creating standalone applications for audio generation and/or processing and connecting them in a patchbay.

Patchfield is already reported to work on various devices like Nexus 7 and 10, and the code is available on GitHub under terms of Apache 2.0.

It might sound like great news, but not everyone shares the sentiment. First of all, in terms of performance Android is still not such a great OS for audio processing. Granted, Google finally started doing something about it recently:

But then again, there's this notion that JACK is full of overdesign anyway. Among people who are not particularly fond of it — Paul Davis, one of its main developers.

In the past few years Paul revisited his views on audio processing, and he's now gravitating towards the idea that the host/plugin architecture is robust enough to handle even complex audio graphs.

For instance, in June this year David Robillard already demoed a version of Ingen, an LV2 plugins host, that provides advanced connectivity between audio processors while being an LV2 plugin itself.

In other words, the fact that Google's developers are finally working on advanced audio features is great — it's not as if we had a plethora of great apps for musicians on Android. Yet it's not quite clear whether Patchfield is going to make a lot of difference in the long run.

32 Comments

Interesting point of view! I think you’re making too much of the reference to JACK. I’m mostly referring to JACK because it’s a concise way of communicating the general intention while simultaneously giving credit to Paul Davis et al for some of the ideas behind it.

The implementation of Patchfield, however, is entirely different from JACK, and I’m hoping to resist any temptation to overdesign.

I should probably clarify the way Alexandre paraphrased me. What Patchfield and JACK share in common is the notion that it makes sense to implement different audio processing elements as distinct processes (programs).

Although this is useful for some users, some of the time, my feeling is that this notion is generally incorrect. You don’t need to develop a flexible audio routing system as “plumbing” (like JACK or Patchfield) if people are loading plugins into a single process that handles this stuff internally.

We originally developed JACK (on Linux) as an explicit response to the lack of a sufficiently powerful and sufficiently accepted plugin API there, which prevented anyone from answering the question “i want to write some audio processing code, how should i do it?” with any kind of coherent answer. JACK let everyone (developers) do their own thing, and then the users get to string the results together. Sometimes, this is very cool, but most often its really a second-best solution for users.

Developers on OS X (for example) who want to write a clever new piece of audio processing code have a very simple and standard way to do it. They don’t worry about audio routing, and they don’t have to explain much to their users. They create an AudioUnit plugin, and users can use it within more or less any audio application on their platform.

It is this aspect of JACK that I have grown skeptical of. It has been a marvellous thing for developers, and is also incredibly cool when doing some slightly wacky stuff that, yes, to be sure, you could not do with a plugin-style model. It also isolates programs from each other’s foibles and faults. But in the end, I think that the “connect a bunch of apps together and route audio between them” model is a specialized one for a particular brand of audio geek, and isn’t really the right kind of solution for the vast majority of users who want to do things with audio on a computer.

Peter, to me graph-like routing on mobile is kinda questionable. It has its pros and cons. It can be great when you have the time to sit and tweak nodes, but I’ve seen musicians struggling with graphs during live performances.

Cycling’74 sort of solved the connectivity issue on Mac (admittedly, not iOS) without going for the whole graph thing, and with JACK personally I’m torn between the simplicity of matrix-like connector in Ardour 3, and the big picture I can see in Patchage.

Paul and Alexandre, here’s my current take on some of the points that you raised:

* While inter-app audio routing is the most prominent feature of Patchfield, it’s probably the least important one right now. For this to be deployed fully, the Patchfield service needs to be available from Google Play, but it isn’t yet because I want to wait for the protocol and API to stabilize first.

So, for the time being, Patchfield will mostly serve as an organizing principle for intra-app audio, and I think it has a lot to offer for this purpose, too. (A small, simple API plus implicit support for multiprocessing, for example.)

Once the service is available from Google Play, we’ll see how the inter-app routing features holds up in the wild.

* Patchfield could also serve as a plugin host if there were a good way to download and install plugins (i.e., untrusted binaries). On Android, however, the only viable way to install binaries is as apps from Google Play. Of course, it might be useful to create a way to distribute plugins, but that seems a lot harder than getting inter-app audio right.

* The problem of musicians struggling with graphs is very much on my mind, and two related items are high on my to-do list.

First, I want to improve navigation between the control app and other clients. It’s okay for now, but the default behavior of the “back” button is not ideal in this setting, and I’ve been thinking about ways to improve this.

Second, I want to come up with a robust session management scheme (i.e., a way of storing and restoring the audio graph). This may actually be more feasible on Android than on other systems because client apps can provide intents that specify how they expect to be (re)launched. Saving a session might be as simple as saving a launch intent for each client app plus their connections.

I am working on a project where I have to use Patchfield for implementing some inter-app audio routing.
To be very true I like the features it has, and its infrastructure have made lot of things much easier while mapping and coding audio in Android apps.

I found Patchfield released on github that was inspired by Jack Audio Connection Kit and it based on Android platform.
It is interesting callback driven audio APIs was implemented without changing android’s framework side.

I am using Android and iOS both. If we compare both in terms of audio than I think there is nothing better than iOS yet. Apps like Garage Band and many similar apps gives iOS a unique place which I think no one can take.

Since Jack now works on Windows (Jack 2 / Jackdmp), it might be interesting to use it for audio routing, similar to what “Virtual Audio Cable” does. (In my case the Jack 1.9.8 installer didn’t work on Windows XP, so i installed 1.9.7, downloadable on the jackdmp

Its always between android and apple isn’t it . But to make a point here i feel there are products beat each other . End of the day, If you had a proper cash you would go for Apple , So just because you cant reach it . You dont call it bluff but appreciate where things have reached its us the consumers who are in profit in the competition they are fighting