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: Lucas Goossen <email@hidden>
- Date: Tue, 21 Aug 2018 15:00:26 -0500
Sorry Doug, didn’t mean to do that off list.
That is a very good point. I currently take advantage of the shared process to
share info between instances, and am not sure how that makes me feel at the
thought I might loose that.
> On Aug 15, 2018, at 16:03, Doug Wyatt <email@hidden> wrote:
>
> 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
_______________________________________________
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