Re: (iOS AUv3) memory limit for AU Extensions
I see the limit it now 512. > On Aug 15, 2018, at 15:03, Doug Wyatt 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 > <mailto:dwy...@apple.com>> 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 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 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 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 >>>>> Sent: Friday, July 27, 2018 11:20:40 AM >>>>> To: Bram Bos; coreaudio-api@lists.apple.com >>>>> 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
Re: (iOS AUv3) memory limit for AU Extensions
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 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 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 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 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 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 >>>>> Sent: Friday, July 27, 2018 11:20:40 AM >>>>> To: Bram Bos; coreaudio-api@lists.apple.com >>>>> 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 >>>>
Re: (iOS AUv3) memory limit for AU Extensions
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 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 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 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 >>> Sent: Friday, July 27, 2018 11:20:40 AM >>> To: Bram Bos; coreaudio-api@lists.apple.com >>> 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 (Coreaudio-api@lists.apple.com) >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/coreaudio-api/lucas%40goosesoft.com >>> >>> This email sent to lu...@goosesoft.com >> ___ >> Do not post admin requests to the list. They will be ignored. >> Coreaudio-api mailing list (Coreaudio-api@lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.apple.com_mailman_options_coreaudio-2Dapi_damiani-2540ufl.edu=DwICAg=pZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2KikqINpWlZM=YihhonIjnlIN6Wuo58LaXg=4jIw13vgpENHaNfzMopO5jmDcbH79YNTJTKmaja54dY=2NGu-FxLbzU184S0E1-b1v1c1930ceG1aE1NahHT3qo= >> >> This email sent to dami...@ufl.edu > ___ > Do not post admin requests to the list. They will be ignored. > Coreaudio-api mailing list (Coreaudio-api@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/coreaudio-api/dwyatt%40apple.com > > This email sent to dwy...@apple.com ___ Do not post admin requests to the list. They will be ignored. Coreaudio-api mailing list (Coreaudio-api@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/coreaudio-api/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: (iOS AUv3) memory limit for AU Extensions
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 mailto:lu...@goosesoft.com>> 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 mailto:bram...@outlook.com>> 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 mailto:p.sand...@alpinesoft.co.uk>> Sent: Friday, July 27, 2018 11:20:40 AM To: Bram Bos; coreaudio-api@lists.apple.com<mailto:coreaudio-api@lists.apple.com> 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 (Coreaudio-api@lists.apple.com<mailto:Coreaudio-api@lists.apple.com>) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/coreaudio-api/lucas%40goosesoft.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.apple.com_mailman_options_coreaudio-2Dapi_lucas-2540goosesoft.com=DwMFaQ=pZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2KikqINpWlZM=YihhonIjnlIN6Wuo58LaXg=4jIw13vgpENHaNfzMopO5jmDcbH79YNTJTKmaja54dY=YuU47-8r6ZFQSiVG5vZtWv4mw3pcYjKReQe0GlV_n9g=> This email sent to lu...@goosesoft.com<mailto:lu...@goosesoft.com> ___ Do not post admin requests to the list. They will be ignored. Coreaudio-api mailing list (Coreaudio-api@lists.apple.com<mailto:Coreaudio-api@lists.apple.com>) Help/Unsubscribe/Update your Subscription: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.apple.com_mailman_options_coreaudio-2Dapi_damiani-2540ufl.edu=DwICAg=pZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2KikqINpWlZM=YihhonIjnlIN6Wuo58LaXg=4jIw13vgpENHaNfzMopO5jmDcbH79YNTJTKmaja54dY=2NGu-FxLbzU184S0E1-b1v1c1930ceG1aE1NahHT3qo= This email sent to dami...@ufl.edu<mailto:dami...@ufl.edu> ___ Do not post admin requests to the list. They will be ignored. Coreaudio-api mailing list (Coreaudio-api@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/coreaudio-api/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: (iOS AUv3) memory limit for AU Extensions
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 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 > Sent: Friday, July 27, 2018 11:20:40 AM > To: Bram Bos; coreaudio-api@lists.apple.com > 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 (Coreaudio-api@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/coreaudio-api/lucas%40goosesoft.com > > This email sent to lu...@goosesoft.com ___ Do not post admin requests to the list. They will be ignored. Coreaudio-api mailing list (Coreaudio-api@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/coreaudio-api/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: (iOS AUv3) memory limit for AU Extensions
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 Sent: Friday, July 27, 2018 11:20:40 AM To: Bram Bos; coreaudio-api@lists.apple.com 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 (Coreaudio-api@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/coreaudio-api/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: (iOS AUv3) memory limit for AU Extensions
For a sample based synth, this is quite easy to achieve. I, for one, would like to see this restrictions removed as well. Le 27/07/2018 à 11:20, Paul Sanders a écrit : 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 (Coreaudio-api@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/coreaudio-api/o.tristan%40uvi.net This email sent to o.tris...@uvi.net -- Olivier Tristan Research & Development www.uvi.net ___ Do not post admin requests to the list. They will be ignored. Coreaudio-api mailing list (Coreaudio-api@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/coreaudio-api/archive%40mail-archive.com This email sent to arch...@mail-archive.com
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 (Coreaudio-api@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/coreaudio-api/archive%40mail-archive.com This email sent to arch...@mail-archive.com
