Revisiting the crackling noise

Just wanted to ask developers if they can address the crackling noise I get now on many of the patches in the forum. I can use these patches on my first gen iPad Pro with no crackling noise at all. However, on my NEW iPad Pro 2nd gen I get crackling. My understanding is that the the iPad has 120 Hz refresh rate. If the software does not take this into account, it would seem that a patch puts twice the graphics load on the display. Can you build into the software an option for slowing the display to 60 hz, like my 1st gen iPad. This, in my opinion could solve my crackling issues. Thank you for a great program. I hope that this could be an option in your software.

2 Likes

There is an option on the iPad Pro 2nd Gen to limit the refresh to 60Hz, See:

2 Likes

I didn’t know about this! Great tip :slight_smile: Thanks!

If this works well, I feel like it should be permanently pinned to the top of the forum. I also feel like the d/l workaround for iOS could be similarly posted. I found the Workflow app to be my goto method.

1 Like

Unfortunately, this setting did not help. I tried it with several recent patches, including the drum_kit_seq which works very well on 1st gen iPad Pro at around 40% cpu, but uses 97% on new 2nd gen iPad Pro. Can you please program the ability into audulus to run at 60 hz. Thank you

1 Like

If forcing Audulus to run at 60Hz didn’t work in the settings, why would it work to hard program it into Audulus to make it run at 60Hz?

Can you link to the patch you’re talking about? I’d like to try it on my iPad :slight_smile:

Here is the link to ONE of the many patches that cause crackling.

Just because Apple provides a switch in preferences, may not mean that all apps are forced to 60 hz.
The app may have to read the preference settings and adjust accordingly.

This whole crackling issue needs to be seriously addressed. Almost every patch I create that gets slightly complex, it starts causing crackling. Not cool. Especially when every patch works flawlessly on an older iPad.

Once again, this is not an attack on Audulus. I love the program, and you as developers are wonderful to deal with, and the community is marvelous. Let’s please get this worked out together.

If any has successfully used the switch in preferences and got results, please let me know.

Thanks to all
Cheers

1 Like

P.S. I used the drum_seq_kit2 patch as one of many tests.

1 Like

I’ll look into this - but the crackling is caused by refresh rate and something about the way Apple changed the priority of processing for graphics. Its a little over my head but has been talked about in other threads. Just know that @taylor is working on the problem and it will be fixed at some point :slight_smile:

We will also have other CPU saving enhancements that are unrelated to graphics that will expand the overhead of Audulus.

The 60/120 Hz refresh rate setting in System Preference is a system-wide setting and doesn’t need to be queried by an app to take effect. If changing the setting has no effect, then I would have to conclude that the refresh rate is probably not the root cause of the issue. It is possible for an app to request a specific refresh rate down to 30fps, but it sounds like this may not help. In addition to the increased refresh rate, there are certainly other differences between the various iPad models. One area that has caused issues in the past is the native audio sample rate. Since Audulus currently runs at 44.1 kHz, devices that only support 48kHz on the hardware must re-sample which substantially increases the CPU load. This is the case with the later iPhones when running on the internal speaker. Perhaps there is some similar issue with the gen 2 iPads. Apple is not very good at providing detailed hardware information to their developers so identifying the best fix may be difficult. Hopefully @Taylor will be able to come up with a solution. It’s also possible that a new version of iOS may have a fix.

1 Like

That’s interesting.

1 Like

It caused some cracking issues on the iPhone 6 (and later) which was the first device that didn’t switch down to 44.1. It only applied when using the internal speaker, headphones were fine. I’m not sure if it is still an issue. https://forums.developer.apple.com/message/72961#72961 I’m not suggesting that this is the problem, only that you can’t make assumptions about what’s going on under the hood. Like all iOS apps, Audulus doesn’t interact with the hardware directly. To generate audio, an app informs iOS that it would like to produce some sound. iOS requests a buffer full of audio data which the app supplies, iOS requests another buffer etc. A similar process happens with graphics. An app developer generally has little or no control over how iOS deals with the hardware. Generally an app can “request” a specific setting or provide a “hint” but ultimately iOS may or may not honor the request. In the case of the iPhone 6 an app could request a 44.1 kHz sample rate, but if the phone was using the internal speaker, it would remain at 48. If the app didn’t check the actual rate following the request and assumed 44.1 problems would occur. Even if the app behaved correctly, the additional CPU load caused by the need to convert sample rates resulted in less processing cycles available for the app.

2 Likes

I wonder how well this little guy is performing with Audulus.

2 Likes

It would be interesting to find out.

1 Like

Great discussion. Thanks to everyone for your replies and suggestions. I hope we all solve this.

Tried using headphones on my 2nd gen iPad Pro and still get horrible crackling on the more complex patches.

I’m frustrated that my new “whiz bang” iPad Pro is suffering with Audulus. Back to my old 1st gen iPad Pro for my audulus fun!!!

1 Like

I planted a seed on the Audiobus Forum and there has been some interesting discussions about audio performance between various iPad models.

1 Like

This is quite an interesting bug. It’s actually not an issue of the patch being too complex graphically.

Even if I simplify the patch down so almost nothing is being rendered (by putting everything in a subpath), it still glitches.

If I disable animation, it goes away. So I’m going to try to figure out precisely which part of rendering is causing the glitching.

2 Likes

So far, this is looking like a bug with Apple’s OpenGL implementation.

I’m going to try to prepare a bug report tomorrow.

2 Likes

That sounds like good news!

If this proves to be true, Apple will surely fix the issue.

If it would “only” be the effect of the higher priority for graphics or lower priority for audio, i think we would have less chance for a fix.

But anyway, this 44.1 <-> 48 kHz conversion is still problematic and should be fixed by Apple.

Maybe you can adress this as well?

1 Like