I’m absolutely gutted. After losing recordings with using Audacity with an external USB microphone on two occasions (see https://forum.audacityteam.org/t/strange-audio-problem/40611/1), I decided to just use the internal microphone. I tested the recording before starting and it seemed ok. After recording for 2 hours and now listening back, the audio has large skips in it throughout the entire recording, where it presumably just didn’t record for a second or two every few seconds. This is different to my previous problem. I’m posting here in the hope that maybe it could be recovered, but I don’t feel optimistic. Any ideas? Is there a way to listen to the raw source audio to check?
Wifi was off. Audio to buffer is 100ms. No, transposing of audio did not return. The skips that occurred during this recording were consistent all the way through.
I can’t depend on Audacity to reliably record audio. This is a fairly high powered computer using its internal microphone and was not busy with few applications open and low CPU usage. If quicktime and my iPhone can reliably record audio with its built in App – while compressing to mp4 – why can’t audacity? I will be experimenting with other applications in the future to record the audio.
To say I’m disappointed is an understatement – three times I have lost recordings, and this was a long one. I was silly not to at least use multiple devices to record this time, but I assumed that audacity would at least be able to work correctly with the internal microphone, and it has done fine in the past – this is a new problem, and therefore I assume a bug in Audacity related to macOS 10.12 or something.
Thanks for the link. We’ve seen that before, but it was decided not to blanket turn AppNap off or turn it off by default or turn it off when recording. After all AppNap is an operating system default and it is designed to save power and increase system responsiveness. Many people can record without dropouts with AppNap turned on, and generally speaking the Mac should not put an app into AppNap when recording.
It’s much more likely that Audio to buffer is the problem, among things we control. It’s set at an inappropriately high default due to something that changed in the third-party Audio I/O library we use. That one is listed on our bug tracker.