Static/distortion on recording in Yosemite

[Gale Andrews]

I've read of others having static on recording, but it goes away when the file is exported. Unfortunately in my case it is still there after exporting and playing it in ITunes. I've exported to .aiff and MP3 with same results. I'm recording in Mono and at a 22050 project rate.

I've tried 2.0.6 and the nightly build of Jan 4th 2015. 2.0.6 was far worse.

On 2.0.6 it starts after about 5-7 minutes of recording speaking and is very much like static, but only occurs when there is speaking. When the recording is silent there is no "static". I can see lots of little spikes when I spread the audio out. Most are only about 6 samples long.

On the nightly build of Jan 4th it was fine for about 50 minutes then started having issues.

We need to be sure whether this is a recording issue or not. I'm not 100% clear it's a recording issue.

If you never played the recording before exporting it, the playback "uninitialised buffer" bug that is fixed in the nightlies after 21st December could occur and you could definitely get crackle exported (even if the recording was perfect).

A good test would be to play before exporting. If you hear crackle in different places each time then as Koz says, that's a playback issue.

Really I would try to test with the nightlies, not just because of the uninitialised buffer playback fix, but because there are some other Yosemite-specific interface and effects fixes. 2.0.6 does not officially support Yosemite.

Another obvious question is your use of 22050 Hz project rate in Audacity. Can you say what your recording device is (make and model number)? If it's any kind of upmarket external device it will not be defaulted to 22050 Hz. It will absolutely be expecting 22050 Hz to be set for it in "Input" and "Output" in /Applications/Utilities/Audio MIDI Setup if your recording software is set to that rate. Mismatched sample rates are a primary cause of recording and playback issues.

Changing Audacity "Audio to buffer "might" help, but reducing the buffer usually only helps if it's really a playback problem.

I don't know if this is related, but on both occasions I recorded another speaker with no problems at all. Immediately after that recording I saved the recording and selected close from the menu. After that I selected a new session. When I clicked on record to start the next recording Audacity crashed. I then restarted Audacity and did the recording that had the issues. Could the crash have left things in a state that is causing the problem?

If this was in 2.0.6 it could be relevant, given this was a playback problem and not a recording problem.

It should not be relevant in the current nightlies.


Gale

[cmac185]

Gale,

Thanks for the reply.

I do significant editing and playing of the recording in Audacity before exporting so am sure it is not just a playback issue. I would be very glad it it was playback only, but it doesn't seem to be so. The Crackle, once started, continues for the entire recording so isn't just a momentary issue like system overload. On a particular recording it always starts the same place which is also evidence that it is on the recording and not just playback.

You raise an interesting point regarding the Midi settings. I have never touched them. Looking at their settings I find that the "hardware rate converter" is disabled and the input is 44,100. I'm only using Audacity for recording and the input to the computer is analog line-in so do the Midi settings make any difference? I've been recording using the 22050 only because that is the eventual sample rate that I have to end up with to post the file on-line and it takes less space in storage that way. I could record at the 44100 I suppose and covert it later if that was a solution to the problem.

You say that the crashing/restarting issue should not be relevant when using the nightlies. What could explain being able to record for 40 minutes with zero problems and then and hour later doing another recording with the same software and hardware setup and no changes made between times except that Audacity crashed when trying to start the second recording so it was restarted and the second recording was messed up? This has happened two weeks in a row with the first time using the Jan 4th nightly and this last week using 2.0.6. I'm not saying that you are wrong, just trying to understand what would trigger the issue after that long a time of working well.

I've been trying to break it most of the morning. I did download the Jan 10 nightly and used that and can't seem to break it so far. I loaded the computer up to the max with recording a video from my camera via iMovie, recording with Audacity, starting and running a Virtual Machine of Ubuntu, doing other things with FireFox etc. Memory was more than used up and CPUs maxed out and no issues cropped up.

Audacity did start crashing when it was running and I either hit stop or one time the mouse just brought it to the foreground and it crashed. I've never seen Audacity so unstable as it is these days. It seems ok as long as I'm just using it and not doing other things. At least the Jan 10 version restarted ok and didn't seem to mess up the subsequent recording.

One question - I was recording music, is there any likelihood that voice would make any difference over music in terms of the problem we're chasing?

I guess I'll go back to 2.0.6 and see if I can make it mess up to prove I can duplicate the issue here at home. Maybe the Jan 10th build fixed something.

Thanks Gale and Koz for hanging in there with me. Hopefully we can "catch this rabbit".

Cliff

[Gale Andrews]

You raise an interesting point regarding the Midi settings. I have never touched them. Looking at their settings I find that the "hardware rate converter" is disabled and the input is 44,100. I'm only using Audacity for recording and the input to the computer is analog line-in so do the Midi settings make any difference? I've been recording using the 22050 only because that is the eventual sample rate that I have to end up with to post the file on-line and it takes less space in storage that way. I could record at the 44100 I suppose and covert it later if that was a solution to the problem.

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.

If this device has any control panel or settings of its own for sample rate, set those to 22050 Hz too. If it has any buffer settings of its own, look at those too.

You say that the crashing/restarting issue should not be relevant when using the nightlies.

I am saying only that if there was corrupted audio in the buffer due to the crash, that could be a problem in 2.0.6 but not in 2.1.0-alpha, because that later version now resets the buffer.

What could explain being able to record for 40 minutes with zero problems and then and hour later doing another recording with the same software and hardware setup and no changes made between times except that Audacity crashed when trying to start the second recording so it was restarted and the second recording was messed up? This has happened two weeks in a row with the first time using the Jan 4th nightly and this last week using 2.0.6. I'm not saying that you are wrong, just trying to understand what would trigger the issue after that long a time of working well.

Please remember that Audacity does not officially support Yosemite so we are in somewhat uncharted territory. Also we do not know what device you are recording from or (if it's an external device) whether it has correct drivers and firmware. All we know is you are running with mismatched sample rates which I strongly suggest you correct.

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):

Code: Select all

/Library/Logs/DiagnosticReports/

I've been trying to break it most of the morning. I did download the Jan 10 nightly and used that and can't seem to break it so far. I loaded the computer up to the max with recording a video from my camera via iMovie, recording with Audacity, starting and running a Virtual Machine of Ubuntu, doing other things with FireFox etc. Memory was more than used up and CPUs maxed out and no issues cropped up.

Audacity did start crashing when it was running and I either hit stop or one time the mouse just brought it to the foreground and it crashed. I've never seen Audacity so unstable as it is these days. It seems ok as long as I'm just using it and not doing other things. At least the Jan 10 version restarted ok and didn't seem to mess up the subsequent recording.

Those two paragraphs seem a little contradictory, but I would personally try providing some crash reports and shutting down as many apps as possible when using Audacity. Reintroduce other apps one by one to see if you can find an individual culprit app or a stress point beyond which Audacity becomes unstable.

I was recording music, is there any likelihood that voice would make any difference over music in terms of the problem we're chasing?

Recording music from where and how? From a loopback cable? Using Soundflower?

If you mean you were recording a hymn rather than a sermon by the same method, no that makes no difference.

I guess I'll go back to 2.0.6 and see if I can make it mess up to prove I can duplicate the issue here at home. Maybe the Jan 10th build fixed something.

I would stay with the 2.1.0-alpha (latest one you have). We won't be going back to 2.0.6 to fix that.


Gale

[kozikowski]

https://discussions.apple.com/thread/6606703

This may not be a simple Audacity problem.

Koz

[cmac185]

https://discussions.apple.com/thread/6606703

This may not be a simple Audacity problem.

Interesting thread. I reset the PRAM a month or so ago for another reason.

Cliff

[Gale Andrews]

And... get those sample rates matched so that if there is clicking in the recording, we know that sample rate conversions aren't the cause.

Gale

[cmac185]

Status report: This last weekend's recording went off without a hitch using the Jan 11 Debug version and with matched sample rates. My attempts to cause a crash have failed so far. Spent several hours trying everything I could think of to duplicate past crashes or just to cause the OS to get confused and nothing happened. Guess that is good, but I wish I could get good data with the debug version to help track down the crashes. Will keep using the debug version for a while and if anything strange happens I'll report here. I hate it when things appear to have fixed themselves for no good reason.

Thanks to everyone for your help and suggestions!

BTW, is there any way to find out what the differences are in the nightly versions? Thought that might be helpful in seeing what could have changed that fixed a problem.

Cliff

[Leland]

Status report: This last weekend's recording went off without a hitch using the Jan 11 Debug version and with matched sample rates. My attempts to cause a crash have failed so far. Spent several hours trying everything I could think of to duplicate past crashes or just to cause the OS to get confused and nothing happened. Guess that is good, but I wish I could get good data with the debug version to help track down the crashes. Will keep using the debug version for a while and if anything strange happens I'll report here. I hate it when things appear to have fixed themselves for no good reason.[/quote/

That good news...I've learned not to look a gift horse in the mouth and to hope it doesn't keep you in the arse as it passes by.

BTW, is there any way to find out what the differences are in the nightly versions? Thought that might be helpful in seeing what could have changed that fixed a problem.

About the only way is to look at the commit log:

https://code.google.com/p/audacity/source/list

Leland

[Gale Andrews]

Now that the crackling issue is fixed, I split the crashing issues to a new topic http://forum.audacityteam.org/viewtopic ... 47&t=83320.

Gale

[cmac185]

Guess what! The crackling/static/whatever is back in full force!!!!!!! Using Audacity Jan25 Nightly Debug version on Yosemite 10.10.2. It really messed a very important recording and there is nothing I can do about it now. Grrrrr...........

I hadn't done any recordings for a while as I only do it as a backup person. Had to do one again this Sunday and the situation is exactly the same as before. Do one recording and all is fine. Save file then close Audacity to try and keep from having any issues. Restart Audacity and let sit for probably 45 minutes then start recording. First 15 minutes are fine then gradually the popping sound starts and gets worse until the recording is finished, about 30 minutes. The popping is only heard when other sounds are being recorded. During a speaker's pause, all is quiet including no popping. The sound at the end reminded me of a machine gun. Very regular sharp pops. On the medium volume passages the pops are visible on the wave form.

I am using a wireless mic to a receiver and the receiver's output is routed to Line-in on my 2009 MacBook Pro. The midi sample rate is set to the same as Audacity, 44,100. I am recording mono since there is only one channel coming from the mic. Now that I think about it I may have gone to Stereo recording at the end of my last episode several months ago. Hopefully that wouldn't be an issue.

The laptop has other programs minimized, but none that use audio and none are actively running doing anything. Swap file is not being used, lots of extra memory. No Internet connection available.

Help!!!! Please!
Cliff