I am running Audacity 2.1.2 on Windows 8.1 64-bit OS, downloaded from the installer on the official website. My OS and Audacity are being loaded from a Samsung 500GB SSD. I’m running an AMD FX 8350 Vishera 4Ghz 8-core processor, with 32GB 1600Mhz RAM and a Gigabyte GA-990FXA-UD3 rev. 3.0 motherboard.
I am using Audacity to sync nine 4.5 hour tracks to review each of them synced time-wise. Once I have the file loaded, the program becomes very laggy and unresponsive in most cases only after just clicking and scrolling. I haven’t even started the track yet. I feel like with my setup, this task should be a breeze and shouldn’t be bogged down as much as it is. Everything else works fine, just Audacity is affected. I’ve tried running in compatibility mode and Windows troubleshooter actually says there a software conflict and Audacity is incompatible with Windows 8.1.
I have no idea what is going on here, and I’ve exhausted all avenues while trying to resolve this. Any help is appreciated.
I also have two EVGA GTX 970 graphics cards. I am still learning about how this all works together, but I would think that my system would run this just fine… This has been a source of great frustration the last few weeks and I would really like to figure this out.
That is a HUGE amount of data. Assuming 44100 kHz sample rate stereo tracks, that would be close to 50 GB of data. Audacity handles audio in blocks (“blockfiles”) that are about 1MB each, so for each track Audacity has to keep a record of around 10,000 blocks of data. If you look at an AUP file in a text editor you can see how Audacity manages data in a project. As an example, this is the data for tracking one blockfile:
You will note that Audacity has calculated the start position, length, mininmum, maximum and rms values for the block, and it does this for all 10,000 blocks in each track. It does this so that it can draw the waveform. I don’t know what you would call “very laggy”, but handling this amount of data is certainly non-trivial and even on a fast machine I would not expect Audacity to be “snappy”.
Thanks, Steve. I figured that would be the case in this situation… Sometimes it would snap out of it and handle it perfectly fine, but the thing is I had been having problems with the program when I was just reviewing one 4.5 hr track at a time. Maybe a 3-4 second delay between mouse click and program response. Where as with the 9 tracks in one .AUP file, I am having anywhere between a 10-20 second delay.
Yestderday, I changed the processor affinity for Audacity to just one core and it actually helped with reducing the delay. I was able to do what I needed to do for a couple hours before I got burned out and tired. So, this might be part of the answer. I am going to play around with it some more and see what the results are.
I was told that some games will use the CPU to handle high quality graphics and multi-core CPUs will not handle that so well. I feel like this will be the same here as well. In some cases, turning your graphics settings higher will put more load on the GPU and off of the CPU. I would like to find out how to assert something like this to Audacity.
Currently Audacity only uses one core, so if you see more than one core being used by Audacity, that’s something that your OS is doing. On my dual core machine I see Audacity switching from one core to the other, which is due to heat management by the system. On my machine, this switching occurs every few seconds when processing a long track, so there is negligible impact on performance other than preventing the core getting too hot and throttling back. Rapid switching, or moving threads to different processors could have a negative effect on the performance of Audacity. Multi-processor support may be implemented in Audacity in the future, but for now it is a single processor program.
Sometimes it would snap out of it and handle it perfectly fine
That would get my attention right there. We can justify a slow machine or process, we can’t justify when a machine gets it in its craw to work right sometimes…and not others.
Did you make the machine? Have you ever used a memory checker? Highly recommended.
It could be explained by Audacity using a cached image of the waveform image (fast), but when it can’t do that the track data must be re-analyzed before it can be drawn (slow). Even on a fast machine, analyzing many GB of data will not be instant.
But I would not necessarily expect that memory is anything to do with it. Turning off as many other applications as possible while using Audacity might help.
Setting Audacity to 16-bit Default Sample Format in Quality Preferences would halve the data being pushed around. This is a reasonable approach if you are not actually applying effects to the files, as you seem to imply.
