Re: (iOS AUv3) memory limit for AU Extensions
Re: (iOS AUv3) memory limit for AU Extensions
- Subject: Re: (iOS AUv3) memory limit for AU Extensions
- From: Doug Wyatt <email@hidden>
- Date: Wed, 15 Aug 2018 13:03:03 -0700
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@hidden> 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@hidden> 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@hidden> 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@hidden> 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@hidden>
>>>> Sent: Friday, July 27, 2018 11:20:40 AM
>>>> To: Bram Bos; email@hidden
>>>> 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@hidden)
>>>> Help/Unsubscribe/Update your Subscription:
>>>>
>>>> This email sent to email@hidden
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Coreaudio-api mailing list (email@hidden)
>>> 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@hidden
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Coreaudio-api mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Coreaudio-api mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden