Audacity Recording Freeze at 38m 47.5s: Win7

[otwo_pipes]

Gale wrote:

For RAM usage, I was just looking in Windows Task Manager (Performance tab) at the "Available" figure under "Physical Memory (MB)".

Can I suggest you use Microsoft's 'Process Monitor' for RAM usage. In the listing you can select Audacity and then right click for 'Properties' and see the RAM Audacity, or any other process, is using; very neat.

The same way you would force quit any program, using Windows Task Manager.

Okay, terminology differences. 'Quit' to me is using the executable to end the process i.e. I would use 'quit' in the same context as 'close' whereas I would use 'kill' to describe using Task Manager. No harm in asking and thanks for the explanation.

I would still like to know if you had pressed Stop when you produced that image (which would have copied the ,au files in the folders from RAM to disk) or Pause (which would not have copied to disk).

I cannot answer this question because I have no notes and I am not going to guess but let me ask, have you answered your own question..... you wrote "if you had pressed Stop when you produced that image (which would have copied the ,au files in the folders from RAM to disk) or Pause (which would not have copied to disk)." The image is on disk and the folders have .au files so maybe, from your reasoning above, I pressed stop. However, I have to question your reasoning. My understanding is the .au files are written to the temp directory When Audacity thinks the system has run out of free memory according to the RAM setting in the audio cache. If this is the case surely the status of pause or stop is irrelevant other than stop will write the contents of RAM to HD. If I ever see this scenario again I will document and let you guys know exactly what I did.

There are three major problems in that image.
* Where are the d00 through d05 folders? DId you delete them? Even if you had only pressed Pause, Audacity should still have created empty e00/d00 through d05 folders on disk, ready to populate them with .au files on Stop.

If I modify, delete or in any way fiddle with an image there is little point in taking the snapshot or informing you guys. That would be a complete waste of time. I may make mistakes but I will not deliberately mislead. I realise you have to ask the question because, like you, I wonder where the directories are and I would also ask the same question to ensure we were talking about the same thing, hence my snapshot. (short answer next time )

* Where is the d0c folder that should follow d0b? It seems it wasn't written.

Correct: It has not been created.

* The big one: d06 (which should have been written before d07) being written at the same time as d0e, and what is more, at 15:34 instead of 15:37 which would have been expected from the previous folders. That is, unless Audacity does this when it starts writing to disk when system RAM falls below the Audacity minimum. I'll test, but I don't think so.

Yes, I do not understand either and remember from one of my latest posts, "The 2nd crash had 20 .au files in the d00 directory: all files were 780kB apart from 2 files which were 318kB. (Why are there two files of size 318kB being written when Audacity crashes? I could understand all files being 780kB and one file was a different size but two files of 318kB, seems (only a little) odd to me.)" I do not think Audacity is writing directories in the manner you are anticipating. As a simple test, and especially as you have lots of RAM, record for 30-60 minutes at 24/96 with audio cache enabled and set to 16MB. Open Win Explorer. Press stop and monitor how the .au files are being written by Audacity. I do not think I see each directory populated in order i.e. many directories are being written to until there are 255 files in a directory. To see this you need to have enough data in memory so that HD writes takes long enough for you to probe many directories.

Do I assume you crashed at or after 15:34?

otwo_pipes wrote (In the posting with the directory snapshot): The screen shot is from an LP rip without a crash. The folder information is from a good run and not a crash.

And where Dennis said elsewhere
but NOTHING in directory .d01
that would only be correct if you had pressed Pause rather than Stop at that time AND d00 had actually been writing to disk instead of RAM, which would be very odd in itself.

Please remember I am seeing directories being created almost from the moment recording commences even though there may be 1.5GB or RAM available.

Now, let me repeat myself so there is no misunderstanding, "I did not make an issue of it last night but the 24-192 capture had files written in directories .d00, .d02 etc. but NOTHING in directory .d01 and these Audacity settings did not cause a crash. I do not know if this is relevant but everything is worth mentioning."

but to continue with today's results... how about this one if you like oddities.
My XP system crashed today, which in itself is very good news for my testing. The crash timeline was 24:28, see the screenshot. Directories created at/before the time of crash are d00 - d08. I only ever see d00 - d06 created when my Win7 system crashes. Maybe this is beginning to point to a memory issue. However, I think the real talking point will be that directories d00 - d05 are empty directory d06 has 130 .au files, directory d07 has 250 .au files & directory d08 has 57 .au files. Hardly an ordered write of 255 files per directory. All .au files are 781kB in size.

Can you take a look at my post above viewtopic.php?p=185462#p185462 and offer any comments?

I hope I have answered this and all other points now; if not, please let me know.

and digressing to my bug-bear:-
Does anyone know a simple and guaranteed method of un-stalling a stalled recording? This really is a pain as sometimes a simple re-start of Audacity works, sometimes deleting the contents of the temp directory works and SOMETIMES it is repeated (3) re-boots, the later being a right pain.

[steve]

all files were 780kB apart from 2 files which were 318kB. (Why are there two files of size 318kB being written

If you are working with stereo tracks, Audacity uses separate data blocks for left and right channels. Assuming that both left and right are the same length and not an exact number of blocks then it is to be expected that there will be two, equal sized blocks that are smaller than the other blocks.

Now, let me repeat myself so there is no misunderstanding, "I did not make an issue of it last night but the 24-192 capture had files written in directories .d00, .d02 etc. but NOTHING in directory .d01 and these Audacity settings did not cause a crash.

I like crystal clarity
When you start recording something, do you always start a new project, or do you sometimes undo or delete the audio of one project and start another recording in the same project? (just wondering as this could have some implications as to why some of the folders are out of order/missing).

Does anyone know a simple and guaranteed method of un-stalling a stalled recording?

I'm on a different system to you so your mileage may vary, but if I get a bad crash (not so uncommon because I'm always messing around trying to break things), to get a "clean fresh start" I check in the system processes that Audacity is completely closed (if not, kill it), then restart Audacity (which usually brings up a message about the poor little orphans), then close Audacity (which deletes any spurious temp data) and restart Audacity again.

[otwo_pipes]

Steve wrote:

If you are working with stereo tracks, Audacity uses separate data blocks for left and right channels. Assuming that both left and right are the same length and not an exact number of blocks then it is to be expected that there will be two, equal sized blocks that are smaller than the other blocks.

Thanks, so god-damn obvious.

I like crystal clarity

You comment produced loud guffaws

When you start recording something, do you always start a new project, or do you sometimes undo or delete the audio of one project and start another recording in the same project? (just wondering as this could have some implications as to why some of the folders are out of order/missing).

Simple question, unfortunately the answer is complicated.
When I am ripping LP's audio cache is disabled. I start Audacity, record one side, pause, record second side, stop, export in 24/96, undo record and repeat the process until my days rip is complete.
When I am testing I always re-boot after a record, irrelevant of whether or not there was a crash. I think/thought this was the only way for me to ensure I was working on a level playing field and not seeing artefacts of previous crashes however, your answer to my stall question confirms what I thought I had seen. After a crash and a re-boot I start Audacity but you have said I must close Audacity and re-start to remove the artefacts. What you have told me is I am not, after all, testing on the the level playing field as I assumed. Interesting. In future I will monitor the temp directory more closely.

[otwo_pipes]

otwo_pipes wrote:

When I am testing I always re-boot after a record, irrelevant of whether or not there was a crash.

and it should have read:-
When I am testing, audio cache is enabled, and I always re-boot after a record, irrelevant of whether or not there was a crash.

[Gale Andrews]

Gale wrote:

For RAM usage, I was just looking in Windows Task Manager (Performance tab) at the "Available" figure under "Physical Memory (MB)".

Can I suggest you use Microsoft's 'Process Monitor' for RAM usage. In the listing you can select Audacity and then right click for 'Properties' and see the RAM Audacity, or any other process, is using; very neat.

I don't see that - where are you looking exactly? All I was intending to do was verify the 6 MB per minute extra RAM usage (compared to disk writes) that Task Manager seems to show. I will look at that some time.

The same way you would force quit any program, using Windows Task Manager.

Okay, terminology differences. 'Quit' to me is using the executable to end the process i.e. I would use 'quit' in the same context as 'close' whereas I would use 'kill' to describe using Task Manager.

That's why I said "force quit". It's analogous to "kill".

I have to question your reasoning. My understanding is the .au files are written to the temp directory When Audacity thinks the system has run out of free memory according to the RAM setting in the audio cache. If this is the case surely the status of pause or stop is irrelevant other than stop will write the contents of RAM to HD. If I ever see this scenario again I will document and let you guys know exactly what I did.

That is the case IF Audacity is doing what it should, which clearly it doesn't. As you know, Audacity should when recording to RAM create empty e00/d00 folders ready to populate when Stop is pressed or system RAM falls below the Audacity minimum. Therefore it seems pertinent to ask if you knew what happened to those six initial folders. I appreciate unless you document everything as you go along, you may not be able to answer a question about "missing folders".

Do I assume you crashed at or after 15:34?

otwo_pipes wrote (In the posting with the directory snapshot): The screen shot is from an LP rip without a crash. The folder information is from a good run and not a crash.

Well that is even more odd.

I have today made four tests (24 x 192, 1900 MB Audacity minimum with 3000 MB available). One test recording froze at the point system RAM fell to 1900 MB with the same symptoms as your first post. I tried File > Exit then Cancel, but that did not ungrey File > Export or other menus normally greyed out when recording. I force quit in Task Manager, but as nothing was written to disk, no recovery was possible.

In two of the other tests, Audacity correctly recorded to RAM where the system RAM was above the Audacity minimum, then when system RAM fell below the minimum, Audacity wrote to disk all the .au files it had in the folder it was allocating at the time (so for example d03 while d00, d01 and d02 remained empty). Even though that allocated folder had not reached 256 files, it then started writing a new folder. On pressing Stop, the folders for the data before the disk write started were correctly populated with 256 files, and the recording was correct.

The other test was like the two in the paragraph above, except that Audacity wrote the first eight .au files to disk.

Now, let me repeat myself so there is no misunderstanding, "I did not make an issue of it last night but the 24-192 capture had files written in directories .d00, .d02 etc. but NOTHING in directory .d01 aand these Audacity settings did not cause a crash. I do not know if this is relevant but everything is worth mentioning."

It would appear to be wrong even if it did not crash, if you had started from a clean temp directory (File > Close). Did you actually have all the intended recording?

Note that if you want to retain temp data from a project while Audacity remains open, choose File > New to start a new temp folder for that project.

My XP system crashed today, which in itself is very good news for my testing. The crash timeline was 24:28, see the screenshot. Directories created at/before the time of crash are d00 - d08... However, I think the real talking point will be that directories d00 - d05 are empty directory d06 has 130 .au files, directory d07 has 250 .au files & directory d08 has 57 .au files. Hardly an ordered write of 255 files per directory. All .au files are 781kB in size.

That would seem expected if you crashed. Audacity never got the chance to transfer the .au files from RAM to disk. But we have seen more bizarre cases where the folders are not written at all.


Gale

[Gale Andrews]

Just to add, the Audio Cache Preference has now been removed for 2.0.2, though not any of the audio IO code it uses.


Gale

[otwo_pipes]

Gale/Steve Please look at a new posting I have made "LP Rip with Distortion at the end of side one". This is very important to me and is so serious I may have to stop using Audacity unless the problem can be resolved quickly. The current problem and the stalled recording can be lived with but the distortion is just too serious.

This morning, Wednesday, I started my Win7 system from cold and I was presented with a stalled record i.e blinking cursor when I selected the 'Record' function. The temp directory was clean, there were no projects left from the previous days (Tuesdays) rip and there had been no crashes during the Tuesday recording session apart from the very first rip when I had started the system with crash testing settings in preferences. An Audacity re-start cured this stall. Okay, to continue with the main thread:-

I am revisiting these posts and intend to write a summary. I think this is necessary especially as I have just seen an error in a partial answer of mine to one of Steve's questions re:-

To answer Steve's questions:-
For clarification, are you saying that:
The problem occurs intermittently on both your Windows 7 system and your XP system
The problem was not intermittent; quite repeatable and at (virtually) the same time points
The freeze always occurs at 39:47.5

my statement is correct apart from the fact I should have said it only applied to the Win7 systems. I forgot to add the sentence, "I have never seen a crash on my XP system." this was correct at the time of posting. Jumping to the present time.....

It seems progress is being made at last. I can now confirm why previously I did not see any crash on the XP system and suddenly I do. It is all to do with the audio cache settings. I had changed the Audacity default from 16MB to 100MB on both the XP and the Win7 systems. Put simply, an audio cache of 100MB does not crash on XP and does crash on Win7, both systems have 2GB RAM but maybe Win7 uses more RAM than my XP system. I have not had time to undertake any testing today to look at the memory usage of my XP and Win7 systems. If I set the Audacity audio cache to 16MB on the XP system and record at 24/192 then I see consistent crashes at a record time or around 24 minutes. It is not strictly true to say an audio cache setting of 100MB does not crash the XP system because I had one crash on Tuesday evening when I left the record run for about 2.5 hours. My previous XP tests had been around the hour mark with one test of 1.5 hours. It seems the crashes are related to the audio cache setting size, maybe I ought to do more 'Time to Crash' testing on the Win7 system to try confirm this.

@Gale: For RAM usage, I was just looking in Windows Task Manager (Performance tab) at the "Available" figure under "Physical Memory (MB)".
@otwo_pipes: Can I suggest you use Microsoft's 'Process Monitor' for RAM usage. In the listing you can select Audacity and then right click for 'Properties' and see the RAM Audacity, or any other process, is using; very neat.
@Gale: I don't see that - where are you looking exactly?

Download Process Monitor from http://technet.microsoft.com/en-us/sysi ... 96645.aspx
Extract all files and run the application, which does not install
Start Process Monitor when Audacity is running
Right Click on the Audacity Icon, select properties and the performance tab in the pop-up window
If you decide to close Process Monitor to re-start, PM has to be run from the directory where it is stored after unzipping.

@otwo_pipes:I have to question your reasoning. My understanding is the .au files are written to the temp directory When Audacity thinks the system has run out of free memory according to the RAM setting in the audio cache. If this is the case surely the status of pause or stop is irrelevant other than stop will write the contents of RAM to HD. If I ever see this scenario again I will document and let you guys know exactly what I did.
@Gale: That is the case IF Audacity is doing what it should, which clearly it doesn't. As you know, Audacity should when recording to RAM create empty e00/d00 folders ready to populate when Stop is pressed or system RAM falls below the Audacity minimum. Therefore it seems pertinent to ask if you knew what happened to those six initial folders. I appreciate unless you document everything as you go along, you may not be able to answer a question about "missing folders".

What I can say is the missing folders were never created because I did not delete them and I cannot (easily) frig the Windows Explorer snapshot. I have no idea why they were not created but Steve gave a pointer in a previous post of his because I had not been using close but I did reboot and this appears not to have been enough to reset Audacity. I have to start Audacity then close and re-start Audacity to finish up with a clean system. I was not doing this so maybe the procedure I was using, which left previous projects in the temp directory, could explain the missing folders.

@Gale: I have today made four tests (24 x 192, 1900 MB Audacity minimum with 3000 MB available). One test recording froze at the point system RAM fell to 1900 MB with the same symptoms as your first post. I tried File > Exit then Cancel, but that did not ungrey File > Export or other menus normally greyed out when recording. I force quit in Task Manager, but as nothing was written to disk, no recovery was possible.

Brilliant because now you are also able to generate a crash which should be repeatable.
Correct re having to force quit Audacity: Though when you re-start Audacity it does ask if you want to recover and if you agree to recover then I think Audacity crashes again.

In two of the other tests, Audacity correctly recorded to RAM where the system RAM was above the Audacity minimum, then when system RAM fell below the minimum, Audacity wrote to disk all the .au files it had in the folder it was allocating at the time (so for example d03 while d00, d01 and d02 remained empty). Even though that allocated folder had not reached 256 files, it then started writing a new folder. On pressing Stop, the folders for the data before the disk write started were correctly populated with 256 files, and the recording was correct.

Absolutely, and I have only realised what is happening because of this description of yours, see my next paragraph

@Gale: The other test was like the two in the paragraph above, except that Audacity wrote the first eight .au files to disk.
@otwo_pipes:Now, let me repeat myself so there is no misunderstanding, "I did not make an issue of it last night but the 24-192 capture had files written in directories .d00, .d02 etc. but NOTHING in directory .d01 and these Audacity settings did not cause a crash. I do not know if this is relevant but everything is worth mentioning."
@Gale: It would appear to be wrong even if it did not crash, if you had started from a clean temp directory (File > Close).

but I did not start from a clean (File >Close) but a 'dirty' re-booted system. Maybe this is not a good idea for punters. A re-boot should leave a punters home system clean and not require further actions to make a system clean (developer systems are unique). Lets define this as, "Audacity produces a dirty crash." Only food for thought

Let me summarise, earlier in this post you said, "As you know, Audacity should when recording to RAM create empty e00/d00 folders ready to populate when Stop is pressed or system RAM falls below the Audacity minimum." If I am correct I can explain some of the folder structures we see at/after a crash. I have seen on many occasions Audacity writing directories d00, d01 etc. and the time interval between writing these directories is constant for a given sample rate/bit depth. This implies Audacity is continuously calculating how many directories are required to hold the current RAM contents i.e. at the start of recording, irrelevant of the length of the recording or sample rate Audacity will require at least one data directory which is d00. Given time, sample rate, file size and number of files per directory I believe Audacity creates the next directory when, or a defined time before (and the before could be important), the latest created empty directory, would be full if the contents of RAM were written i.e if stop was pressed. I also suspect audacity actually starts writing to disc not with the current contents of RAM, after the audio cache limit is reached, but with the next captured data just as if the audio cache had not been enabled and the record start time was now T-zero. I think this is what you have said but I missed it on the 1st, 2nd 3rd readings and have only just realised. I added the previous sentence because I do not want to re-write this paragraph. This would explain the empty directories of d00 - d05 in a previous crash I described. It does not fully explain the partially filled directories d06, d07 and d08 but does explain the empty d00 - d05 directories.

What conclusions can we draw. Not a lot other than we know (I think) Audacity is doing calculations during a recording and writing to hard disk. The time of these hard disc writes are dependant on audio cache setting and sample rate etc. Why does Audacity crash when the audio cache is enabled and not when it is disabled. I cannot answer but this morning I was beginning to think the hard disk writes are causing the crash. Quite an interesting conclusion as I have made another posting with a question regarding distorted audio which I think is due to erroneous hard disc writes on the last rip I made today.

@Gale: Did you actually have all the intended recording?

This was a test recording and I have not been listening to test recordings so sorry but I cannot answer this question.

@Gale: Note that if you want to retain temp data from a project while Audacity remains open, choose File > New to start a new temp folder for that project.

Thanks for the info.

@otwo_pipes: My XP system crashed today, which in itself is very good news for my testing. The crash time-line was 24:28, see the screen-shot. Directories created at/before the time of crash are d00 - d08... However, I think the real talking point will be that directories d00 - d05 are empty directory d06 has 130 .au files, directory d07 has 250 .au files & directory d08 has 57 .au files. Hardly an ordered write of 255 files per directory. All .au files are 781kB in size.
@Gale: That would seem expected if you crashed. Audacity never got the chance to transfer the .au files from RAM to disk. But we have seen more bizarre cases where the folders are not written at all.

As I have said above, I think I can explain why d00 - d05 are empty at the time of crash but not why d06 and d07 is not full. I could explain d08 being partially full but not 3 directories partially populated. I do not think it is adequate to say you would expect this if Audacity has crashed. Can you please explain why d06 does not contain 255 files. Steve explained very well why we have two files of identical size at time of crash, it is called stereo. Is there such a simple explanation for the number of files in d06 - d08 of my screen-shot?

I do not see why your bizarre case has no directories created. That is most odd. My reasoning says a d00 directory has to be created in a project when recording starts; as you said, bizarre.

[Gale Andrews]

Can I suggest you use Microsoft's 'Process Monitor' for RAM usage. In the listing you can select Audacity and then right click for 'Properties' and see the RAM Audacity, or any other process, is using; very neat.
@Gale: I don't see that - where are you looking exactly?

Download Process Monitor from http://technet.microsoft.com/en-us/sysi ... 96645.aspx
Extract all files and run the application, which does not install
Start Process Monitor when Audacity is running
Right Click on the Audacity Icon, select properties and the performance tab in the pop-up window

I only see the "Event", "Process" and "Stack" tab as per the image on the product page




Gale

[Gale Andrews]

Dennis, Thanks for the extra information about crashes on XP at 16 MB Minimum.

Brilliant because now you are also able to generate a crash which should be repeatable.

Certainly not repeatable, in fact that was and sill is the only crash I have ever had with Audio Cache. After that, Audacity started writing to disk correctly when system RAM fell below 1900 MB.

I did not start from a clean (File >Close) but a 'dirty' re-booted system. Maybe this is not a good idea for punters. A re-boot should leave a punters home system clean and not require further actions to make a system clean

Don't agree. We want to have data to recover from if the system crashes.

I believe Audacity creates the next directory when, or a defined time before (and the before could be important), the latest created empty directory, would be full if the contents of RAM were written i.e if stop was pressed.

Yes.

Can you please explain why d06 does not contain 255 files.

I think (from examination of the creation time of the previous folders) that's because Audacity started writing to disk before it had completed writing to RAM all the files intended for the d06 folder. So at that point it started d07 (same behaviour as in my tests). This may actually be what is intended, but it will be noted anyway for if and when we look at resurrecting this feature.


Gale

[Gale Andrews]

The only new discoveries that I have made are:
[*] An apparently "out of sequence" data folder structure can be created by discarding Undo History.

Can you explain that one a bit more, please Steve? This sounds as if it could be relevant generally, not just to Audio Cache recording.


Gale