Patchfield introduces concepts of JACK audio server to Android

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.

Ingen

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.

Was it useful? There's more:

  • TVPaint Animation ported to Android

20 Comments

Leave a comment
  1. 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.

    It’s probably misleading look at it as a question of audio servers vs host/plugin architectures. Neither concept really applies. Patchfield is something else, an attempt to implement flexible audio routing within Android’s idiom.

  2. 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.

  3. Alexandre Prokoudine 06 September 2013 at 7:38 pm

    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.

  4. 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.

  5. The fundamental problem with plugins is that a single misbehaved plugin can take down the whole app. With separate protected processes, that’s less likely to happen.

  6. Alexandre Prokoudine 07 September 2013 at 2:09 am

    @Lawrence, not necessarily. Plugins can be executed in a different process. This is what Bitwig claims to do, AFAIK.

  7. So, if I understand correctly, an application registers itself as a client of the JACK server? As Peter said, seems that JACK it’s a simple way of communicating its intention.

  8. i want to make my own application any one knows how can i rigster my account on google store and make my own andrioid application

  9. @usmansarwer

    You need to pay for it..Or you can buy play store accounts from resellers

  10. great post….really healpful for mine project. thanks for sharing :)

  11. Pretty interesting stuff and I’m glad that not everyone has forgotten about the Andriod.

  12. great stuff.. it’s all about my apps development on android finally can get the information about jack on servers

  13. Helpful information about JACK audio server. Its helps to Android developer in their project. Thanks for share this great stuff.

  14. Jack doesn’t work properly under many conditions.  I had a lot of trouble installing it on Windows XP until I found out the correct DirectX setings.

  15. ow this post is so awesome…. thanks for this. I realy like this….

    And your site is cool. I will be Back again .

  16. 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.

    Great job by Peter Brinkmann.

  17. Interesting news. Thank you providing this info. Thank you Peter, for this awesome post. I love to read everything about Android :)

  18. Hi all,

    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.

    https://github.com/google/patchfield

    Thanks,
    KimJeongYeon

  19. Thanks Alexandre for info. I am just going to download PatchField..  Hope that it works…

  20. 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.

Tell us what you think

Submit the word you see below: