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.
AUM crashes on open if default sample rate is not 44.1 khz
I have my ipad connected to a Moto 828es. When AUM is not open, it appears to default to 44.1khz. When I open AUM, I can set the sample rate to a different value... sometimes... often with a lot of effort and random errors before finally finding success. Now, I've found that if I set the default sample rate to anything other than 44.1khz, AUM crashes while opening. Any ideas what might be going on here?
Comments
Do you mean the ipad defaults to 44.1 or the moto.
Can you not set the moto to more than 44.1 via some moto software.
Then aum can be set to anything less than the moto settings.
Seems like you got the moto set to 44.1 and you trying to set aum to higher values. 48k plus etc ?
Dont know about this stuff
but seems maybe the drivers for pc cause this
https://www.motunation.com/forum/viewtopic.php?t=64510
and maybe even theres driver updates for apple products?
https://motu.com/techsupport/technotes/apple-silicon-motu-audio-inst
What ipad you got?
If these moto interace needed update for m1 chips.
Then maybe it dosent support m1 ipads?
The MOTO lets you set an internal sample rate, but the connected device can change that. With nothing open, the iPad tells the interface to run at 44.1 kHz. The interface is class compliant and connected to the iPad, so there are no specific drivers. When you open AUM, the default empty project can be set to a specific sample rate. Its default appears to be 44.1 kHz. However, you can update that. I set it to 48 kHz then re-opened AUM… and AUM crashed. I have to unplug my interface and let AUM go back down to the iPad’s internal default to fix it.
However, sometimes AUM will just get completely confused. For example, this last time, I set my MOTU to 48 kHz, then opened AUM. AUM then reset my audio interface to 44.1 kHz, but the settings in AUM say that the sample rate is 0 kHz and it has the wrong device selected for the input. I closed AUM and reopened it again, and now AUM says the sample rate is 48 kHz but my interface says it is 44.1 kHz. I set the interface back to 48 kHz, but now AUM says the internal speaker and mic is the audio source. 🤦♂️
The only way I can get it to reliably work all the time is to set everything to 44.1 kHz. Which kinda sucks when your interface supports up to 192 kHz. I would expect everything to at least work with 48 khz, but AUM is getting all kinds of confused.
What OS version are you running and what iPad?
I use AUM at both 44.1k and 48k with an audio interface. So, this isn’t a generic issue.
Is the interface’s firmware up to date?
Do you have another host app besides AUM?
What buffer size are you using?
Have you tried disconnecting everything, rebooting and reconnecting everything?
@espiegel123 yeah, it’s totally possible that this is a fairly specific issue. I get the feeling that there is something up with the interface and AUM both taking control of the sample rate and then both giving control up. I held off upgrade from 15.x. Finally upgraded to the latest release of iOS 16 today to see if it helped. My audio interface is also up to date. I will give it a try in audiobus tomorrow to see how it behaves. Buffer size doesn’t seem to affect the issue, regardless of what I have it set to. I’ve disconnected and rebooted many times while debugging it.
The way it should work in most cases is the first thing to grab the sample rate owns it. So, for instance, you opened an IAA or standalone app that operates at 44.1kHz, then you open AUM, you won't be able to change the sample rate to 48kHz unless you shut every app down and change AUM to 48kHz. Sometimes a reboot is required as well.
If you plug your interface in first then start AUM, in theory, AUM should open in that sample rate, or at least be able to be set so. Another example: if I have AUM running at 48kHz, then plug lightening ear buds in, it changes to 44.1kHz and can't be changed until the earbuds are removed. Or, if I have iDAM running to my Mac, anything and everything gets forced to 44.1kHz.
Moral(s) of the story? 1) Always reboot when things get weird. 2) Shut everything down, then start up what you would like to own the sample rate first. 3) iOS is weird and iOS sample rates moreso. 4) Remember moral #1.
@wim I agree that is should happen that way, but AUM still seems to be getting confused. Even after a fresh reboot, with my interface unplugged, then setting the desired sample rate on my interface, then plugging it up, then starting AUM, it still gets wonky. It either resets the interface's sample rate, or it just crashes. And if it does reset the sample rate, it's usually completely messed up.
Do you have another host app to try? It might be something about the interface and how it responds to sample rate change requests that is the problem.
Hmm, I've read that the newer MOTUs are class-compliant, but when in class-compliant mode, they can only be set to 48kHz. Strange that only 44.1kHz is useful in your case.
Check that your 828es has the latest firmware.
https://motu.com/en-us/download/#category=1&product=348
And with "crash" you mean AUM closing by itself and leaving you back at the iOS home screen? (Just want to make sure since not all users know exactly what a crash actually means).
The sample rate is ultimately handled by iOS / CoreAudio, when you change the setting in AUM it asks the system for a new preferred sample rate, and the system either changes to it or don't. (If unsupported by the hardware, or some other open app is owning the current audio session).
Let me know how it goes with the recent iOS 16.x, and if possible also try other audio interfaces and host apps to pinpoint the issue. There has been trouble with some audio interfaces in some iOS versions, which has been fixed either by firmware updates for the audio interface or minor iOS updates.
I have had a couple 828es, and have not experienced the issue you are experiencing at all.
No issues changing the sample rate. (iOS 15 and 16, bit App Store ver and betas)
Most likely an app owning the sample rate. Force quit all apps, restart, try AUM again.
Doesn’t hurt to try reinstalling AUM, of iOS. (Don’t restore for a backup initially if you do this)
Yep, I'm up to date on my firmware
Unfortunately, it happens after a fresh restart of the iPad, with nothing else running.
Yes, just to clarify, it is closing completely back to the springboard, and I am on the latest iOS release right now. Do you have a debug build that has crash-reporting enabled? I have a scarlett 2i2 that I can test on as, but I don't recall if there is a way form me to set the sample rate manually on it (haven't used it in a few years).
Interestingly, I just tested Audiobus and it initially seemed to have the same problem... but after another restart of my iPad, Audiobus actually appears to work as expected. It changes the sample rate of my interface correctly when I select different sample rates, and then when I close Audiobus, iOS reverts back to 44.1 kHz.
Just triple-checking, you installed the
firmware update from April 2022?
Yup
Crash logs can be found in device Settings > Privacy > Analytics & Improvements > Analytics Data. You can swipe down in the list to reveal the search box, then look for AUM. I don't have any AUM crash logs so I can't say for sure what the search term should be, but I would expect "AUM" to find them. They'll probably look something like "AUM-" followed by the date and time and an ".ips" extension. Once found, tap on the entry to show the log. At the top-right is the Share icon that you can use to create an email to info @ kymatica.com.
Unless there's a better email address @j_liljedahl ?
That's perfect, thanks @wim.
Yeah I've seen a few crashes where it seems the sample rate is 0 Hz which make things go wrong. I've never been able to reproduce it myself though, so I haven't been able to make that situation handled gracefully.
BTW have you tried turning off Siri?
I've compared notes with Michael before about exactly how we both initialize the audio session and manage sample rates and buffer sizes etc, and we found no important differences that could explain why something like this works in one but breaks in the other. Sometimes it can be a combination of the iOS SDK used when building the app for release, and the installed iOS version, and the firmware of the audio interface, and the exact model of the iOS device, etc. One such known issue is that on some devices, on iOS 16.x, Siri must be disabled to allow changing the buffer size.
Ah thanks, I’ll look for that and send the logs over.
Ok, yes, it does set the sample rate to 0 when I see the crashes. I’ll look for some debug logs to send to you, and I’ll try disabling Siri as well. If you have a debug build with more logging that you want me to run, I can do that as well via TestFlight.
@j_liljedahl I disabled Siri and restarted the iPad. It starts at 44.1. Then I open AUM, and it's still at 44.1. Then I manually set AUM to 48. It hangs for a bit, but then it finally switched to 48 (my MOTU confirms this). I forgot to actually test any audio before I then restarted my iPad again, to try the same process. However, this second time AUM said that it could not set the sample rate, even though it did update the audio interface. When this happens, the sample rate selection menu shows 48 is selected, and the sample rate button (that opens the menu) shows 44.1. The play button is red as well. The buffer size shows an incorrect value as well. I don't see any analytics logs with AUM in the name, but it's definitely crashed to springboard before, so I don't have anything to send (unless there is a different name to look for). Any other steps I can help debug with?
No idea where these sample rate gremlins are coming from unfortunately. Can anyone else with a MOTU replicate this? Or with any other audio interface? I don't think I'll be able to try working around this problem without having access to an audio interface that has this issue.
Is this MOTU directly connected to the iPad or via docking station / dongle? Some dongles refuse to work properly.
This happens even when the interface is connected straight into an apple usb-c to usb-a adapter. I don't have a usb c to usb b cable to test on, but I would assume the apple dongle is good enough to confirm that this is an issue.
That USB needs Thunderbolt speed (min. is 10 Gbit/s per channel) and USB 2 is max. 480 Mbit/s. Find a proper dongle for start.
?
The interface in question should work fine with the USB connection OP mentioned.
Yes, on the paper it should work, the screenshot is from the MOTU official site. Sry. I have pet-peeve with dongles, hope @jscheel wont get me wrong. 😅
Nah, no worries, dongles can be tricky. However, to make sure we are all on the same page: the MOTU 828es does not require thunderbolt, it supports it. It also supports USB 2.0. Here are the specs from the manual:
I've reported this issue to MOTU's support team as well, and asked if they would be willing to loan you a device for testing. Fingers-crossed that they are open to the idea
@jscheel i just sold my last 828es last week so I cant test for you, but i havent had issues with multiple 828es on the same AUM rig for the couple years i had them.
standard questions:
specific troubleshooting:
things you dont wanna hear as options: