You still have not said what device you are recording from. Is it line-in to the Mac or a USB or Firewire external device? If it’s a USB device, connect it to an empty USB port on the Mac. Do not connect it to a USB hub connected to the computer.
Perhaps if rates are mismatched as they currently are, you should enable the “hardware rate converter”, but I would very strongly suggest that you make rates match if you want to solve this. If you only want to record at 22050 Hz, it’s probably more convenient to change both the input and output rates of this device to 22050 Hz in Audio MIDI Setup. If there is no option to set it to 22050 Hz then I suggest setting Audacity sample rate to 44100 Hz instead.
Earlier on this thread I specified that the problem originally occurred when recording from a wireless lapel mic. The actual connection is an analog output from the wireless receiver to the line-in port on my MBP. Thus there is no external recording device, only Audacity recording via the line-in connection.
In testing I have recorded from an external tape player via line-in as well as using Soundflower between iTunes and Audacity. Nothing I have been able to or load the system with has caused any problems here at home, even with 2.0.6. Seems really strange that I can’t duplicate it so far.
If you provide the Mac crash reports for Audacity we can see what they say. To do that, open Finder, then choose Go > Go to Folder and type (assuming you are using Yosemite):
Thanks, the actual connection is what we need to know. I still suggest you change Audio MIDI Setup for line-in to 22050 Hz, or change Audacity project rate to 44100 Hz.
Thanks, they seemed to have identical symptoms in the crashed thread. I passed them on for a developer to look at.
In some of the recording I did the other day trying to recreate the problem I had matched rates and crashes still occurred. Those crash reports I sent you were with nothing else running on screen and rates unmatched.
The computer had been running for maybe a week or two at the time, but had been put in suspend mode during transport to the church to record the sermons. Once there it was awakened and Audacity started. Audacity defaulted to 44100 sample rate so I changed the rate to 22050 and did the first recording which went fine. At the end of that I saved the recording and closed the current session using the menu item “close” then opened up a “new” session for the second recording and again set the sample rate to 22050. When it was time to start the recording I clicked on the record button and had an immediate crash. At that point I selected “reopen” from the OSx crash dialog box and Audacity opened and I was able to start the second recording. Audacity nightly Jan 4 was used the first week and version 2.0.6 was used the second week with identical results other than 2.0.6 started messing up the second recording data after about 5 minutes and the Jan 4th nightly took almost 50 minutes to start it messing up.
Both times nothing else was in the foreground. FireFox, MacMail, and a couple of other smaller programs were minimized and doing nothing. There was no wireless available there so FireFox or Mail couldn’t have been trying to access the Internet. No editing of the first recording had taken place.
My impression was it could be a display/redraw issue partly from how it crashed and partly because on Yosemite Audacity sometimes seems like it is doing lots on unnecessary screen redraws. I see this usually in that the menu bar at the top of the display will often flash rapidly 10 - 15 times when saving a file and sometimes doing some other things which I don’t remember exactly what they were now. Since nothing is changing in the menu bar why would that redraw at all? Could there be changes in the OSx display interface that are contributing to this issue? I don’t have other programs crashing as a rule.
I’ll do some testing with matched and unmatched rates this evening and see if I can make any sense out of it.
I’ve uploaded a crash report from one of the recording sessions that ended up with a messed up recording. This one used the Jan 4th nightly.
I’m one of the Audacity devs and, so far, I’ve not been able to recreate your crashes. So, I was wondering if you have time to try the latest “debug” versions we have:
It “may” help me to figure out what is going on because it may include extra information in the crash report.
Oh, and I know what you mean about the menu redrawing…that is definitely eye catching. Not sure there’s something we can do about it until we upgrade to wxWidgets v3, but I will be taking a look into it.
I’ll give it a try. If I can get it to crash do you want the same crash reports I’ve been uploading?
FWIW, I haven’t been able to recreate the crashes that happened a week or two ago, but other crashes have happened. Knowing the propensity of software to cause frustration, getting it to crash when I want it to could be a challenge. It seems as if it usually happens at the most unexpected times.
BTW, this Sunday I need to do another recording and was planning to have two laptops, one with Yosemite and one with Mavericks both recording to make sure I get a good recording. What version would you or anyone else recommend for the Mavericks laptop? For Yosemite, use the debug version or the latest nightly?
For the Yosemite, please use the debug version. For Mavericks, I should think that even the latest night should be okay, but I’d recommend whatever version you used last that worked without crashing. I’d hate for you to get another bogus recording.
Well, this weekend’s recording went with out any static so hopefully that is a done deal, BUT after the last recording, before I had saved the file, I clicked the button to display the whole recording on one page width and Audacity crashed. Thankfully upon restart it recovered the files and all was well as far as the recording went. Sure had a couple of moments of concern though. Moral - Save as first thing if possible.
I’ve attached the crash report. Used Jan 18 debug version so hopefully it will have some good info for you.
To be clear, was this Audacity’s “Fit Project” button, or the Mac’s green window button which has seen changes in Yosemite?
“Fit Project” button. Both recordings were about 50 minutes long and the window for the first recording had been closed and a new one opened for the second recording. Didn’t mention it in my last post, but I had set the “sound activated recording” feature with the sound level really low so as soon as the mute on the lapel mic was turned off there was enough noise to start the recording. It stopped the same way when the mute was turned on. I then clicked the “stop” button in Audacity then hit the “Fit Project” button. I don’t remember for sure, but I think I used the same sequence on the first recording although I may have saved first.
I find it interesting that some of the crashes several weeks ago were when starting the second recording. It’s almost as if after doing a recording sometimes something is left in an unstable state so when doing another one without doing anything else in between the possibility of a crash is greatly enhanced. Just a wild guess, for what it’s worth. The strange part is that I’ve been unable to reproduce it after hours of trying.
I agree it looks strange. Checked all the Audacity crash reports and they are all round numbers. Even two other programs that crashed had round numbers. What I found even more interesting is the numbers and the differences between boot time and awake time.
The other two programs were Google Earth and FireFox Plugin Container. Neither of them had multiple windows. It doesn’t seem as if other programs write logs like Audacity does. For instance, FireFox crashes fairly often, but doesn’t write any thing to the Diagnostic Reports directory. I was surprised to find the crash report for the Plugin Container. Those two reports, Google Earth and FireFox Plugin Container are the only other crash reports in that directory except for some hidden crash report files for mdworker and LCCDaemon all dated October 2014.
Reinforcing my decision not to upgrade right away.
Starting somewhere around Mavericks, the decision was made to make the OS much MUCH more energy efficient. The cheerfully spinning backup clock with the tiny clock hands actually moving backwards (nice graphics touch, that) turned into a still image with two arrowheads.
I remember reading that the OS actually shut down briefly instead of “wastefully spinning its wheels” on NO-OPs.
Anybody experience those hyper efficient cars that actually turn off the engine at stoplights and what a joy those things were to drive? 10.9 was practically non-functional when it came out and the first few upgrades had to do with patches so timing-critical applications would start working again.
Any of this sound vaguely familiar?
What is the effect when Audacity is forced to use a network-connected drive instead of a local drive? Any of the same symptoms?
What is the effect when Audacity is forced to use a network-connected drive instead of a local drive? Any of the same symptoms?
Not sure what you are asking here. Run Audacity from a remote drive? Use a remote drive to store data? I have a backup drive 5400 rpm drive on firewire. Could run off of that. It is really slow in comparison to what I normally use.
FWIW, I’m using a really quick SDD internal drive. Boots totally (everything up and running, no HD action any more) from start chime to finish including typing in my login password in 1 minute. Maybe that contributes to timing issues? Just this evening I upgraded memory to 8GB from 4GB so maybe that could help or maybe hinder?
Doesn’t count. FireWire is high-speed bi-directional. My last Mac Mini didn’t boot from the internal drive. It booted from the large, external FireWire drive and it did that until the drive failed to come up one day. It did video, audio, television, Audacity and other live production work just fine.
I’m talking about the Audacity System Drive living on the network instead of local. Or Audacity working over here, but its capture drive is over there. Audacity doesn’t understand network negotiation, collisions and delays and I wonder about the similarity between those errors and the general Yosemite “magic” errors.
Something like: If Yosemite is left alone long enough, it tries to go to sleep and flushes the first Audacity wake-up event down the loo. So the variable has nothing to do with length of show, number of tracks, excessive sample rate or any of the other normal causes of problems.
Along the lines about sleeping and such…I “think” I saw an audio device problem today while trying to get it to crash that was related to wakeup. But I couldn’t reproduce it. Basically, Audacity wasn’t able to talk to the audio device again…restarting Audacity was the cure. (All mostly supposition since I wasn’t able to recreate and diagnose.)
I’d hate for you to get another bogus recording.