Audacity Recording Freeze at 38m 47.5s: Win7

[otwo_pipes]

@Gale
Hi.. I have made measurements as requested.
I captured samples at 24/96 with the minimum memory set to 100MB and Audacity crashed but interestingly the Available Memory is 300MB, see the attachment. Also, prior to crashing Audacity does appear to be functioning correctly regarding writing data to disc as the Available Memory decreases slowly and then hovers around the 300MB mark and no longer decreases as the digitised audio is captured. Most interesting don't you think?
When Audacity has crashed the Audio Position counter is still functioning, see the different timings between the Audio Position counter and the captured Audio waveform display. The audio level meters are still functioning and audio is routed into and out of the S/PDIF connections on the M-Audio sound card. If I kill Audacity, or stop Audacity recording sound is no longer routed through the S/PDIF connections
I have also set the minimum memory to 1000MB and this has been running for over 2 hours. The only difference I can see between the Audio Cache enabled/disabled is the Commit (MB) slowly increases when the Audio Cache is enabled (See the Windows Task Manager snap in the bottom left corner of the attachment.) The Commit Memory is shown above the 'Resource Monitor' Activation Button. When the Audio Cache is disabled the Commit Memory starts at, and hovers, around 995MB.
I have also hammered the system, when capturing audio with the cache set to 1000MB, by opening Firefox, Internet Explorer, Opera & Chrome with mulltiple tabs and websites in each browser and the Available memory dropped to under 100MB whilst Commit rose to over 3000MB. After the hammering, with all browser windows still open, Windows slowly recovered and had over 500MB memory available but commit was still at 2995 MB. During this hammering Audacity was still working correctly after 1hr:45mins
I don't have any more ideas and it is late so any suggestions?
Apologies if I have not made myself clear but as I said, it is late.
Dennis

[Gale Andrews]

Dennis, thanks for the tests.

I captured samples at 24/96 with the minimum memory set to 100MB and Audacity crashed but interestingly the Available Memory is 300MB, see the attachment. Also, prior to crashing Audacity does appear to be functioning correctly regarding writing data to disc as the Available Memory decreases slowly and then hovers around the 300MB mark and no longer decreases as the digitised audio is captured.

Assuming you are not recording into a saved project, have you looked at the Audacity temporary directory to verify that .au files are being written there when system memory falls to 300 MB? The temporary directory is noted above "Audio Cache" in the Audacity "Directories" Preferences. If the.au files are being written, it is not correct. With an Audacity Preferences limit of 100 MB, Audacity should be continuing to use RAM and not writing anything to disk until the system memory falls below 100 MB. It is possible that crashes occur when Audacity is incorrectly writing to disk when it should be writing to RAM (according to the "Minimum Free Memory" limit). But that is only speculation.

I have also hammered the system, when capturing audio with the cache set to 1000MB, by opening Firefox, Internet Explorer, Opera & Chrome with mulltiple tabs and websites in each browser and the Available memory dropped to under 100MB whilst Commit rose to over 3000MB. After the hammering, with all browser windows still open, Windows slowly recovered and had over 500MB memory available but commit was still at 2995 MB. During this hammering Audacity was still working correctly after 1hr:45mins

If Audacity started writing .au files after the system available memory fell below 1000 MB, that's OK. However having to set a 1000 MB limit gives you very little benefit, only 300 MB of usable RAM if you usually start from about 1300 MB free,



Gale

[Gale Andrews]

At the moment, reset is done by editing the audacity.cfg settings file

Or during install of v2.0.1 if the box is ticked!

Indeed, but that's a clumsy way for more experienced users in my view.

However thanks for the note because I see we did not mention this in the Manual at http://manual.audacityteam.org/man/Preferences#reset which we should do I think, even if it is in the FAQ. I added some text there.


Gale

[otwo_pipes]

Hi Gale
Regarding the configuration file I have to ask, "Who reads the manual?" I sure did not, I know I know everyone will say the manual is there for a reason but being an ex-electronics professional I don't read manuals unless absolutely necessary. Sorry.
Maybe that is why this thread was originally started; my lack of reading the manual! Then again if eventually we find a root cause so much the better............
I still feel a save/restore default/user configurations would be very useful. Maybe it is a matter of convincing the powers that be.
As to your suggestions questions etc. re the original thread, that is a task for this evening when I finish the days archiving of my vinyl collection...
Watch this space ...
br Dennis

[steve]

being an ex-electronics professional I don't read manuals unless absolutely necessary.

Strange that. Being an ex-electronics professional myself, I do read manuals
One notable exception was Audacity, as when I first started using it the manual hadn't been written (at least, not much, and it wasn't included in the standard download).

You're quite right though, most of the forum questions could be answered in 4 letters: rtfm. (or as I prefer; read my signature )
The forum is here as a second line back-up to the manual, but mostly the answers are in the documentation (FAQ, manual or wiki).

For your information, Gale and myself have been discussing the "use RAM" feature and there is definitely something wrong with it but as yet we're not quite sure exactly what it is that is wrong.

[otwo_pipes]

@Steve
Agreed re the manual and the RAM issue.
In my electronics days I had a reputation (good I might add) at breaking sw systems. I was so adept at breaking sw systems I was often tasked to test the systems before release to customers. This testing was undertaken on my own as my style is a little unique. Maybe that is the reason why I dive straight in without reading the manuals. It is what I have grown accustomed to and yes, I know the consequences of this style.
We are agreed on the RAM function being problematic though what the root cause is, at the moment, a mystery. What interests me is the repeatability of the crash timing. It is always, almost exactly, the same. I cannot be certain as to how exact as I have not taken any readings though now we have the photograph of a crash time, in this thread.
This evening I shall capture records at 24/96 and 16/44 whilst monitoring memory usage and HD writes to see if this alters the crash timing.
I will also set the RAM cache to 100MB and the 600MB requested and post the results late this evening.
If there are any other tests you would like me to repeat on my Win 7 system then please let me know as I would also like to get to the bottom of this one.

[Gale Andrews]

Regarding the configuration file I have to ask, "Who reads the manual?" I sure did not, I know I know everyone will say the manual is there for a reason but being an ex-electronics professional I don't read manuals unless absolutely necessary.

That's another cunning reason why the FAQ is included as part of the Manual.

I still feel a save/restore default/user configurations would be very useful.

I have added your vote for a reset (more accessible than now, without having to run the installer to do it).

The only strong rationale for putting it in the Windows installer is that most users assume that running the installer will actually reset the preferences, but by default, it doesn't.

I think most people who support a reset want a button for it in Preferences. At least, that would be a cross-platform solution, though it doesn't cover the case where Audacity won't launch.



Gale

[otwo_pipes]

@Gale
This evening I have obtined interesting results and I can now make basic predictions of when Audacity will crash as I alter the sample-rate / bit-depth. I have not been able to capture enough data to make significant predictions of crashes as I vary the audio cache memory depth but at least I have made a little progress.

I have captured data at sample rates of 24-96 with the audio cache depth set to 16MB and the crash time was identical to my previous data capture when the audio cache was set to 100MB. That got me thinking. The crash time was 38mins 49.25secs (this timing is as close as I can read from the screen capture image and more than good enough with what follows)

My next capture was at a sample rate of 16-44 and again the audio cache memory depth ws 16MB. If the crash is caused solely by an available RAM issue then the crash should occour at either (38mins 49.25secs) x (96/44.1) or (38mins 49.25secs) x (96/44.1) x (24/16) dependent on how Audacity writes to memory. Surprisingly, but as I suspected, Audacity did not crash at either of these times but at.........
patience, patience, all will be revealed...

I was fairly sure I could predict when the crash would occour if I set Audacity to record at 24-192 and my prediction seems to be correct.
Audacity will crash sometime after creating directory d06 but before creating directory d07. These temporary directories are empty prior to, and when, Audacity crashes i.e. Audacity creates these directories at fixed time intervals but does not write to them. The important point is the time interval for each directory creation is dependent on the setting of the size of the audio cache and the sample rate. Audacity will crash prior to the creastion of directory d07. The directory creation time interval does not seem to be dependent on the bit-depth but I have not performed enough captures to be certain of this last statement.

I think it is very interesting Audacity is creating these directories but is not writing to them but is writing somewhere. The amount of available system RAM, during an audio capture, decreases to a certain point and then continually oscillates i.e. available memory rises, falls rises etc. until Audacity crashes. Audacity appears to be using the Virtual memory that Windows has set aside. I have looked at the memory allocation table during a capture, with Audacity settings that will casue a crash, and I have seen Windows continuously increasing the ammount of Virtual memory allocated to Audacity until the inevitable crash. Audacity has not used this available memory even though the audio cache is set to 16MB.

I have also set Audacity to a 24-192 sample rate with a 600MB cache and there has not been a crash becasue the directories d00 etc. are being written to. the critical audio cache setting is somewhere between 100 & 600MB.

To progress I think we need to have independant confirmation of the above findings regarding the crash timing.

Please note:- Increasing the depth of the audio cache is not an acceptable (permanent) solution to the Audacity crash. This would just be a fudge. To solve this issue I feel we should try to progress this investigation as far as possible and then present our findings to the sw developers.
The sw developers will have the neccessary tools to be able to sort this issue. I can investigate how my XP system performs with particular attention to the above crash findings to see if this will give any further insight.

[Gale Andrews]

Hi Dennis,

Thanks for your efforts.

I do not know at the moment why Audacity writes empty directories in preparation for transferring the cache to disk on pressing Stop. However I can tell you that each dXX directory inside the eXX directory is written to until the d directory contains 256 .au files, then the next "d" directory in the sequence is populated with .au files.

Each .au file is 1 MB in size by default. Thus assuming Audacity was actually writing data, then the greater the sample rate and bit depth, the sooner each directory will be filled and the next one populated.

I think it is very interesting Audacity is creating these directories but is not writing to them but is writing somewhere. The amount of available system RAM, during an audio capture, decreases to a certain point and then continually oscillates i.e. available memory rises, falls rises etc. until Audacity crashes. Audacity appears to be using the Virtual memory that Windows has set aside. I have looked at the memory allocation table during a capture, with Audacity settings that will cause a crash, and I have seen Windows continuously increasing the amount of Virtual memory allocated to Audacity until the inevitable crash. Audacity has not used this available memory even though the audio cache is set to 16MB.

I have also set Audacity to a 24-192 sample rate with a 600MB cache and there has not been a crash becasue the directories d00 etc. are being written to. the critical audio cache setting is somewhere between 100 & 600MB.

1. Does the certain point before which Audacity uses RAM ever vary with its "Minimum Free Memory" setting? You seem to be saying not? If not, I think it may be an idea to try a 24x192 capture with minimum settings between 16 MB and 600 MB.

2. On what basis do you believe that when you reach this certain point, Audacity starts writing to disk, given it is not writing in the temp folder? The names of the .au files are random, but perhaps it would be an idea to seach for .au files by date created, to find out where they are.

3. Are you sure that after the certain point, Audacity is not writing to RAM as well as to disk, given Windows is continuing to allocate more and more virtual memory to Audacity? Might the available memory not be depleting further due to swapping to the page file?

4. If you set the minimum to 600 MB are you getting RAM used until system RAM falls below 600 MB, then disk writes - i.e. does the procedure work as intended if the minimum is high enough?

To progress I think we need to have independant confirmation of the above findings regarding the crash timing.

Please note:- Increasing the depth of the audio cache is not an acceptable (permanent) solution to the Audacity crash. This would just be a fudge. To solve this issue I feel we should try to progress this investigation as far as possible and then present our findings to the sw developers.
The sw developers will have the neccessary tools to be able to sort this issue. I can investigate how my XP system performs with particular attention to the above crash findings to see if this will give any further insight.

It's quite difficult to fix anything that the developers cannot replicate on their own machines. If the developers cannot reproduce it, we are looking at giving you a debug build of Audacity, then you installing Visual Studio and examining call stacks (even if you wanted to do that)




Gale

[waxcylinder]

At the moment, reset is done by editing the audacity.cfg settings file

Or during install of v2.0.1 if the box is ticked!

Indeed, but that's a clumsy way for more experienced users in my view.

It's a clumsy, non-intuitive, way for anybody IMO - and that's why Koz keeps asking for an easy cfg reset - and why we put this proposal up in the Wiki: http://wiki.audacityteam.org/wiki/Propo ... _cfg_Reset

Peter.