Audacity 2.0.0, Win7 x32 SP1 2G ram
The Audacity recording process freezes at 38minutes and 36.5seconds.
By ‘process freeze’ I mean the audio and time in the ‘default view’ window (showing the amplitude and time of the recorded audio waveform) stops updating though the record and play-back level meters are still functioning. The ‘Audio Position’ indicator continues to update the time.
The audio input is still looped back and routed correctly to the sound card output.
It is not possible to export the audio that has been recorded prior to the freeze. The export function is greyed out.
Most of the time the only way to close Audacity is to use task manager to kill Audacity. Re-starting Audacity and attempts to recover the project fail due to file corruption.
Signal sources are a Pink Triangle PToo with a SME series V arm + Audio Technica cartridge. I have also been using a Pioneer TX-9500 FM tuner as a continuous sound source. The audio pre-amp is a Musical Fidelity 3A. The ADC used to digitise the audio source is an RDL HR-ADC1, a broadcast quality unit: see the following link for details of the converter:- http://www.rdlnet.com/product.php?page=506
Audacity and the RDL HR-ADC1 are set to 96KHz and 24 bit quality.
I am using the S/PDIF output of the RDL HR-ADC1 which is connected to an M-Audio Delta 192 card.
I am only using the M-Audio sound card as a S/PDIF Input Output interface. See the following link for details of the sound card:- http://www.m-audio.com/products/en_us/Audiophile192.html
I did my intial testing using the following equipment set-up:-
Audacity 2.0.0, XP x32 SP3 2G ram
M-Audio Delta 2496. See the following link for details of the sound card:- http://www.m-audio.com/products/en_us/Audiophile2496.html
All other connections and conditions are as per the Win7 set-up. I can not be certain of the numbers of runs performed on the XP set-up without problem and it may be as low as 2 or 3 albums.
Obviously there is a lot of testing that can be performed to try to ascertain the root cause and to rule out the S/PDIF interfaces on the M-Audio cards and also the RDL HR-ADC1 unit, when used with Win7. As this testing is time consuming I was hoping for pointers regarding any settings I may have overlooked in Audacity before I undertake detailed testing.
For reference, I am an retired electronics design engineer so I do not need assistance with detailing tests to prove my system, I am only interested in help regarding Audacity as this is my first experience of the program.
Then you already know that 2G of ram is the absolute rock-bottom recommended for Win7 with few if any applications running. Certainly not enough to reliably do picture or sound production.
With your system Win7 x32 you can install max 3GB of ram so it might still not enough for your set up.
That is a limitation for the 32bit system unless you upgrade (install from scratch new OS) to 64bit.
Thanks guys but my set up with Audacity + XP SP3 and 2G ram is no problem.
You seem to be suggesting that if you wish to use Audacity and Win7 then you need a 64 bit system. I have not seen this limitation in the Audacity Wiki recommendations for Win7 as per the cut below:-
System requirements
Windows 7 system requirements quoted by Microsoft are as follows for all versions of Windows 7, including the “Starter” edition with least features that is shipped with many netbooks.Unlike the Vista Starter Edition, Windows 7 Starter does not have a limit of three programs running at a time. For a comparison of features in different versions of Windows 7, click here.
1 gigahertz (GHz) or faster 32-bit (x86) or 64-bit (x64) processor 1 gigabyte (GB) RAM (32-bit), or 2 GB RAM (64-bit)
16 GB available hard disk space (32-bit) or 20 GB (64-bit)
DirectX 9 graphics device with WDDM 1.0 or higher driver For best performance if you are recording, editing or playing a large number of long tracks, we recommend twice the stated processor speed and RAM.
As you can see, I meet ALL the Audacity best performance recommendations except Audacity is not working.
If this was just a ram limitation then I do not see why Audacity would always run out of memory at 38 minutes and 47.5 seconds. This freezing at 38:47.5 is repeatable. I suspect there is something much more fundamental that is causing this problem.
I have an SME arm and Grado Gold. Terrific arm, ropes and all.
Audacity and other editors work in real time. They can’t have the computer stop a second while it does housekeeping or shuffles data around to make room. If the machine isn’t ready for the current note when it’s sung, it will miss the next one. A computer on the edge can start giving you odd missing bits and unstable behavior. Someone did a memory survey recently and found his Win7 machine was using 3/4 of the available 2G just to stay alive. So you’d be doing live audio production in 500M.
There are certainly things you can do to help. Do you have Win7 set to auto defragment the drive? I would probably do it manually and turn that off. Anything that competes with the show is to be avoided. Unplug the network and turn off Virus Protection. Are you doing email as you capture your music? Things like that. You have little or no room for error.
Audacity has a setting to Always Use Memory for capture instead of shuffling off to hard drive constantly. There is a very firm limit to how long you can go with that. Preferences > Directories > Use RAM… Have you tried capture multiple times and it always crashes in the same place? You don’t have to play a record. Just set to recording and come back in a half-hour.
Any reason you’re in such a high sound standard? Music CD is 44100/16 and television sound is 48000/16. I understand higher is better, but the machine has to struggle to save all that data and again, in real time. Then there’s the thing that Windows doesn’t directly support 24-bit. I’m fuzzy there, but I think that’s correct.
Oh, never mind. You’re using an internal custom sound card. That eliminates a lot of the housekeeping. Still, Windows has to “know” what 24-bit is.
Audacity does not require a 64 bit system. It is a 32 bit program so it is (or should be) quite happy on a 32 bit system.
For clarification, are you saying that:
The problem occurs intermittently on both your Windows 7 system and your XP system
The freeze always occurs at 39:47.5
You have only tested with recording set to 24/96
What happens if you record in 32 bit float? Does it still freeze? Does it still freeze at the same “38:47.5”?
What if you change the sample rate, for example at 48 or 44.1 kHz?
It’s running quite happily right now on my wife’s little Samsung mini laptop/notebook running Windows 7 Ultimate 32-bit.
With a bit of effert I’ve even persuaded the little beast to record streaming audio from t’interweb (which can sometimes be a challenge for modern W7 systems).
Problem solved:
Unfortunately I missed (missed = I read and did not correctly decode) the comment from Koz, “Audacity has a setting to Always Use Memory for capture instead of shuffling off to hard drive constantly. There is a very firm limit to how long you can go with that. Preferences > Directories > Use RAM…” Had I realised the implications of this statement I would have saved my experimentation using the Windows resource monitors and Vinyl Studio as a comparison tool. My recordings never crashed under VS and the resource monitors showed averages of 8% CPU & 35% memory usage; there had to be something in Audacity causing the problem I was experiencing. As I said, I miss-undersood Koz’s comment. The reason I did not follow on these comments is beneath the audacity tick box is a pre-filed box with 16M memory cache limit and the statement that if free memory falls beneath this figure then data is written to disc. I just did not twig the implications of this. With the audio cache box ticked data is indeed cached in ram. I have sat and watched my free ram drop from 1.35G to 600M and then penny dropped. So what is going on… here I have to surmise a little because I do not have the tools to diagnose but I guess writing the cached data to disc, all 1.35G, is very CPU and disc intensive, so intensive that Audacity grinds to a halt and ceases recording. If recording is stopped prior to the crash then it takes many minutes to save the cached data. I have removed the tick from the ‘cache audio’ box and everything works as it should.
If Koz is correct and selecting the Audio Cache tick box inhibits discs writes then I maybe this could be explained a little more clearly in the description alongside the tick box (just a thought). What is obvious to experienced users is not necessarily quite so clear to newbies like me… and I did look could not find anything to this effect in the FAQ, I tried many searches hence my resort to use this forum.
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
see my comment above You have only tested with recording set to 24/96
Yes, I have only used 24/96 and if I had not found the root cause during the course of today then I would have used both the M-Audio sound card and the external RDL ADC box to digitise at different bit depths and sample rates to see if there was a correlation.
Again, thanks quys, we got there in the end and I wish I had better understood Koz’s comment. The comment and explanation was spot on but it just did not register until I read all comments again before writing this update. When I read Koz’s comment this was definitely a, “Durgh Brian” moment for me.
Yes, Koz is correct.
That option is only intended to enable users that have a slow hard drive and/or slow/old machines to be able to make short recordings. By default the option is not selected.
You are not the first to misunderstand the purpose/implications of that option. Can you suggest better wording for the option?
The option is under “Directories” because it is directly related to the “temp folder location” (which is quite rightly in the “Directories” section).
Normally Audacity will write data to this temp folder unless/until the project has been saved
When “Play and/or record using RAM (useful for slow drives)” is enabled Audacity uses RAM instead of the hard drive.
I think that moving it to a “Performance” section would encourage users to enable it when not needed and so lead to the problem that you had.
Perhaps something like “Disable hard drive cache”.
Essentially the problem is that the feature does not work very well. What should happen is that when the memory limit is reached, Audacity should seamlessly switch back to writing to disk. Unfortunately it is not seamless. Obviously the switch needs to be very fast so as not to disrupt the audio data stream and it looks to my uneducated eye (I’m not a C+ programmer) like the problem lies there. It seems that sometimes the audio data stream gets disrupted during the “switch over” and that stalls the recording.
Yes that’s right also I was wondering why there’s only a temporary location but not a location you choose to save your files.
What I always do with any software I tell it to store any output to a drive/folder I created and use only for that purpose.
When “Play and/or record using RAM (useful for slow drives)” is enabled Audacity uses RAM instead of the hard drive.
From the Wiki “Minimum free memory (MB): Sets a minimum level for available system memory” this instruction is very clear but from the control panel I thought it refers to the system memory I tell Audacity to use as cache not the bare minimum left for the system to be alive.
I think that moving it to a “Performance” section would encourage users to enable it when not needed and so lead to the problem that you had.
Perhaps there are novices and experienced users, maybe a clear red warning when playing with that setting I think could be beneficial
Essentially the problem is that the feature does not work very well. What should happen is that when the memory limit is reached, Audacity should seamlessly switch back to writing to disk. Unfortunately it is not seamless. Obviously the switch needs to be very fast so as not to disrupt the audio data stream and it looks to my uneducated eye (I’m not a C+ programmer) like the problem lies there. It seems that sometimes the audio data stream gets disrupted during the “switch over” and that stalls the recording.
The default unchecked box should be enough for now, then if I know what I’m doing so I play with it and if things go wrong I set it back to default.
Apologies for not replying earlier regarding the request from Steve for new wording for this function. The delay was partially due to wanting to polish my words and partially due to weekend activities.
So, here are my efforts; I would suggest the following revision:- Start with
This function is required for legacy PC hardware. Modern PC systems should not select the tick box. If in doubt try the default, ‘Not Ticked’ setting first.
Copy the current message ‘as is’ in this area, including the tick box etc. but remove the section in brackets (useful for slow drives) as this may tempt someone to try this feature which is the exact opposite of what is required. A better explanation of how this function works can be incorporated in the user manual. and the crux is to finish with:-
WARNING: When this feature is enabled recording time is directly proportional to (free system memory)/(sampling rate)
and in red if deemed necessary…
Notes:
i) I know this feature is not dependent on legacy systems but the intention is solely to stop newbies like myself from making a basic error by enabling this function.
ii) I think it would be good to provide a list of the ‘default settings’ in the user manual but even better would be to have a save/restore function for the default and/or user settings. The ‘restore default settings’ would be particularly useful in situations similar to the problem discussed here; it would be possible to set everything back to the default and start again. A standard de-bug procedure.
iii) Koz was very clear. It is my professional ability related to reading English that was the fault (I am Welsh) and said with a big smiley face…
iv) I also thought I was setting the amount of RAM to be used as cache and not the true operation (same reason as iii) above. There is nothing wrong with the explanation it is just the function does not work as I expected and therefore I did not read correctly.
v) I have had no further problems with Audacity and, so far, I have transferred 28 albums to my hard drive.
br and thanks again to all
Dennis
@otwo_pipes, so did you have “Audio Cache” enabled on the XP system where you don’t receive the crash?
Audio Cache is not on by default. Note that caching applies to editing as well (though I think there should be an option for it to apply only to recording). 96000 Hz, 24-bit recording takes about 33 MB of cache (or disk space) per minute, hence you have used about 1.3 GB of RAM when you crash (almost all of what you had left).
Audacity is 32-bit. Even if you had 3 GB of RAM, 32-bit Windows has a limit of 2 GB memory per application for a 32-bit application. So if you had not crashed during recording, you would have crashed if you had edited the whole of the recorded track (because that would have pushed the RAM use to 2.6 GB).
If you had 64-bit Windows, then the maximum memory Audacity as a 32-bit application can address is 4 GB.
Clearly Audacity can and does crash when RAM cache is enabled before the system RAM gets as low as 16 MB. That may be a problem of the default being too low, though I know some people find Audacity will crash with this feature on when the system RAM gets down to 600 to 700 MB. The developers so far have not shown much interest in looking into this, but may find they cannot reproduce the problem. With an old Win 7 64-bit system with only 2 GB RAM (therefore only just matching minimum requirement), I can repeatedly go down to 16 MB system RAM remaining and have Audacity then switch to disk writes with no crash.
On the documentation of system requirements, see http://audacityteam.org/download/windows#sysreq where it says the recommended Audacity requirement for Win 7 32-bit is 4 GB RAM (the maximum RAM you could install). Note however that even with 4 GB RAM installed, typically only 3 GB to 3.5 GB will be available for applications. We went for a 4 GB recommendation even for 32-bit Windows on the basis of experience with the previous 1.3 Beta series working with hour long recordings or more (irrespective if Audacity RAM caching was enabled). I’ll make this clearer on the Windows 7 Wiki page.
@Gale: Yes, I had caching enabled on the XP system because I had mis-understood the purpose of the cache switch.
I have now repeated the XP system test and found Audacity grabs memory until aprox. 1.3 GB has been used. This equates to recording for about 35 minutes and then Audacity starts disc writes and I have not seen any problems. I left this test run for just under an hour. This repeat testing was using the internal sound card but the Audacity settings were still 24/96. The temp files stored on the hard drive for this test total aprox. 1.9 GB. If you want me to repeat with the high speed sound card then I can though I do not see what benefit this will give. BTW the 24/96 card is not no longer fitted in the XP system so I would have to re-install the drivers etc.; this will not be an immediate task though I could repeat the tests tomorrow evening.
My XP system is SP3 with 2GB RAM and a pretty slow Celeron processor. The system was bought second hand years ago so I guess it is`15 years old. My Win7 system is only 2 years old with a SATA II hard drive and is significantly faster than the XP system. I see regular 60% CPU usage on the XP system and only occasional CPU usage in excess of 20% on the Win7 system when Audacity is recording. I am do not use either of these systems for general computing when Audacity is recording though there is various security sw running. Both systems have a wired Internet connection.
If I can be of any further assistance, or there are any tests you would like me to undertake, then please point me in the right direction.
@otwo_pipes, all images in the Manual show default settings unless otherwise stated. I’ll add your vote for some way to reset to the Audacity defaults from within the Audacity Preferences. At the moment, reset is done by editing the audacity.cfg settings file (see http://manual.audacityteam.org/o/man/preferences.html#stored ).
I tried to tweak the Manual page for Audio Cache ( http://manual.audacityteam.org/man/Directories_Preferences#cache ) - the wording for “Minimum free memory (MB):” now says “Audacity will use RAM until your total available system memory falls below this level, then will write data to disk instead”.
If you want to test on the Win 7 machine, I would be interested to know if you avoid crashing if you set “Minimum free memory” to about the system memory you have left before the crash. Is this about 600 MB?
