Re: [Audacity-quality] Crashes due to "Audio Cache" in Directories Preferences

[Gale A. <ga...@au...>]

| From Vaughan Johnson <va...@au...> 
| Thu, 28 Apr 2011 23:25:14 -0700
| Subject: [Audacity-quality] Crashes due to "Audio Cache" in Directories Preferences
> On 4/28/2011 10:20 PM, ga...@au... wrote:
> > 
> > Summary: 
> > 
> > Crashes due to using audio cache for editing are frequently reported (at
> > least 12 per month) so are assumed to occur much more frequently than 
> > this in practice. Do we want this feature in 2.0 "as is"?
> 
> A crash is a bug.
> 
> A bug is not a "feature".

Is it as simple as that?  We have a "feature" that invites crashes because
it deliberately uses up the computer's RAM. Programs crash when RAM 
becomes too low. 

I think there may be a question as to why (on some machines) there are 
reported crashes using this feature when there is still apparently up
to 1 GB of RAM available.   


> 12 per month is what percentage (times 100 or 1000 for estimation...)?
> Please be specific. What do you mean by "much more frequently"?

Who can answer that? There are as many reports of crashes directly 
attributable to "Audio Cache" as there are complaints of users 
accidentally enabling "Snap To".  James reckoned "times 100" for 
Snap To actual cases. I would guess more than that, when 
extrapolated to 2.0. 

For the "12 cases per month" where I have investigated a crash, got an 
answer from user and established the cause is using Audio Cache for edits, 
there are probably another six where an unexplained crash is reported 
and we get no more feedback. Some of those are likely to be Audio Cache
issues.

On the other hand, not everyone will be working with really long tracks or
dozens of shorter tracks, and not everyone will go into Preferences. So I 
would guess "times 50" to be reasonable when extrapolated to 2.0 (some 
of whom will figure out for themselves that Audio Cache is the problem).   


> Does this deserve a Bugzilla entry?

I was hoping for some input before doing that.  Personally I would remove 
the feature for 2.0, because few users understand we are caching all the 
edits. If we keep it, have something like:

Audio Cache

[   ] Use RAM for audio data 
(useful for recording on slow drives, but could crash if 
enabled for repeated editing)  
 
Stop caching if memory falls below: [   ]  MB  

Then remove the verbose explanation we now have about the minimum. 




Gale 
  


> Longer spiel:
> 
> As I (thinly) understand it, we cache without blockfile writing during 
> recording, unless the available RAM falls below the minimum set in 
> Preferences, in which case we write blockfiles instead. Other than 
> during recording, we write an entire copy of the blockfiles to RAM
> (again as long as available RAM exceeds the minimum). Blockfiles
> are still written in this case, so we can recover edits if there is a 
> crash.  
> 
> If cached data is available, Audacity will use that in preference to any
> files on disk.
> 
> I have seen crashes reported on systems Windows XP and above with 
> (on 64-bit systems) as much as 8 GB of installed RAM and as much as 
> 1000 MB set in "Minimum Free Memory". The crashes are not reported
> when recording, but when repeatedly editing the entirety of long tracks.
> The crashes stop as soon as "Audio Cache" is turned off. 
> 
> The people who experience crashes are a mixture of those who 
> deliberately enable the feature and those who do so accidentally.
> 
> I have to say I don't see crashes when I have tried this, even with the
> default 16 MB minimum memory. Initially, processing seems quicker
> than reading from disk, but becomes snail-pace once I get up to about 
> 85% RAM in use. 
> 
> Allowing use of RAM beyond the good use case of making glitch-free 
> recordings seems questionable to me, unless we have one checkbox
> for using RAM only during recording, and a second checkbox that 
> allows RAM for edits as well as recording. Whether we do this or not
> post 2.0, I would rather see the current Preferences text about 
> Audio Cache used for a warning than an explanation of what the
> minimum does.  
> 
> Aside from that, can the minimum available RAM setting work on % 
> remaining rather than a fixed amount remaining?