Crashing on Yosemite

[cmac185]

10.10.4 will be out soon and will (finally) have a network fix included. The problem was that Yosemite often reported a working network as unavailable. Only DNS failed and the conclusion was you had no internet.

Unfortunately, this error also affected some other processes. I've never seen it affect audio (certainly not Apple's internal audio), but there's always a first.

Now I come to think of it...

Could it be I never see this kind of error, because all the audio people I support occasionally have their system set to never sleep?

Glad to hear about the network fix coming out. Maybe it will fix some strange behavior we have with iChat/Messages on our home network.

My system is set not to sleep so maybe you're right.

Cliff

[Gale Andrews]

I had wondered about recording in the same window. Could try that.

I know one user for whom that does not prevent the crashes, but does make them less common.

Restarting Audacity between recordings also seems to keep it from crashing as far as I can recall.

OK thanks I made a note of that in the bug report.

Checking the bad file in parallel with the file recorded on the other machine all seemed fine until about 10 minutes into an hour long recording. Then the lost data/dropouts start to happen. Though I haven't gone through the whole recording I checked 6 different bad spots and 2 were very close to 12 seconds, 3 were very close to 6 seconds and one about 3 seconds.

Those are very long for conventional recording dropouts.

The Audacity AU data files written during recording will all be the same length except the last one(s). If the data files are only 3 seconds long and you are recording at default 32-bit float, this suggests you are recording at 88200 Hz or 96000 Hz. High sample rates are not going to help if you are at risk of recording glitches. So I would make sure you are recording at 44100 Hz.

If you are indeed recording at 41000 Hz 32-bit float then AU files except the last one(s) will be about six seconds long, so a dropout of 3 seconds won't be caused by a recovery error. As another test, if you select a dropout, open Effect > Amplify... and "Amplification (dB)" is not zero, it's a recording problem, not a recovery problem.


Gale

[cmac185]

Those a very long for conventional recording dropouts.

The Audacity AU data files written during recording will all be the same length except the last one(s). If the data files are only 3 seconds long and you are recording at default 32-bit float, this suggests you are recording at 88200 Hz or 96000 Hz. High sample rates are not going to help if you are at risk of recording glitches. So I would make sure you are recording at 44100 Hz.

If you are indeed recording at 41000 Hz 32-bit float then AU files except the last one(s) will be about six seconds long, so a dropout of 3 seconds won't be caused by a recovery error. As another test, if you select a dropout, open Effect > Amplify... and "Amplification (dB)" is not zero, it's a recording problem, not a recovery problem.

I am recording at 44100 Hz 32 Bit float. One thing that I didn't think to mention before is that the recovered recording was about 29 minutes long where the actual recording time was about 1 hour. There are no areas to amplify. The data is actually missing, not just a blank or very quiet spot. Listening to the recording the audio just jumps the 12 sec or 6 sec or what ever length is missing like that section was cut out/deleted. I didn't think to look at the time line before saving. If I had we would know for sure if it was a recovery problem or not, but it seems to me that drop outs in recording have always still continued the time line to the full length of recording.

Could Audacity momentarily hang/pause if the recording buffer is just a little too small? I know when I was testing that I tried it at 6 seconds, I think it was, and it recorded fine for a short time then Audacity hung. Restarting Audacity was the only way out. If that is happening in this case then it is restarting itself which to me seems highly unlikely, especially for the several hundred missing spots on the recording. Audacity wasn't hung at the end since it responded normally to the stop button before I tried to save the file. Maybe I need to wait longer before saving? There probably was 3 seconds between the stop button and the cmd-s.

Cliff

[Gale Andrews]

The data is actually missing, not just a blank or very quiet spot. Listening to the recording the audio just jumps the 12 sec or 6 sec or what ever length is missing like that section was cut out/deleted.

Without the log, AUTOSAVE file and temp folder it is total speculation. Hopefully you know now what information to provide if you get a bad recovery in future.

Audacity wasn't hung at the end since it responded normally to the stop button before I tried to save the file. Maybe I need to wait longer before saving? There probably was 3 seconds between the stop button and the cmd-s.

When you press Stop, Audacity will only have a maximum of two AU files left to write, so you should not need to wait.


Gale

[cmac185]

Without the log, AUTOSAVE file and temp folder it is total speculation. Hopefully you know now what information to provide if you get a bad recovery in future.

How long does the data in these locations (log, autosave & temp) remain there after the recovery attempt? Do I need to save them with every crash before recovery to be sure they don't go away if it thinks it did a good recovery?

Cliff

[Gale Andrews]

Without the log, AUTOSAVE file and temp folder it is total speculation. Hopefully you know now what information to provide if you get a bad recovery in future.

How long does the data in these locations (log, autosave & temp) remain there after the recovery attempt? Do I need to save them with every crash before recovery to be sure they don't go away if it thinks it did a good recovery?

The log is cleared on exiting Audacity.

The temp folder and the AUTOSAVE file for the project window are deleted when you close that Audacity window normally (saving changes or not saving changes). To preserve the temp data and AUTOSAVE file for that window you must force quit Audacity.

Gale

[cyrano]

But why record 32 bit float?

AD's provide either 16 or 24 bits per sample. I've always believed that should be the input setting and the DAW will work with 32 bit float internally.

Or is that a fairy tale? Or is Audacity different?

[cmac185]

I think I've figured out the issue that caused my crash last week and this week. It was mentioned earlier that sometimes turning off putting the screen to sleep helps. That thought was key to at least one solution for me.

Today I tried to duplicate exactly what happen last week to see if it was random or not. Everything happened the same as last week with the exception that both the first and second recordings (not just the second one as last week) had the major dropouts that I first saw last week and thought were because of a bad file recovery after the crash. It turns out it was not a bad recovery at all, but a combination of turning back on App Nap and then allowing the screen to go to sleep. Thankfully I was able to duplicate things at home so was able to verify my conclusions. Apparently Yosemite was trying to put Audacity to sleep since the display was off and App Nap was allowed. Why it can't tell that Audacity is really busy is another question, but the problem goes away when App Nap is turned off. Then putting the display to sleep is no problem, at least as far as recording. I was able to see the CPU load go from a normal 35% for Audacity recording to 70%+ after waking the display up. The display was also noticeably jerky and the dropouts started very shortly after putting the display to sleep.

My thinking regarding the crashing is that what ever is going on to cause the extra CPU load causes a problem when stopping or doing something else requiring a significant display rewrite. Today it was just hitting stop that crashed it, last week it was hitting cmd-s to save the file. I could be all wet on this, but it makes sense to me anyway.

I could upload the crash report, but it seems to be the same as last week with the OSSpinLockLock+11.

Question: Would there be a way that Audacity could tell the OS to never put it to sleep or to raise it's priority to a place where it wouldn't go to sleep? I don't know on OSx, but in some other OSs a "real time" app can set its priority so it gets all the cycles it needs to keep up.

Cliff

[cmac185]

After I posted the above I played around a little more and increased the priority and ran Top. Interestingly in Top Audacity is shown to sleep then run every couple seconds the sleep again. This is with App Nap off so this sleeping is different than "Napping" I assume. For some reason I was expecting that Audacity was constantly doing things during recording, but apparently not even though the display is constantly updating. Since there are 6 threads it says, maybe it is just the main thread that is sleeping and others not. Setting a higher priority didn't seem to change anything.

Another interesting observation is that minimizing Audacity using Cmd-h changes the CPU load from 35% to 10% on this machine. Quite a reduction in load by not updating the display. Note: 'minimizing" by using the amber, middle, button on the display window does nothing to change the CPU load. Reading on the Wiki about how to reduce loads in Audacity it mentions turning off the "Update Display while playing." This only turns off the updating of the track window size, not the real time displaying of the recorded data and even when the recorded data goes out of view off the end of the track display the CPU load is only reduced by abaout 2%.

Cliff

[cmac185]

Another crash. This time Audacity was not even visible, i.e. on another "desktop" on my Mac and I plugged in my second monitor. Doing that always flashes the screen. It was at that instant that the crash occurred. Looking at the crash log the same OSSpinLockLock+11 seems to be the reason. How you could track it down I don't know, but all these crashes seem to have display rewrites as common. Leland a while back indicated that he was aware of all the display flashing during some operations and that it was due to using an older video api or something of that sort. Could something in that realm be the root cause of all this crashing?

Cliff