Loopy Pro: Create music, your way.
What is Loopy Pro? — Loopy Pro is a powerful, flexible, and intuitive live looper, sampler, clip launcher and DAW for iPhone and iPad. At its core, it allows you to record and layer sounds in real-time to create complex musical arrangements. But it doesn’t stop there—Loopy Pro offers advanced tools to customize your workflow, build dynamic performance setups, and create a seamless connection between instruments, effects, and external gear.
Use it for live looping, sequencing, arranging, mixing, and much more. Whether you're a live performer, a producer, or just experimenting with sound, Loopy Pro helps you take control of your creative process.
Download on the App StoreLoopy Pro is your all-in-one musical toolkit. Try it for free today.
44.1khz or 48khz for better iPad and app performance?
I was just wondering what the experts thought here as my searches brought forth conflicting opinion.
As far as iPad performance is concerned any benefits for either to work with? I dont publish my work so no industry standards need be observed etc, but I was thinking about performance and file sizes etc.
Thank you.
db
Comments
Your life will be easier if you set your DAW to 48khz. You can still mixdown to 44.1, but iPads generally work better at the native 48khz.
iPad defaults to 48khz but some apps just run better at 44.1khz for me.
44.1 kHz gives you about 9% more CPU headroom compared to 48 kHz. The difference in sound quality is negligible at best. The sample rates that your audio hardware supports have nothing to do with it. 44.1 kHz will give you better performance on any hardware. The only variable that has to do with the hardware is the final sample rate conversion from whatever you're using in your DAW to the rate the hardware supports or is using, which has essentially zero CPU impact.
Disclaimer: this is a technical birdseye view in an optimal world with textbook implementations in all involved software and operating system APIs. Real mileage may differ 😃
At first read I thought you were saying that CPU use would be 9% lower overall with 44.1 kHz. Is that what you're saying, or are you saying that just the fraction of affected overall processing that is dealing specifically with audio would be 9% more efficient?
It seems unlikely to me that just changing sample rates between 44.1 kHz and 48 kHz would result in any difference in what we typically see as CPU or DSP percentage utilization. It seems like it would be a much smaller contribution in context of everything else going on. I have no idea if that hunch is correct or not, so I'm asking. 😎
(and yes, I know the limitations of CPU measurements in iOS/iPadOS)
Yes that's what I was saying. This was under the assumption that the majority of CPU time in a realtime audio environment would indeed be dedicated to audio stuff. Which is admittedly a bit naive 😇
I did a slightly unscientific test by running Xequence Audio on Linux (with a proper way to measure CPU Time) with the exact same project, exact same length of time running the timeline, and once with 44.1 kHz and again with 48 kHz, here's the result:
So the difference in practice in this specific setup is roughly 4%, not 9%. So I stand corrected 😄
Still, whatever you're doing, using a lower sample rate MUST improve CPU utilization, as still most of the CPU time spent in a realtime audio environment is in DSP code, which, well, has to either process 48000 samples per second or 44100!
NB: Ignore the memory usage. That's a memory leak in Chromium's Web Audio code that I've reported 😄 wasn't me! ☝
Thanks for that detailed answer @SevenSystems. That's really good to know. I wouldn't put it too high on my priority list of reasons to go 44.1 vs 48, but sometimes every little bit can help. That coupled with the lingering problems with a few apps running at other sample rates might make a difference though.
Another factor is iDAM. That gets forced to 44.1 kHz. So if most of what someone is doing has been at 48 kHz, if they enable an iDAM connection, sample rate gets overridden.
OK, interesting. Yeah, my posts are always a bit black & white, but my main point is that so many people seem to be somehow worried about some mystical connection between their audio hardware and the sample rate they're using in their DAW, while there is really none (or shouldn't be).
Heck, it should be possible to set a DAW to 66.666 kHz and it should work with any hardware, as there will always be a final conversion step in the operating system or audio driver that converts whatever nutcase buffer comes in to a rate the hardware supports.
Great info @SevenSystems keep them technical details coming. Love it. 👍🏼
I barely understand any of this most of the time.
Higher sample-rate usually gives slightly lower latency and as well so it's a give or take situation...
...On iOS most audio passes thru CoreAudio before being heard and gets re-sampled to the target sample-rate used/selected on the playback device if there's a mismatch between the source and the destination.
IDAM is in general pretty bizarre with its locked sample-rate...
Don't assume I do 🤣 I obviously am talking from a birdseye view as mentioned and don't know all implementation details in all DAWs or operating systems.
The gist of it is: The sample rate in your DAW just determines how accurately the DAW "paints" the audio. The sample rate of your hardware determines how accurately it can reproduce audio it gets from the software. Between the two, there's almost always a "converter" that can (should be able to) take audio at any sample rate from the software, and then turn it into a sample rate that the hardware supports.
The sample rate chosen by a DAW is, in theory, a completely arbitrary number. The sample rate of hardware is actually more "cast in silicon" and thus can't be changed, so the conversion step is necessary.
Man I'm too wordy tonight. Must be because I'm nervous about the election even though I'm not American 😂
There's another layer to this - plugin sample rate handling. Some plugins still don't adapt properly to the sample rate that the DAW is working in. Some take the hardware sample rate and some are clueless and just assume a particular sample rate. Thankfully that's becoming less frequent.
Then there are IAA apps. The first app to grab the sample rate prevents DAWs from changing it. This can add to the weirdness.
Your point that DAWs should be able to work at any sample rate is clear and very good to know. Too bad Apple has made such an incomprehensible muddle out of the whole thing though.
Ha ha! I wonder if it was you that first pointed this out to me, or someone else. That's probably the first (and only) thing I think I understood and retained about DSP.
At the same buffer sizes, 48 kHz should give 9% lower latency than 44.1 kHz. 96 kHz should give 1/2 the latency of 48 kHz. At the cost of higher CPU.
Exactly. Although it would be pretty stupid to use a higher sample rate JUST to get lower latency, because you get an "unwanted", useless audio quality and CPU usage increase as a side-effect.
It would then be better to just straight offer smaller buffer sizes.
The only reason why this would make sense is if you, say, can still run your project at 256 samples, but it starts crackling at 128, and as buffer sizes always have to be a power of 2 and you can't have, say, a 192 samples buffer, you can indeed get 9% lower latency than 256 by using 48 kHz instead of 44.1 kHz.
Fwiw, if you are using an audio interface, either 44.1kHz or 48kHz, go with what is convenient.
If not using an interface, iPads and iPhones since 2017 or 2018 (even those that support both 44.1 k and 48k) are 48k based and sometimes exhibit anomalous behavior because the hardware is based on 48k and does some weird behind the scenes stuff —including the real buffers not being quite what you would expect and timestamps sometimes being funky.
Michael jumped through a lot of hoops in Loopy Pro to get things working smoothly on iPad 6’s and similar devices running at 44.1k without an audio interface. (In AUM, it manifests in the same situation as loops being a few samples too long or too short in some circumstances )