@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
Dennis, thanks for the tests.
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.
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
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
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
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.
@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.
That’s another cunning reason why the FAQ is included as part of the Manual.
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
@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.
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.
-
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.
-
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.
-
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?
-
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?
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
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/Proposal_Easy_cfg_Reset 
Peter.
@Gale
Thanks for your efforts.
No problems, it is my pleasure. More to the point, it is good to keep my hand in now I am retired
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.
This is NOT what I have seen. I have not counted these files as I did not think it was an issue though I think the number of .au files in each directory varies and last night I think I was seeing as low as 5-10 files (I think) but again, it was late and I was not looking too closely however you may find my latest screen shot interesting as this shows there are not always 256 files per directory. The screen shot is from an LP rip without a crash. The main picture shows the timing of each directory ‘date modified’ and the small pictures show the contents of each directory and date created. Look very carefully at these time and dates. Is there a clue here?
I have had a bad day ripping LP’s and Audacity has not been well behaved, no crash but a right pain. After many ‘fixes’ to Audacity I now have your 256 files per directory (and one run that should have crashed with the Audacity settings but it did not). Don’t you just love systems. At least I can prove what I have said re there not being 256 files per directory otherwise you may have started to dismiss my input.
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.
Each .au file is 1 MB in size by default.
This is not what I seeing, my files are 780MB and not, as you say, 1MB. |I don’t know the relevance of this but I thought it was worth mentioning.
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.
The greater the sample rate the quicker the directories are written; this is agreed and explains the variation in time to crash being sample rate dependent. At the moment I do NOT agree that bit depth alters the rate of directory writes but please remember, my results of last night are based on a sample test of one. This is not statistically significant so I am looking at this now.
_otwo_pipes wrote: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.
- 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._
The ‘certain point’ varies dependant on the setting of the audio cache depth.
If the audio cache is set to 16MB then system RAM is used until only around 95-100MB of the system RAM is free then the oscillations start followed by a crash some time later. If the audio cache is set to 100MB then RAM is used until around 300MB of RAM is free then the oscillations start followed by a crash some time later.
The some time later is dependant on the time between each make directory. This time is dependant on the sample rate and may or may not be dependant on the number of bits in the sample. I know the time could be dependant on the number of bits in the sample but so far I have not seen this. The crash occurs after the make directory d06 and before make directory d07, about one third to half of the make directory time interval after directory d06 is made. As I said, this time is definitely dependant on the sample rate and may be dependant on the bit rate.
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 search for .au files by date created, to find out where they are.
The reason, for my assumption, is very simple… When capturing data at ‘Rate’ bytes per second the storage required is the ‘Rate’ multiplied by Time (in seconds) bytes. When this number exceeds the amount of RAM used, since the start of recording, Audacity must be writing somewhere and the VRAM, allocated to Audacity by Windows is continuously increasing from the start of capture. As I said, I now assume Audacity is writing to the Virtual Windows RAM. Windows could of course be allocating VRAM to Audacity and Audacity discarding the captured data. I have not looked for the .au files, I just assumed. Sorry for this assumption and I like your question.
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?
I suspect, and always have, that Audacity is writing to both RAM and VRAM from the START of audio capture when audio cache is enabled. I know this is not how it is intended to operate but this seems the only explanation for what I am seeing. Remember, I do not have a development tool-set, only the Windows Task Manager tools. Let’s assume Audacity settings are such they will cause a crash. There are numerous choices of settings but the results are always the same aka:-
The system RAM is continually decreasing to the oscillatory value, as explained before, AND the VRAM allocated to Audacity by Windows, or whatever, is continually increasing. These actions occur from the start of recording until the crash. Maybe the VRAM point is very significant. Let me ask the question: If Audacity/Windows has over 1GB (and maybe as much as 1.5GB) of system RAM available why should Windows/Audacity increment the VRAM allocated to Audacity from the start of the audio capture? This behaviour does not make any sense to me. Let me run it past you again:-
The system RAM available to Windows is continually decreasing from the start of recording until the critical available memory, which is dependant on the audio RAM cache depth:-
If the cache is 16MB the system RAM decreases to about 100MB
If the cache is 100MB the system RAM decreases to about 300MB
then the available system RAM oscillates around this figure whilst the VRAM allocated to Audacity has continued to increase from the start of the audio capture
I can only assume Audacity is writing to RAM and VRAM but cannot be certain because projects are never recoverable after a crash.
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?
I do not think so but this one is difficult to answer with the tools I have available. I think the RAM is used until somewhere in excess of 1GB is in use, but never as much as 1.4GB (I have 2GB RAM) and then the oscillation starts. The oscillations are from around 1GB to 1.3GB; it was late and I am hazy on this point. What I am certain of is the correlation between available RAM and the cache setting but it is only a correlation; the two are NEVER equal i.e. 16MB cache correlates to 100MB system RAM and 100MB cache correlates to 300MB system RAM. I think 600MB cache correlates to 1GB system RAM but I am not sure on that one. It was gone midnight when I finished capturing audio 
otwo_pipes wrote:To progress I think we need to have independent confirmation of the above findings regarding the crash timing.
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)
I have no problem trying to help, other than time. My priority is ripping my Vinyl collection to HD. I have around 800-1000 albums and it takes about one hour per album. This equates to… a very long time. I am going to live in Thailand from October for 5-10 years. I will travel SE Asia on my Valkyrie motorbike using Thailand as a base… now I am digressing Re the de-bug build and VS; here I may be out of my depth and require hand holding. I am not a softie and have little experience of software de-bug as my background is hardware design. I finished my career consulting for the likes of Nokia, TI and Sony Ericsson. I have interfaced with, and assisted softies with hw/sw de-bug, a great deal but as to hands on… anyhow, I am game if someone can assist when I have problems.
Also, it is quite difficult trying to de-bug at a distance. I need to be accurate and not cause further confusion and to this end this update has taken many hours to write. I was also ripping LP and trying to sort other Audacity problems but that is another story. I have to read the FAQ first Gale, from my point of view It may be more efficient to Skype me if you are interested, I am dennis2pipes. (The 2pipes comes from smoking a pipe and always carrying two hence…) If you see me on-line in Skype then you can call but please not this evening. I am too tired and testing some ideas with this Audacity problem.
@Gale: 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.
@2pipes: At the moment I do NOT agree that bit depth alters the rate of directory writes but please remember, my results of last night are based on a sample test of one. This is not statistically significant so I am looking at this now.
You are absolutely correct as the memory requirement is dependant on sample rate and bit depth. What is interesting the crash ocours at 19:19 when captured at 24/192 and 38:38 when captured at 16/192. This implies Audacity is using two words for storage when the bit depth is 24.
@Gale: 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 search for .au files by date created, to find out where they are.
@2pipes: The reason, for my assumption, is very simple… When capturing data at ‘Rate’ bytes per second the storage required is the ‘Rate’ multiplied by Time (in seconds) bytes. When this number exceeds the amount of RAM used, since the start of recording, Audacity must be writing somewhere and the VRAM, allocated to Audacity by Windows is continuously increasing from the start of capture. As I said, I now assume Audacity is writing to the Virtual Windows RAM. Windows could of course be allocating VRAM to Audacity and Audacity discarding the captured data. I have not looked for the .au files, I just assumed. Sorry for this assumption and I like your question.
Section 2 was all based on a wrong initial calculation. One minute of capture at 24/96 uses 96k words per second or 96460 bytes per minute i.e about 23MB per minute. Re-visiting and searching the hard drive has shown there are NO writes to VRAM during capture and prior to the crash i.e. there are no .au files on the hard drive after a crash. Sorry to have mis-lead.
@Gale: 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?
@2pipes: I suspect, and always have, that Audacity is writing to both RAM and VRAM from the START of audio capture when audio cache is enabled.
The above has now been proven to be wrong. Apologies again.
@2pipes: The system RAM is continually decreasing to the oscillatory value, as explained before, AND the VRAM allocated to Audacity by Windows, or whatever, is continually increasing. These actions occur from the start of recording until the crash. Maybe the VRAM point is very significant. Let me ask the question: If Audacity/Windows has over 1GB (and maybe as much as 1.5GB) of system RAM available why should Windows/Audacity increment the VRAM allocated to Audacity from the start of the audio capture? This behaviour does not make any sense to me. Let me run it past you again:-
The system RAM available to Windows is continually decreasing from the start of recording until the critical available memory, which is dependant on the audio RAM cache depth:-
If the cache is 16MB the system RAM decreases to about 100MB
If the cache is 100MB the system RAM decreases to about 300MB
then the available system RAM oscillates around this figure whilst the VRAM allocated to Audacity has continued to increase from the start of the audio capture.
The above still stands. I have seen some variation but I do not think the variation is significant.
Given the previous erroneous assumptions I made I am now at a loss to explain the oscillatory nature and why the continually increasing VRAM from the start of audio capture when the cache is enabled? Not much is making sense at the moment. Maybe it it time for me reply to any posting regarding these points and then make various detailed measurements until I have some sound ideas…
Apart from the one run at 16/192 testing has been at 24/192 in order to reduce the time to crash.
Of two crashes I have seen, files have been written in .d0; 5 on one crash and 14 on the second. All other crashes I have looked at have no files written to the dxx directories.
I have run a capture at 24/192 for 1.5 hours with audio cache off. I have a huge temp directory, 5.6GB & 7.5k files. The reason for such a large collection of data was to look at the VRAM which was 36MB at the end of the collection which is, give or take, the size at the start of the run.
Gale: I think the audio capture of 38mins 47secs requires about 890MB of RAM (96k samples x 4bytes x 38.75 minutes x 60 seconds) Please confirm my calculation. The reason I ask is the crashes seem to occur at the changeover from RAM to HD writes however this does not explain why there is not a crash when the cache is set to 600MB. Any thoughts?
Could this be to do with Windows memory management? (Windows moving RAM to page file when available memory gets too low).
Is that above the threshold for Windows swapping RAM to disk?
Hi Dennis
Thanks for your efforts.
So as I understand it, you don’t crash with an Audacity setting of 600 MB, but you crash with a setting below that. System RAM appears to be no longer used at a point well above and roughly proportional to the Audacity setting. The critical point where RAM stops being used is accompanied by the start of reductions and replenishments of system RAM which are not observed prior to that point. On a couple of occasions only, .au files were written to the temp folder. Soon after this critical point is reached, Audacity crashes.
The onset of reductions and replenishments varies with the bit depth and sample rate of the recording and the Audacity setting, so this is not Windows swapping to the page file when system RAM falls below the Windows threshold point. Fair summary?
Even after you pressed the Stop button, there were no .au files in d01?
Also I note in your last image above of the folder structure, there was no d0c folder? And had it already populated d00 - d99?
I think the formula is:
size in MB = sample rate in kHz * number of channels * (bits per sample /8) * time in seconds / 1024
So as you can see that gets us to roughly 33.75 MB per minute assuming stereo.
I agree the block file size for 24-bit (irrespective of Audio Cache being on or not) is 780 kb. I am not sure why that is at the moment. The block file size for 32-bit and 16-bit is 1 MB.
38.75 minutes of 24-bit 96000 Hz stereo is about 1.3 GB of file usage. Isn’t that about the amount of RAM you said you had to spare at the time you started to record?
Gale
otwo_pipes wrote:One minute of capture at 24/96 uses 96k words per second or 96460 bytes per minute i.e about 23MB per minute.
Okay, thank you for the correction as I forgot the the 2 channels for stereo, and other points, when I wrote this but my spreadsheet was correct
betwixt us we may get there…
@Gale copied an equation from documentation:
I think the formula is:
Code: Select all
size in MB = sample rate in kHz * number of channels * (bits per sample /8) * time in seconds / 1024
here follows the short (honestly, this IS the short) answer to an important point. I will answer the other points later:-
I think we have a classic case of the numerical units provided in the equation above not being entirely correct. I know exactly what is meant but I still think the numerical units are not quite correct. We all know k * k = M (capitals as per Gales equation) however Gales equation uses MB on the left and kHz (meaning 1000 in frequency) AND 1024 (meaning k in software terms) on the right. The 1024 refers to 1k byte of RAM. This leads me to think we have a classic example whereby k * k does not equal M. In my mind, this concept is simple but has proven extremely difficult for me to explain in writing so please bear with me whilst I try to explain.
Can we assume, for the point I am trying to make here ,we have an 8 bit system i.e each sample is 8 bits (keep it simple, 8 bits = 1 byte).
Let me start by asking a hypothetical question:-
In a system with 1 MB of RAM and a sample rate of 1 kHz and only 1 channel (I did say lets keep it simple) how long can we write to RAM?
The answer to this question is hopefully, also simple:-
1 MB(yte) of RAM at a sample rate of 1 kHz and 1 byte per sample has to be 1e6/1e3 = 1e3 or 1k seconds: no problem; or… is it a problem?
Let me ask another (simple) question, what is the magnitude of 1k (in this context)? Is it 1000 as in kHz or…to continue…
re-arranging the equation quoted by Gale we have:-
time in seconds = (size in MB) / (sample rate in kHz * number of channels * {bits per sample /8} * 1024)
or simplifying as we have a sample width of 1 byte and only 1 channel:-
time in seconds = (size in MB) / (sample rate in kHz * 1024)
putting the same numbers from my hypothetical question above onto this equation we have:-
1e6(MB)/1e3(kHz)/1024 = 1,000,000 (from MB)/ 1,000 (from kHz) / 1024 = 0.9765625 k seconds
or should that be
1,048,576 (from MB) / 1000 (from kHz) / 1024 = 1.024 k seconds
or even
1,048,576 (from MB) / 1024 (from kHz) / 1024 = 1 k seconds
as I asked, what is the magnitude of 1k?
I think it is glaringly obvious that something is very wrong here. We cannot have one equation with three different answers depending on how you define M or K.
If you have any doubt to my reasoning or logic please look at the following URL:-
http://en.wikipedia.org/wiki/Megabyte
here, the table at the top right actually states 1k = 1000 in decimal and 1024 in binary and I quote, “The megabyte is a multiple of the unit byte for digital information storage or transmission with three different values depending on context.” What, I hear you ask, three different values depending on context please, give me strength and one wonders why we have errors in system design…
I know, I have been there before and even seen 32 bits systems not work because the LSB was defined as… I will leave the reader to ponder on that one
so, let me ask a rhetorical question… when the audio cache is set to 16MB in Audacity, how big, in decimal, is 16MB?
I know how big 16MB is; you know how big 16MB is but seriously are all the Audacity functions, maybe written by different people, referring to the same size for 16MB and are you sure you are using 16MB in the same ‘context’ (re the URL) as Windows/Apple and Linux? Is that an interesting question or is that an interesting question? Answer YES because you cannot have MB = kHz (samples/second) * bytes * time / 1024
1MB of memory = 1024 bytes * 1024 bytes and not 1000 * 1024 bytes…
boy, was that difficult to write…
I hope the readers understand the point I have laboured here.
@Steve: I owe you an answer but I am not sure I have the knowledge to answer your question re Windows Memory Management.
I now have another tool at my disposal, Process Manager from Microsoft, so I may be able to answer your question later.
Hi Dennis
I am not a mathematician, but the point of the /1024 is to convert kb into MB for ease of working with the resultant figure.
If you want another much more complex formula which still gives a very similar result, try http://tinyurl.com/cb7tc3k .
However you play with formulas, you can concur I think that 24x96 recording requires some 33 MB per minute of RAM or disk space just by looking at one minute of recording (with audio cache disabled) in the Audacity _data folder. Hence 38.75 minutes requires some 1.3 GB of RAM or disk space.
If I understood you to say that you usually have 1.3 GB RAM to spare before starting recording, and given your first image shows 300 MB RAM free when you crashed, then presumably some 300 MB memory had been swapped to page file by the time of the crash.
Was my summary at the top of https://forum.audacityteam.org/t/audacity-recording-freeze-at-38m-47-5s-win7/25136/34 correct? And, next question below that, you are sure the folder d01 had no .au files in it even after stopping recording?
Gale
@otwo_pipes,
The formula given by Gale was correct. The amount of storage required to hold one minute of recording can be correctly calculated as follows:
Sample rate x number of seconds x sample format x number of channels = total number of bits
Total number of bits / 8 = total number of bytes
Total number of bytes /1024 = total number of KBytes
Total number of KBytes / 1024 = total number of MBytes
So, if recording CD quality (Sample rate=44100, sample format = 16bit), the actual numbers for one minute become:
44100 x 60 x 16 x 2 / 8 / 1024 /1024 = 10.094MB (to 3 decimal places)
There’s no confusion, no doubt, no need to muddy the waters with esoteric arguments about K not equalling K. All you do is write the formula in words and then substitute the correct numbers.
PGA wrote:
Sample rate x number of seconds x sample format x number of channels = total number of bits
Total number of bits / 8 = total number of bytes
Total number of bytes /1024 = total number of KBytes
Total number of KBytes / 1024 = total number of MBytesSo, if recording CD quality (Sample rate=44100, sample format = 16bit), the actual numbers for one minute become:
44100 x 60 x 16 x 2 / 8 / 1024 /1024 = 10.094MB (to 3 decimal places)
and all I can say is I whole heartedly agree. You are absolutely correct and please, I am not trying to muddy the waters with esoteric arguments because, I think we all know, memory leakage can and does cause random and difficult to track, system crashes.
Unfortunately the formula Gale wrote is not the same as the formula you have written, the formula on the first line of the URL http://tinyurl.com/cb7tc3k Gale provided or the point I made in my post. There is one very important and maybe significant difference between these formulas and I am the only one that seems to have spotted this error. PGA, your formula, my formula and the formula in the URL all have two 1024’s in the divisor. The formula provided by Gale has only one 1024 in the divisor (actually Gale has one divisor of 1000 for the kHz and one divisor of 1024). PGA, I am very pleased you agree with my statement that to convert bytes to MB you require two 1024’s in the divisor but Gales’ equation only has one.
Gale & PGA: the point I have been trying to make is the error caused dividing by 10001024 or 10241024 is slight but maybe significant with large data files. If Gale’s formula has been taken from Audacity code, used for memory calculations, then we could very easily have memory leakage causing a crash. As formulas go the error is slight and is not really important UNLESS, as I said, the formula is used for memory calculations when we have a small error which, with a long recording time and huge data files obtained from my sample rate of 24/96, maybe grow into a significant error and cause memory leakage. However, this will not explain why no-one else has repeatable crashes using Audacity with the Audio Cache enabled or why I have not succeeded in causing my XP system to crash.
Gale wrote:
However you play with formulas, you can concur I think that 24x96 recording requires some 33 MB per minute of RAM or disk space just by looking at one minute of
recording (with audio cache disabled) in the Audacity _data folder.
this is NOT what I see. As I said in my last posting, I have started to use Microsoft’s’ Process Monitor to look at memory usage and I have no reason to doubt the results obtained from the use of this program. My results are (with audio cache disabled);-
For 1 minute of recording, averaged from 6 measurements, recording at 16/96 the memory used was 23.2 MB/minute
For 1 minute of recording, averaged from 6 measurements, recording at 32/96 the memory used was 45.8 MB/minute
and the real interesting one is of course 24/96 capture whereby we have
For 1 minute of recording, averaged from 6 measurements, recording at 24/96 the memory used was 45.8 MB/minute
My testing to obtain these results was identical and my interpretation of these measurements is Audacity is using 4 bytes per sample for both 24 and 32 bit recording.
I wonder if:-
Each .au file is 1 MB in size by default.
This is not what I seeing, my files are 780MB and not, as you say, 1MB. I don’t know the relevance of this but I thought it was worth mentioning.I agree the block file size for 24-bit (irrespective of Audio Cache being on or not) is 780 kb. I am not sure why that is at the moment. The block file size for 32-bit and 16-bit is 1 MB.
has anything to do with the file size for 24 and 32 bit recording being identical to all intents and purposes.
Gale wrote:
However you play with formulas, you can concur I think that 24x96 recording requires some 33 MB per minute of RAM or disk space just by looking at one minute of recording (with audio cache disabled) in the Audacity _data folder. Hence 38.75 minutes requires some 1.3 GB of RAM or disk space.
It would seem from my measurements 24/96 recording uses aprox. 46MB/min and 38.75 minutes would require about 1.8GB of memory. Not really relevant to the current problem but included for completeness.
If I understood you to say that you usually have 1.3 GB RAM to spare before starting recording,
Yes, that is correct. I have just looked at my system: I have between 1.1 and 1.5 GB free before starting any programs other than task manager
and given your first image shows 300 MB RAM free when you crashed, then presumably some 300 MB memory had been swapped to page file by the time of the crash.
I do not understand how you have reached this conclusion. I am not used to working out memory usage so do not know how you have drawn this conclusion. Could you please show me your calculations or reasoning to help me. I am HW based and not SW. I can see 1GB of RAM has been used because I start with 1.3GB and have 300MB free when the system crashed but I do not see how you can say 300MB has been swapped to page file. Sorry.
Was my summary at the top of viewtopic.php?p=185105#p185105 correct?
So as I understand it, you don’t crash with an Audacity setting of 600 MB, but you crash with a setting below that.
Correct: I crash with Audio Cache enabled and set to 100MB and do not crash with a 600MB setting.
System RAM appears to be no longer used at a point well above and roughly proportional to the Audacity setting.
Correct: With a cache set to 100MB system RAM appeared to stop being used somewhere between 200 and 300MB depending on the run, i.e. the point when system RAM is no longer used is not consistent.
The critical point where RAM stops being used is accompanied by the start of reductions and replenishments of system RAM which are not observed prior to that point.
Correct:
On a couple of occasions only, .au files were written to the temp folder. Soon after this critical point is reached, Audacity crashes.
Correct: As I said in a previous posting, “Audacity will crash sometime after creating directory d06 but before creating directory d07”
The onset of reductions and replenishments varies with the bit depth and sample rate of the recording and the Audacity setting,
We have to be careful here. I am using an external box for the ADC function and so I believe, though I could be mistaken on this one, the parameters that matter are only the Audacity settings as these settings will overrule any settings on my external box. I think this is correct. Please correct me if I am wrong. Although my external box will go to 24/192 I have failed to get the M-Audio S/PDIF input to lock at 192 samples. The box output 192 samples but my audio card locks to half that rate therefore my Ripping has been carried out at 24/96. For testing I run my external ADC at 24/96 and alter the Audacity settings in the edit preferences menu for sample rate and bit depth. When I vary the Audacity settings your statement above is correct.
so this is not Windows swapping to the page file when system RAM falls below the Windows threshold point. Fair summary?
I am not sure you can draw this conclusion because I have seen some crashes whereby the directories created prior to a crash contain .au data. Therefore, in my naievety I would assume Windows has started to use the page file.
otwo_pipes wrote: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.
Even after you pressed the Stop button, there were no .au files in d01?
Sorry but I cannot remember if I had used Pause or Stop. I will watch for this again and let you know my findings. If I was to take a bet I would hazard I used Stop and not Pause.
Also I note in your last image above of the folder structure, there was no d0c folder?
Correct:
And had it already populated d00 - d99?
No. Look again at the main Windows Explorer image and the sub directories of the e00 directory. The directories are d0a -d0e with d0c missing and d06 - d09 only. There are no directories d00 - d99.
I do not know if this is relevant or not but when Audacity crashes it leaves, quite obviously, many directories and sub directories in the project directory. After a crash I always restart my system so I have a reference point to continue from. Audacity does not always clean the project directories correctly when re-starting i.e I have seen 4 project directories, one in use and 3 from previous crashes, when I took the directory screen shots. When Audacity crashes and I re-start Audacity asks if I wish to recover the data. I always decline as the one time I asked Audacity to recover the data either Audacity or my system frooze. Sorry but I cannot remember which it was.
And, next question below that, you are sure the folder d01 had no .au files in it even after stopping recording?
Answered above: I cannot be sure if I had stopped or paused.
If there are any questions outstanding please remind me.
Note: To complicate matters even further:-
The last testing I performed on Friday evening did NOT produce a crash on my Win7 system no matter what sample rate, bit depth or time tests were performed. Remember, I said I had one run on Win7 that should have crashed but did not. I have made no system changes whatsoever. The only change to procedure I started to adopt was I have deleted the Audacity temp directory due to Audacity not cleaning directories correctly when re-starting after a crash. I have downloaded the Microsoft Process Manager but this is an application which is not installed. Obviously I cannot tell if Process Manager has made any changes to registry settings but it sure is not installed. To run I have to use Win Explorer and find the app Process Manager in the directory to which the download was un-zipped.
I did, indeed, fail to spot the missing 1024 in Gale’s formula. I didn’t see any divisor of 1000 (other than the implied one caused by using sample rate expressed in kHz).
Agreed and thanks