Processor: Sandy Bridge i5-2520M
OS: Windows 7 Home Premium 64-bit
Audacity 2.0.0 (Unicode)
Nero AAC Encoder version 1.5.4.0 (the zip says it’s 1.5.1.0 though)
Source file: AC3 2-ch 384 kbps
So, the issue described in this thread still exists in the current version of Audacity. I’m using a similar command line
neroAacEnc.exe -ignorelength -if - -of "%f"
and Audacity freezes at exactly the 138-th second. Killing neroaacenc.exe restores the response of Audacity. Logs and command window output is exactly the same as in the thread I quoted.
Here’s some snapshots of CPU load (with 2 and 4 logical processors) during the freeze. CPU load seems to cycle, and they seem to add up to ~100 (equivalent to system’s 25%) altogether.
Limiting Audacity.exe to 1 logical processor works. But encoding takes ~4 or 5 times longer. Any ideas? Please let me know if you need more information.
As I understand it, Audacity is not (yet) multi-processor aware and most processing tasks are done in a single thread. Implementing full multiprocessor support would require a major rewrite of the Audacity code, but the developers priority has been on fixing bugs and releasing Audacity 2 rather than engaging in a major rewrite.
There is some discussion about this here: http://audacity.238276.n2.nabble.com/multithreading-td2240954.html
I don’t know if the developers have any imminent plans in this area, but I can ask.
It appears that the Nero encoder (designed to be used with Nero) is expecting multiple threads when running on a multi-processor machine and stalls after 138 seconds if there is only a single thread. If Nero intended to support non-multi-threading applications, then it would probably be a bug in the encoder, but as Nero probably have no interest in supporting such then we’re probably stuck with the limitation until such time as Audacity supports multiple processors.
