Offlist I got a suggestion to provide a per-instance limit. This reinforced the germ of an idea I had -- in theory, we could run each instance in its own XPC service process, each with its own memory limit.
Clearly there's a tradeoff: if AU's are sharing any large-ish chunks of data between instances, that's not possible across processes (except maybe memory-mapped files). Doug > On Aug 15, 2018, at 12:01 , Doug Wyatt <[email protected]> wrote: > > Hi all, > > I realize that to our developers, Radar can sometimes seem like an opaque > black hole, but to be honest, this mailing list is worse :-P If someone would > like to please write a Radar, we can look at it. While in the case of things > like crashing bugs, a reproduction case helps a lot, in this situation, some > concrete suggestions for how to improve things would be useful. > > Due to the limited VM system on iOS, the hard memory limit is not going to go > away, but we would like to reduce pain it's causing. > > Doug > > >> On Jul 27, 2018, at 7:58 , Vieira Damiani, Luis F <[email protected]> wrote: >> >> Even if removing the memory cap is not trivial, providing a warning should >> be straightforward to implement and a good practice. >> >> I agree with Bram that this is a platform, and not an isolated issue, and >> that we should look after each other when it comes to user experience. >> >> Cheers. >> >> On Jul 27, 2018, at 9:39 AM, Lucas Goossen <[email protected]> wrote: >> >>> I think something that is not realized by many developers is that this >>> limit is shared by all instances of the plugin in a particular host. So >>> this means if a user can hit this limitation with even the most >>> conservative memory using plugins. >>> >>> I too would love to see this fixed especially with such big dependence on >>> plugins on the system. >>> >>> On Jul 27, 2018, at 04:28, Bram Bos <[email protected]> wrote: >>> >>>> For me it's mostly a matter of taking precautions. Right now I can open 35 >>>> instances of my most demanding plugin before they all go *poof* >>>> >>>> But I don't like having a product with such a gaping boobytrap in it. >>>> >>>> Having said that, there are currently other plugins out there which are >>>> more sample-heavy or graphics/GUI-heavy which crap out after half a dozen >>>> instances. And it's reflecting badly on the entire platform (with vocal >>>> users concluding the system isn't ready for prime-time yet). >>>> From: Paul Sanders <[email protected]> >>>> Sent: Friday, July 27, 2018 11:20:40 AM >>>> To: Bram Bos; [email protected] >>>> Subject: Re: (iOS AUv3) memory limit for AU Extensions >>>> >>>> I guess my question would be: what are you using so much RAM for in the >>>> first place? Just my $.02. >>>> >>>> Also: please define 'crash'. Thanks. >>>> >>>> Paul Sanders (occasional poster). >>>> >>>> >>>> On 27/07/2018 10:05, Bram Bos wrote: >>>> >>>> Currently, iOS imposes a memory limit for AUv3 extensions. All combined >>>> instances of an AU extension should remain below a cap of 360Mb memory >>>> usage (on 64 bit devices). >>>> >>>> In all hosts I've tested with, crossing this limit will crash all >>>> instances of the extension without warning, often leading to problems like >>>> corrupted projects etc. >>>> >>>> - Are there any known plans to remove this 360Mb cap? Available memory has >>>> doubled/quadrupled since the standard was introduced, so it seems less >>>> necessary now. >>>> >>>> - Is there a way for either hosts or extensions to catch/prevent the crash >>>> from happening in the first place? Something a little more elegant than >>>> going down in flames 😉 >>>> >>>> Thanks for any insights! >>>> _______________________________________________ >>>> Do not post admin requests to the list. They will be ignored. >>>> Coreaudio-api mailing list ([email protected]) >>>> Help/Unsubscribe/Update your Subscription: >>>> https://lists.apple.com/mailman/options/coreaudio-api/lucas%40goosesoft.com >>>> >>>> This email sent to [email protected] >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Coreaudio-api mailing list ([email protected]) >>> Help/Unsubscribe/Update your Subscription: >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.apple.com_mailman_options_coreaudio-2Dapi_damiani-2540ufl.edu&d=DwICAg&c=pZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2KikqINpWlZM&r=YihhonIjnlIN6Wuo58LaXg&m=4jIw13vgpENHaNfzMopO5jmDcbH79YNTJTKmaja54dY&s=2NGu-FxLbzU184S0E1-b1v1c1930ceG1aE1NahHT3qo&e= >>> >>> This email sent to [email protected] >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Coreaudio-api mailing list ([email protected]) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/coreaudio-api/dwyatt%40apple.com >> >> This email sent to [email protected] > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Coreaudio-api mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/coreaudio-api/dwyatt%40apple.com > > This email sent to [email protected] _______________________________________________ Do not post admin requests to the list. They will be ignored. Coreaudio-api mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/coreaudio-api/archive%40mail-archive.com This email sent to [email protected]
