AUM crashes on open if default sample rate is not 44.1 khz

jscheel

@AlmostAnonymous said:
@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:

• updated firmware in place?
• tried different cables/dongles?
• does the issue persists on multiple iOS devices?

specific troubleshooting:

• does the issue persists on a mac or PC
• can you change the sample rate in Motu Pro Audio app or on the devices front panel, or is it locked there as well?
• can you change the sample rate for the motu on a mac in audiomidi setup?

things you dont wanna hear as options:

• have you factory reset the MOTU yet from the front panel?

Yep, I'm up to date on firmware, and I've tried different cables and dongles. I don't have another iPad to test on. MacOS works fine (though I currently have another issue open with MOTU about weird pops when system sounds play while other sounds are playing). I can change the sample rate from MacOS, from the MOTU app, and in the device itself. It's been a while since I did a factory reset, but I have done one since this issue presented itself.

Edit: I actually just remembered that I had a lightning camera kit connector, so I tried connecting it to my iPhone... exact same issue and exact same behavior.

AlmostAnonymous

@jscheel What are you settings here:

jscheel

Ok, I have an update from MOTU. @j_liljedahl, you will probably be interested in this:

AVB enabled products (e.g. 828ES) take a longer time to execute USB initiated sample rate changes. During enumeration, Apple's class drivers can make quick transitory sample rate changes that can interrupt AVB streaming, this delay prevents this issue. It seems like iOS is having issues with this prolonged rate change period. We believe this is a contributing factor to the issue you are experiencing. We have filed a report to Apple for further investigation.

I've asked MOTU if they would consider disabling the delay if no AVB devices are present, but obviously Apple needs to get their house in order.

j_liljedahl

@jscheel said:
Ok, I have an update from MOTU. @j_liljedahl, you will probably be interested in this:

AVB enabled products (e.g. 828ES) take a longer time to execute USB initiated sample rate changes. During enumeration, Apple's class drivers can make quick transitory sample rate changes that can interrupt AVB streaming, this delay prevents this issue. It seems like iOS is having issues with this prolonged rate change period. We believe this is a contributing factor to the issue you are experiencing. We have filed a report to Apple for further investigation.

I've asked MOTU if they would consider disabling the delay if no AVB devices are present, but obviously Apple needs to get their house in order.

Interesting! I wonder if this means the MOTU will change back to a real sample rate after this 0Hz state? If so I might be able to just temporarily disable the audio engine until the sample rate is not 0Hz, but unfortunately that's very hard to test without having an actual device that does this.

jscheel

@j_liljedahl said:

@jscheel said:
Ok, I have an update from MOTU. @j_liljedahl, you will probably be interested in this:

AVB enabled products (e.g. 828ES) take a longer time to execute USB initiated sample rate changes. During enumeration, Apple's class drivers can make quick transitory sample rate changes that can interrupt AVB streaming, this delay prevents this issue. It seems like iOS is having issues with this prolonged rate change period. We believe this is a contributing factor to the issue you are experiencing. We have filed a report to Apple for further investigation.

I've asked MOTU if they would consider disabling the delay if no AVB devices are present, but obviously Apple needs to get their house in order.

Interesting! I wonder if this means the MOTU will change back to a real sample rate after this 0Hz state? If so I might be able to just temporarily disable the audio engine until the sample rate is not 0Hz, but unfortunately that's very hard to test without having an actual device that does this.

If you have a TestFlight build, I can test it out for you. I’ll also remind MOTU of my suggestion that they loan you a test device

j_liljedahl

@jscheel said:

@j_liljedahl said:

@jscheel said:
Ok, I have an update from MOTU. @j_liljedahl, you will probably be interested in this:

AVB enabled products (e.g. 828ES) take a longer time to execute USB initiated sample rate changes. During enumeration, Apple's class drivers can make quick transitory sample rate changes that can interrupt AVB streaming, this delay prevents this issue. It seems like iOS is having issues with this prolonged rate change period. We believe this is a contributing factor to the issue you are experiencing. We have filed a report to Apple for further investigation.

I've asked MOTU if they would consider disabling the delay if no AVB devices are present, but obviously Apple needs to get their house in order.

Interesting! I wonder if this means the MOTU will change back to a real sample rate after this 0Hz state? If so I might be able to just temporarily disable the audio engine until the sample rate is not 0Hz, but unfortunately that's very hard to test without having an actual device that does this.

If you have a TestFlight build, I can test it out for you. I’ll also remind MOTU of my suggestion that they loan you a test device

I've sent you a PM!