Audiobus: Use your music apps together.

What is Audiobus?Audiobus is an award-winning music app for iPhone and iPad which lets you use your other music apps together. Chain effects on your favourite synth, run the output of apps or Audio Units into an app like GarageBand or Loopy, or select a different audio interface output for each app. Route MIDI between apps — drive a synth from a MIDI sequencer, or add an arpeggiator to your MIDI keyboard — or sync with your external MIDI gear. And control your entire setup from a MIDI controller.

Download on the App Store

Audiobus is the app that makes the rest of your setup better.

Trouble starting several AU instances

124»

Comments

  • @Cib said:
    What happens if you want to go beyond instance Z?
    :#

    I believe 10 instances is the limit of any given AUv3. Which is fine. If you're using more than 10 instances of any given plugin, the project would have brought the iPad to its knees long before you got there.

  • Anyone had a chance to test the weird AU instances / performance bug on the 2017 pros now that ios 11 beta 7 is out?

  • @brambos said:

    @Chris_Randall said:
    I can see sort of where the failure is happening, but as AUv3s are very difficult to debug, being sandboxed, I can't say for certain. I've given all my findings to Roli, and they're usually pretty quick about coming up with a fix. Hopefully they'll have something for us in the next day or two.

    Not familiar with Juce, so I don't know how much control you get. But if shit happens, it usually does so in the call to connectViewWithAU().

    Unfortunately the best way to deal with it is on the host's end. My preferred method is using the completionHandler of instantiateWithComponentDescription() to set a flag when ready. You can then use polling to check if the current instance is open for business and start instantiating the next one. Crude, but effective.

    That would ensure sequential loading of the plugins, but is only a partial solution to the problem. Even loading several instances with seconds of delay in between leads to trouble - unless the user opens the UI of each instance. The issue is related to RAM allocation in the UI.

    BTW, wouldn't a simpler way to ensure sequential loading be to use a dispatch_group_t that we enter before making the instance and leave in the completion proc?

  • @j_liljedahl said:

    @brambos said:

    @Chris_Randall said:
    I can see sort of where the failure is happening, but as AUv3s are very difficult to debug, being sandboxed, I can't say for certain. I've given all my findings to Roli, and they're usually pretty quick about coming up with a fix. Hopefully they'll have something for us in the next day or two.

    Not familiar with Juce, so I don't know how much control you get. But if shit happens, it usually does so in the call to connectViewWithAU().

    Unfortunately the best way to deal with it is on the host's end. My preferred method is using the completionHandler of instantiateWithComponentDescription() to set a flag when ready. You can then use polling to check if the current instance is open for business and start instantiating the next one. Crude, but effective.

    That would ensure sequential loading of the plugins, but is only a partial solution to the problem. Even loading several instances with seconds of delay in between leads to trouble - unless the user opens the UI of each instance. The issue is related to RAM allocation in the UI.

    BTW, wouldn't a simpler way to ensure sequential loading be to use a dispatch_group_t that we enter before making the instance and leave in the completion proc?

    Oh, forgot to mention that AUM already does sequential loading of both IAA and AU plugins. (the completion handler calls a block that loads the next one in queue, essentially). But apparently this hasn't helped much.

  • @j_liljedahl said:
    Oh, forgot to mention that AUM already does sequential loading of both IAA and AU plugins. (the completion handler calls a block that loads the next one in queue, essentially). But apparently this hasn't helped much.

    Do the GUIs really have to be opened or would requesting a pointer to the viewController (I forgot the precise name of the method) be sufficient? I haven't tried the latter yet, but it feels like this should trigger allocation of the necessary resources.

  • edited August 2017

    @willhindson said:
    Anyone had a chance to test the weird AU instances / performance bug on the 2017 pros now that ios 11 beta 7 is out?

    I have eight instances of audiomod playing at the same time in AUM without any problems. This is on a 2017 12.9 with latest iOS 11 beta. Not sure if that helps but thought I saw a post earlier if someone having issues >3 multiple instances of that plug-in in AUM.

  • So here is my theory... One thing that to my surprise has not been mentioned here is that each AU only gets one process per host. So multiple instances of a AU in a host all run in the same process. I ran into this early on when I started working on mine and I was working on the assumption that each instance had its own process so I didn't have to worry about sharing resources. This is NOT the case.

    A misunderstanding of this fact can explain all the problems I have seen in this thread. The big main problem that is easily reproduced is the loading of a project. Loading a project loads all the instances in a smaller time frame and thus multiple instances are more likely instantiating at the same time. This also explains why there is more problems on the higher spec machines. They are probably loading things overlapping more.

    Using singletons while not knowing this can cause havoc.

    The one that I think is getting most of the problematic AUs here is the fact that the AU memory limit applies to the process not the AU instance. So using my app as an example I can reliably crash all my instances by adding 52 instances to one host. 51 can run just fine with no issues. My AU uses just under 7MB per instance so: 7*52=364 which is over the limit and the system kills. This is why high end pianos can only load one or two instances without getting killed.

    Personally I think this is the wrong way to do it. They should create a new process per instance even if it takes more resources. And if not they need to be way more communicative about how it actually works.

    Relevant Apple dev forum post: https://forums.developer.apple.com/thread/65909

  • @lucas said:
    So here is my theory... One thing that to my surprise has not been mentioned here is that each AU only gets one process per host. So multiple instances of a AU in a host all run in the same process. I ran into this early on when I started working on mine and I was working on the assumption that each instance had its own process so I didn't have to worry about sharing resources. This is NOT the case.

    A misunderstanding of this fact can explain all the problems I have seen in this thread. The big main problem that is easily reproduced is the loading of a project. Loading a project loads all the instances in a smaller time frame and thus multiple instances are more likely instantiating at the same time. This also explains why there is more problems on the higher spec machines. They are probably loading things overlapping more.

    Using singletons while not knowing this can cause havoc.

    The one that I think is getting most of the problematic AUs here is the fact that the AU memory limit applies to the process not the AU instance. So using my app as an example I can reliably crash all my instances by adding 52 instances to one host. 51 can run just fine with no issues. My AU uses just under 7MB per instance so: 7*52=364 which is over the limit and the system kills. This is why high end pianos can only load one or two instances without getting killed.

    Personally I think this is the wrong way to do it. They should create a new process per instance even if it takes more resources. And if not they need to be way more communicative about how it actually works.

    Relevant Apple dev forum post: https://forums.developer.apple.com/thread/65909

    This is the most probable explanation so far...and I prefer this one to the "screen taking all the memory" one that would have involved hardware problems...

  • edited August 2017

    @cuscolima said:

    @lucas said:
    So here is my theory... One thing that to my surprise has not been mentioned here is that each AU only gets one process per host. So multiple instances of a AU in a host all run in the same process. I ran into this early on when I started working on mine and I was working on the assumption that each instance had its own process so I didn't have to worry about sharing resources. This is NOT the case.

    A misunderstanding of this fact can explain all the problems I have seen in this thread. The big main problem that is easily reproduced is the loading of a project. Loading a project loads all the instances in a smaller time frame and thus multiple instances are more likely instantiating at the same time. This also explains why there is more problems on the higher spec machines. They are probably loading things overlapping more.

    Using singletons while not knowing this can cause havoc.

    The one that I think is getting most of the problematic AUs here is the fact that the AU memory limit applies to the process not the AU instance. So using my app as an example I can reliably crash all my instances by adding 52 instances to one host. 51 can run just fine with no issues. My AU uses just under 7MB per instance so: 7*52=364 which is over the limit and the system kills. This is why high end pianos can only load one or two instances without getting killed.

    Personally I think this is the wrong way to do it. They should create a new process per instance even if it takes more resources. And if not they need to be way more communicative about how it actually works.

    Relevant Apple dev forum post: https://forums.developer.apple.com/thread/65909

    This is the most probable explanation so far...and I prefer this one to the "screen taking all the memory" one that would have involved hardware problems...

    Actually it goes hand in hand with the screen taking memory theory. Each AU instance needs more memory due to the higher res gui and faster refresh rate. It even explains why the 10.5 can run more instances than the 12.9 since it has a lower res display.

  • Hah yeah.. when I was first turning my Ruismaker engine into an AUv3 last year I had a massive WTF moment when I found out (the hard way) that resources were shared between instances. A lot of my nicely optimized C code had to be turned into C++ to overcome this.

  • The user and all related content has been deleted.
  • I've now tried lots of possible workarounds in AUM. Adding a delay in between loading each instance made no effect. Accessing the UI of the plugin without showing it had no effect either, unfortunately. The only workaround I've found that has no weird side-effects is to actually show the UI of each instance and then close it after a very short while.

    Now, all this could be done off-screen and not be visible to the user. But it's an ugly hack just to work around a bug in iOS! Might need to keep it though until Apple fixes it.

  • @j_liljedahl said:
    I've now tried lots of possible workarounds in AUM. Adding a delay in between loading each instance made no effect. Accessing the UI of the plugin without showing it had no effect either, unfortunately. The only workaround I've found that has no weird side-effects is to actually show the UI of each instance and then close it after a very short while.

    Now, all this could be done off-screen and not be visible to the user. But it's an ugly hack just to work around a bug in iOS! Might need to keep it though until Apple fixes it.

    Hah ugly indeed. But do it for the Music! B)

  • edited October 2017

    I'm so glad the developers of apps are here to actually explain this stuff. I'm not much of a programmer but I understand the process a bit and I always wondered why these extremely powerful devices sometimes struggle with multiple but seemingly low resource intensive tasks

    Thanks for explaining!

  • edited September 2019

    @j_liljedahl @brambos

    hello guys, sorry for exhumation this old thread but i wanna ask if issue you discussed here is already solved in iOS or potentially it is still sleeping inside..

    cause i'm experiencing some issues which coincidently looks exactly like this (not in aum, not with bram plugs - but asking because i did found this thread)

Sign In or Register to comment.