Feature removed. r11835.

It's occurred to me that users who deliberately or otherwise have audio cache enabled in previous versions will now only be able to turn this off in .cfg or in the previous version. So there still is a "crash risk". 

Should we have .cfg check and delete the two Cache* lines on launch (or similar)?

(In reply to comment #2)


> It's occurred to me that users who deliberately or otherwise have audio cache
> enabled in previous versions will now only be able to turn this off in .cfg or
> in the previous version. So there still is a "crash risk". 

Yes, I knew this. That's why I previously commented (in code and on
list) about not yet also removing the code for uses of the setting, vs
what I did, just remove access to it in the Prefs dialog.

The risk is *considerably* smaller on something already MoonPhase. Is it
still P2?

I proposed trying this removal from Prefs for one release cycle, and if
it almost entirely fixes the problem, then removing this pref's code
altogether. 


>
> Should we have .cfg check and delete the two Cache* lines on launch (or
> similar)?
>

No. We should never add code when deleting is easier and cleaner, and
achieves the same result!

...And my explicit intention was to delete eventually, anyway.

I'm fine with deleting all code related to audio cache immediately, if
there's basically no further use for it. Is there any portion of our
user-base that actually benefits from it?

(In reply to comment #3)
>> It's occurred to me that users who deliberately or otherwise have audio 
>> cache enabled in previous versions will now only be able to turn this
>> off in .cfg or in the previous version. So there still is a "crash risk". 
> The risk is *considerably* smaller on something already MoonPhase. Is it
> still P2? 
Yes, if we want to stop the crash reports being made. If the crash is during recording, the recording is unrecoverable. Those who crash do so repeatedly, but the crashes are sensitive to particular machines and to how high Minimum Free Memory is set in .cfg. See below for more explanation.    


> I proposed trying this removal from Prefs for one release cycle, and if
> it almost entirely fixes the problem, then removing this pref's code
> altogether. 
>
> Should we have .cfg check and delete the two Cache* lines on launch (or
> similar)?
>
> No. We should never add code when deleting is easier and cleaner, and
> achieves the same result!
> ...And my explicit intention was to delete eventually, anyway.
> 
> I'm fine with deleting all code related to audio cache immediately, if
> there's basically no further use for it. Is there any portion of our
> user-base that actually benefits from it?
Sorry for length of this, I thought previous threads had answered that. 

As you saw, my view was that we should a) fix it now b) significantly increase the Minimum Free Memory setting as a stopgap solution or c) make it experimental with a view to fixing it properly at some later time. Given the behaviour variability I can't see we are going to do a) for 2.0.2. 

This isn't like CleanSpeech where almost no-one wanted it and the only people turning it on were doing so accidentally. Few are turning audio cache on accidentally.  

There are two distinct groups who can benefit from Audio Cache.

1 Those recording to slow drives (the original aim of the feature). These could be low spec machines per se or it could be user records to a slow external drive because they have space there. Audio Cache helps to protect against skipping in these cases, though does not guarantee against it (user may have to turn anti-virus off or other things). Audio Cache is thus useful and mainly safe for these people - especially if they turn it off after recording. Fortunately, many do that, as their reason for turning it on was to protect recording, but we should IMO have an option to use cache only for recording. 

2 Those with powerful machines and 4 GB or more RAM who turn the feature on to speed up response during playback, editing and exporting. This group is where almost all the crashes occur. Some of these people are only on 32-bit OS so don't realise they can only use 2 GB of RAM for Audacity (and maybe we don't help by not enabling IMAGE_FILE_LARGE_ADDRESS_AWARE). And some of those on 64-bit OS aren't thinking that Audacity isn't 64-bit, so they are unaware Audacity still has RAM limitations.
** Audacity crashes for this group either long before system RAM falls to the Minimum Free Memory they set (and just before crash, Audacity will often start writing to disk when it shouldn't) or crashes at the time the Audacity minimum is reached (when it rightly does start writing to disk). 
*** If the Audacity Minimum Free Memory is set to at least 1/3 or 1/2 of system RAM, almost all the crashes stop happening. Minimum Free Memory needs to be set higher on Win Vista/7 than XP to prevent crashes. Proviso: Audacity seems to ignore Minimum Free Memory settings above 2500 MB and still uses RAM when system RAM is at e.g. 2100 MB.    
*** The crashes are machine-variable. On my old, 2 GB RAM Win 7 x64 machine  where I have problems with orphans and autosave failures, Audio Cache works completely perfectly, even if Minimum Free Memory is set to the 16 MB default. The x64 6 GB RAM laptop I bought recently crashes frequently with Audio Cache on.      
*** If we ever have 64-bit Audacity then clearly Audio Cache could be a really powerful feature. 

From where we are now, it seems to me there will still be crash reports because users of previous versions will have the feature turned on (and we can have only have them turn it off by editing .cfg).

(In reply to comment #4)

Thanks for all that, Gale. 

I just did (a) with r11851. 

I thought my previous quick fix was fine for a short release cycle.

Tests OK on all three platforms launching with .cfg that enables the feature. 

As we link to this bug in the code comments for audio cache, I figure we should reopen this as P4 so that user interest in it is recorded (done). Title changed from "Crash Risk if enabling Audio Cache (10 reports per month)" to "Audio Cache deprecated from releases due to crash risk".

As far as I can recall we have had no further user reports of this or comments about it for five years.

And Gale wrote:
>Tests OK on all three platforms launching with .cfg that enables the feature. 


Accordingly I am going to close this