Ipad mini (and iPolysix) troubles

litebritedeath82

I have noticed that I get crackly audio just from running sunrizer into loopy. Ipad mini has the same specs as an ipad 2 and i have all other apps killed in the app bar. Love the app just disappointed when I'm trying to keep it simple and still end up with audio problems.

EDIT by Sebastian: I've changed the headline slightly, because I think this has not necessarily only something to do with the iPad Mini but could also involve iPolysix.

electricgenes

ran into exactly the same problem, workaround here: http://goo.gl/527sU

Sebastian

@electicgenes: Thanks for the workaround!

This looks like a case of changing the buffer size by one of the apps involved - most likely iPolysix. We weren't able to test it before KORG launched it so right now we can only guess.

While I couldn't reproduce this on an iPad 2 (currently don't have an iPad mini to test on), I can probably explain while launching NLog first solves it:

All Audiobus enabled apps are required to run on a buffer size of 256 frames. We ask developers to make sure of that because in iOS, whichever app is in the foreground first and can create audio, that app dictates buffersize.
In this case it seems like iPolysix is maybe changing the buffersize to something higher and thus becomes incompatible with the other Audiobus enabled apps and the distorted sound you hear is the result.

Mind you, we're still not entirely sure how this whole process works like, which app dictates the buffersize and if it needs to be in the foreground, permanently running, etc. The only way to ensure that everything's fine is to just build apps well and make them fast enough to all run on the (very low) buffer size of 256.

Now to your workaround: When you launch NLog first after having closed every other app, it sets the buffer size to - you guessed it - 256. And iPolysix can't change it back, because iPolysix was first. I think it would be enough for you to just run Audiobus first, because that does the same. But that's for you to try - as I've said I can't reproduce the error on an iPad 2.

I know this might all be confusing but this is the stuff we hide from our users to make everything look like it's super simple.

Sorry for the inconvenience,

Sebastian

litebritedeath82

Running audiobus first does not fix the problem on my mini but launching nlog pro first does! If I just launch audiobus first I still get the same glitchy mess in ipolysix. So glad to see a workaround. I was pretty bummed last night when it would not work at all.

Sebastian

I've just talked with KORG and iPolysix in fact starts up in 1024 frames buffersize so it's probably best to start with an app that sets the buffersize to 256 first. In your case that's NLog, but it should work with Audiobus, SoundPrism Pro or any other audiobus compatible app...

We're going to have to talk to Apple to figure this out eventually.

j_liljedahl

Are you 100% sure NLog sets the buffersize to 256? It could also be that it sets a bigger size (512 or 1024) and that this then means that audiobus can't change it down to 256, so all apps will run with the bigger buffersize, meaning higher throughput and less glitches (but longer latency).

As far as I know, an app can ask for any preferred buffersize, but it's important that they are able to adapt to the actual buffersize used by checking the number of frames passed to their audio callbacks.

Sebastian

No, I'm not 100% sure. I'd have to ask Rolf. Which I will

nlog

Hi Friends,

this is how it works:

AudioBus has a fixed preferred buffer size of 256. This is simply too short for some devices like iPad mini or iPad2. Especially when involving multiple CPU hungry apps like polyphonic synths etc.

For these devices a larger buffer size of 512 works better at a little cost of extra latency which is acceptable if you trade this with avoidance of crackling.

If you start NLog before all other apps, NLog decides the buffer size in a way AudioBus and other apps are not able to change it to something else. NLog chooses the buffer size depending on the device like 1024 for iPad1, 512 for iPad2 & mini, 256 for iPad3 & 4. I made some extended tests and they seem to be a good compromise. Also they are based on 4 years of iOS synth experience ;-)

This is why NLog is able to do that:

iOS has some specific un-documented mechanisms of setting the buffer size. All apps have to use same buffer size, so they might request a specific one, but iOS might decide differently in order to find the optimum for all apps.

In order to make this decisions, iOS uses some extra information which is contained in the "Audio Session Type". Each app registers its audio work to be handle within a specific session type. There are a couple of these types. For example apps, which just produces audio but don't consume from input, are using some kind of playback session type. Other apps which read from input are using a recording session type.

When testing NLog with AudioBus I found out a mechanism how iOS manages the buffer size. The first app with a recording session type determines the buffer size. Other apps later cannot change it to something, no playback apps nor recording apps.

NLog is a recording app since it reads from the audio input for effect processing. Thus, when you start NLog first, all is fine. You even do not need to put NLog into AudioBus. It just works since NLog manages the buffer size depending on the device capabilities.

Hope that helps!

Best
Rolf

Sebastian

Thanks man! Helpful and competent, as always...

Michael_R_Grant

Rolf, can you change the buffer size from within Nlog yourself if you want to? I'm just thinking of how opening two/three CPU intensive apps in Audiobus causes all iPad models up to and including iPad 3 to start audio crackling, and whether a nice workaround in future would be to start Nlog, set the buffer size yourself and then start Audiobus.

Leading on from that, if I CLOSED Nlog but kept the other apps open, would the buffer size stay the same as where I left it with Nlog or would it move to a new value automatically?

Let me illustrate my thinking. Is the following how it would work? Example:
1. Open Nlog, set buffer to 512
2. Open Audiobus, buffer stays at 512
3. Open Magellan, buffer stays at 512
4. Close Nlog (double tap home, close app from there), buffer STAYS at 512 despite Nlog not being open anymore?

If so, then when Animoog and Auria arrive with Audiobus support, we could indulge in some clever-ish CPU management if necessary. And Sebastian, maybe changing buffer size could be an advanced option from within Audiobus in future updates if it proves to be a useful thing? Not one that's obvious, but buried in a menu somewhere for people who want to fiddle!

OliverImseng

Yes veery interesting, thanks. So as I suspected at the moment its down to the order in which you load apps. I mean we are in the early stages and once all Dev's adapt their apps to run at 256 everything should be fine.

Another thought, would the performance improve if you ran a Class Compliant USB Audio interface on the CCK? Would be interesting if someone can test that.

Sebastian

I'd like to mention to everyone in here that workarounds like this one are extremely counterproductive to getting a stable and low latency (and thus, usable) audio system established on iOS.

We've tried very hard to make sure that everyone adapts to making their apps compatible with 256 frames and we've reven increased our requirements for Audiobus, thus reducing our own sales because all the guys with iPhone 4 and iPad 1's can't join the party. To now again increase latency via some backflips and secret settings would jeopardise many accomplishments.

I know this is easy to say for someone who is not limited to 'slower' iDevices like and iPad 2 or mini, but I feel like this has to be said.

jonmoore

@nlog,

This is incredibly useful information. So if I use the same logic and open Megellan before Audiobus (which allows you to decide on the buffer size all the way up to a whopping 2048 samples) this will allow me the best processing power for sequencing multiple instruments at once. A buffer size of 2048 will obviously be too slow for live playing but could be ideal for sequencer driven stuff.

From what I understand Auria operates at 4096 samples so hopefully Auria will provide the best option possible for sequencing multiple instruments. When recording through Auria you can configure the buffer size from anywhere between 128 & 4096 samples so you should be able to record multiple instruments at the same time at the larger settings. Very good news for those of us that rely on sequencers to create our music.

As a side note it would make sense to me that the audio buffer should be configurable through Audiobus so the end user is always in control. 256 samples makes sense for when you want to capture a live performance but the large buffer settings will allow for far greater multi-timbrality for sequenced instruments where latency isn't so much of an issue. Higher buffers should also allow the midi clock sync to do its thing with far greater accuracy.

jm

http://soundcloud.com/leftside-wobble

j_liljedahl

@nlog, thanks, that's what I thought.

I know that the audiobus guys have really thought about this, and decided to force a 256 sample buffersize. But, sorry for being a PITA, I don't think it's the right decision. The reason that an app has the ability to ask iOS for a preferred buffersize is just that - the preferred size depends on the situation, resources and demands. A user that owns an "old" device will of course prefer longer latency than broken unusable audio! Even users with new fast devices will prefer to run the combination of apps they want to use, without glitches. This means, users will continue to work around the 256 enforcement by using tricks like this.

I don't think it's fair to talk about being "compatible" with 256 frames buffersize, the ability to go down at this low latency or not depends on many factors: the combination of apps, the hardware it's running on, the complexity of the synth presets or whatever the user has loaded or created in those apps, etc..

So, please consider adding a user setting for the buffersize. It could even be put in the global Settings app so as to not clutter up the Audiobus app UI.

And I'm sorry if I'm sounding harsh, I just feel kind of strongly about this issue.

Cheers,
Jonatan (developer of Gestrument, BitWiz, AudioShare, ProLoop, Nord Beat)

jonmoore

I'm totally with you Jonathan on this issue. And I don't think you're sounding harsh by any means.

jm

http://soundcloud.com/leftside-wobble

Sebastian

We'd have to do it in a way that makes sure every app supports 256 frames. As soon as we 'allow' developers to start at higher frame sizes, they are going to do it, which in turn would again break things.

I'm also not a fan of making things configurable in such a manner, at least not in a way that makes it easy for users to misconfigure things because they don't fully understand what's going on.

Audiobus is not made with hard-core musicians in mind who understand things like latency and buffer sizes. If that would have been our goal, we would have been able to launch it after half the development time. But at the same time, it would not appeal to the same audience and have the potential to open up the possibilities of great music apps to users who are not familiar with all of this technology.

TL;DR: Audiobus Pro anyone?

PS: I hear what you guys are saying. Adding a settings screen or panel with all the stuff that needs to be configured is always the last option. I also feel very strongly about that because it means we have failed to find an easier way to do it. Sometimes it can't be avoided though. Audiobus does not have a settings screen because we forgot to put one in but because we spent countless hours on designing the UI in a way that it doesn't need one - at least right now. This is a pretty long PS.

litebritedeath82

I agree. If the forced buffer size was working very well with synth apps I would understand but when it's causing more issues then its creating I don't understand the need. Even though the ipad 2 and ipad mini are listed as compatible most of the synths that I have that are audiobus compatible have major issues due to the forced buffer size. The NLOG cheat has made them all very usuable.

Sebastian

Please note that higher buffer sizes also mean higher latency. At every node of the connection graph. What you might consider usable someone else might consider completely unusable because they can't play a groove anymore because of the latency.

I'd also like to mention that this situation is exactly why we haven't published the SDK yet, since we've expected things like this to happen that we might have to find a solution to. I'm also going to note that distorted sound in a synth is making it as unusable as very high latency.

What I'd like to know though is where to draw the line: what can we reasonably expect of developers? Can we ask them to make their stuff better, faster? Who's at fault if they can't or won't? In my opinion the big issue here is that the same users who know how to adjust latency and buffer sizes of their apps are the ones who are going to complain about effects and multiple apps in more complicated graphs adding too much latency or Audiobus 'being too slow'. And once that stigma is established the whole platform suffers.

I'm going to talk about this with Mike when he gets back from his well deserved evening off.

litebritedeath82

I also understand that you want to make your app as easy to use and as user friendly as possible but sometimes I feel that if you really enjoy something it's worth learning about. I don't consider myself even musically inclined but I am glad I know about and understand terms like latency and buffer sizes. If I had no knowledge of these things I would be SUPER dissapointed in audiobus as it works with my ipad mini and would not have left the five star rating I did. I purchased the mini specifically for audiobus once I learned my iPhone 4 would not work. If I came into audiobus with no knowledge of electronic music and this forum with the workarounds I would think audiobus was broken and without any settings to adjust would sit around bummed and angry.

jonmoore

Sebastian, I would have to disagree wih you on this matter. When Propellerheads launched Reason it was very much aimed at hobbyists but those same users had to cope with things such as buffer size's, audio drivers and midi configurations.

IMHO, in your quest for simplicity, ironically you've actually made things slightly more complicated. Audiobus is heavily reliant on the order that you launch apps and how you configure virtual midi across those apps. I've been monitoring various audio forums over the last week and there are already a huge number of work-arounds and 'hacks' being shared so that people can get the best out of Audiobus for their own requirements.

I’m not intending to be negative here as I really do beleive you've delivered a game changing solution for IOS musicians. I just hope that you listen to the feedback from you're existing customer base whilst iterating the Audiobus feature set.

Simplicity is a central tenet I apply to most things in life and I still beleive it to be the foundation that Audiobus is built from, however not all configuration options increase complexity.

Just my ten cents anyway...

jm

http://soundcloud.com/leftside-wobble

Sebastian

I hear you.
To me this is all a question of confronting the user with the exact amount of complexity that he or she can handle at the moment. We're going to figure out how to do that and a few weeks after we do that you'll hold it in your hands.

litebritedeath82

audio(short)bus toggle

litebritedeath82

litebritedeath82

Options are great tools for helping people fix their own problems. When I was learning fruity loops ages ago it took some searching and trial and error but the sense of self satisfaction I got when I fixed an audio problem or made something run better kept me at it. I believe it's better to have options that people can explore to get the best out of their personal set ups then to just limit them to background workarounds and hacks.

Michael_R_Grant

My two cents as a layperson who struggles with Virtual MIDI ports, knows little about synth theory and is only learning about buffers and latency from this very thread:

Sebastian is so right about how Audiobus's simplicity is a key component of the system; that if latency could be increased by app developers then they would do it, and how delving into countless menus isn't what the app is meant to be about.

But others commenting here are also right when they say the user experience on iPad 2 and iPad Mini suffers when people try to open too many apps at once (or fail to shut apps down properly once ejected, not knowing they're still "on"); how this may be blamed on the app itself by anyone who doesn't appreciate the limits of their device.

So how about some kind of CPU monitor running in the background? Magellan does this, and Auria, Audulus etc. Audiobus could recognise when the load is reaching the kind of level where problems will occur and inform the user through a warning message, advising them to close apps or give other tips for managing CPU resources.

Meanwhile, advanced users could have access to some of the options listed in this thread in order to configure the app - at least, those that don't go against the ethos of Audiobus. They would therefore be potentially happier, while more casual users would have more of a helping hand when it comes to knowing about the limits of their devices.

Sebastian

@litebritedeath82: Yeah, that people are running NLog before other stuff just to get the other stuff to work is not something that I find especially thrilling. Says something about NLog though. Swiss army knife of iOS music.

@Michael_R_Grant: Messages and hints in the Audiobus app are not something that's going to be viable since Audiobus spends its time mostly in the background.

litebritedeath82

I actually mentioned the official forums in my review on the App Store. I noticed people giving poor ratings due to simple things like icons not showing up. Being on the forum I knew to delete audiobus and reinstall it. I figured hopefully it will get some frustrated users here and they can get the help they need.

Sebastian

That Icon thing is a bug that we've fixed but we weren't going to submit a new version of Audiobus before the holiday break of iTunes Connect because we wouldn't have been able to submit any bug fixes for bugs that could have appeared in that new version... ahh the complexities of responsible app development. Thanks for trying to bring people over here!

I'm out for today. You guys have fun solving our design problems for us...

I appreciate the discussion.

Will

I love this thread and am glad it's not confined to the developer forum.

Maybe the options are simply a toggle for 'Play Live' and 'Sequence'? No confusing info about buffer sizes. Those do to the buffer sizes what you'd expect.

Or a single big sexy knob with the labels 'Faster' on the left and 'More Power' on the right. Or something. Again, no scary words like 'buffer' but it would cycle through the appropriate buffer lengths.

In both cases, it would require letting a user know if another app had already taken control of the audio subsystem. And I guess that's where 'everyone just use 256 please' gets awfully appealing. I wouldn't mind being told to always start Audiobus first to control latency but yeah, things start getting away from 'simple' right about there.

It took MIDI over a decade to level out! Getting that many different makers on board was hard and they had about 1/20 of the 'interested parties' the AB team is looking at.

j_liljedahl

I really like the idea with Faster -> More Power

The situation where an app has already decided the audio system buffersize is a problem, yes. One could gray out the Fast/Power knob and show a tappable info button on it, which links directly into the Help tab to a section explaining that all other recording apps (red status bar) need to be closed before this knob can be used.

Also, can the buffer size of a non-recording app change while it's running, due to another (recording) app asking for a new buffersize? If yes, good. If no, also non-recording apps needs to be closed before the fast/power knob can be used.

Crabman

@Mchael-R-Grant:i'm sorry but i guess most of us are not talking about"countless menus"in audiobus or "too many apps open".

we just talk about ONE Option (set the buffer size) to use ONE app at once.The iPolysix.Its not working even with nothing else in the background thats just fact.Well,at least for(most)ipad 2/Mini user without having access to Nlog (have to purchase it soon^^).

I'm a big fan of the absolut clear and simple layout of audiobus (reminds me of better apple days :-) ) but i'm not sure if you probably underestimate the (audio) consumer a bit.A small option for setting the buffersize wouldn't hurt anybody imo.But prevents people like me to run into the next store to purchase an iPad 4

Guess the more important point is that you force the developer to set their buffer to 256 and i understand your point of view completely.Well,i'm glad it's not me to make this decision

I'll go and grab Nlog.If it works,fine.But its a little bit the opposite to this supereasy workflow that audiobus suggest.