I’m running OS X 10.9.5 on an iMac 23.5 inch and using Audacity 2.0.6. I obtained it from the dmg installer.
I’m getting major stutter-like dropouts during playback after recording sound off the Internet, plus some clicking noise. Sounds fine during record, though I think I can hear some clicking, though very faintly. I thought it might be a latency issue so I tried doubling the buffer time to 200 in preferences but it didn’t help. Used to run 1.3.14 beta on my old mac pro desktop for years and never had a problem. Now I’m experiencing all sorts of issues (see my other post on input levels being too low). Ah, progress…
I’m not doing anything while recording, really. I may have a bunch of programs running like MS Office stuff but nothing that uses sound.
However, thanks to your suggestion I zoomed in to the waveform and didn’t see any dropouts, neither flat blue lines nor blank spots. Also, the damage appears to be in different places with each playback rather that occurring at the same place. So I guess the audio was recorded intact and it is just sounding horrifically bad on playback for some reason.
I am recording in stereo and as far as I can tell both waveforms start on the timeline at zero. I have no other tracks.
Thanks for warning me about Yosemite. That was going to be my next step but experience has made me reluctant to upgrade to a new OS for at least a year.
Be aware that alpha builds may have bugs and may not be as stable as release builds. The latest builds should be quite close to release ready for Mavericks, but bear it in mind. Otherwise wait for the next 2.0.7 release towards the end of the month and let us know if it helped.
I tried recording with nothing else running other than Audacity and Safari and I recorded at 16 bit and in mono. Still the same problem.
I just now tried your suggestion and downloaded the beta but when I tried to open it I got an error message saying it could not open “because the identity of the developer could not be confirmed.” Any suggestions?
Updating Soundflower did the trick! No more dropouts! In fact my input levels look healthier, too, so it solved both my problems!
I can’t remember where I got the idea to update Soundflower, either it was mentioned when I downloaded a new copy of Audacity (thinking mine was corrupted) or when I downloaded the beta, but glad I spotted that suggestion! Hopefully this thread will help others with the same problem.
This problem was a killer for me so I’m thrilled. Thanks for all your attempts to help earlier!
Well I mentioned it, for one. But what device were you using for playback? If the glitches sounded in different places each time, then it was a playback problem. In that case I don’t see why updating Soundflower should help, unless you were using Soundflower for Audacity playback, with Soundflowerbed switched on. Was that what you were doing?
Yes, that is exactly what I was doing – using Soundflower as both my input and playback device with Audacity and yes with Soundflowerbed on. I wasn’t aware there was any other way to set it up. In fact I thought that’s what Soundflower was for, to be the go-between for all audio sources so everything gets sent to Audacity for recording and playback. It just never occurred to me to update Soundflower until I saw it mentioned (here or during the re-downloading process for Audacity, I can’t recall where).
Thanks for the reminder to change my buffer back to 100 ms. It worked at 200, too, but best to be “normal” for future issues as Koz said.
The reasons for doing it Koz is to stop crackling playback on Mac. We’ve heard many times that this works, usually by reducing “Audio to buffer”.
I have to reduce “Audio to buffer” on my Mac Mini to stop crackling when choosing Soundflower (with Soundlowerbed running) as Audacity playback device. Soundflowerbed has a Buffer Size setting, but it does not stop the crackling for me. Obviously if changing “Audio to buffer” does not help, yes - go back.
If you do have to reduce Audio to buffer for playback this is a risk in principle for getting recording dropouts, but reducing buffer for playback on affected Macs seems to not harm recordings on those Macs. Do you have evidence it does?
Or at least I don’t think so. It’s hard to tell now since I’ve tried so many things. What happened was, after not using Audacity for a couple of days when I tried it again the dropout problem suddenly reappeared!! So of course I’m like all, sunuva – @#$!%$! So I started from scratch with a new copy of Audacity 2.0.6 for Mac (I think I was last using the beta based on previous suggestions). No love. Then I tried changing the buffer again, only this time I REDUCED it from 100 to 50 – and it worked!!! This seemed strange to me because I thought the whole point of a larger buffer was to ease the workload on the CPU. Doesn’t lowering it make it harder?
Another interesting note, I played around with different buffer values to see if I could hear an optimal point of clarity. 25 caused an entirely new kind of distortion or clipping or something (though it would only appear after a period of time of good sound, not right away) and 75 was the same dropout as before. So it would seem 50 is the perfect Goldilocks number.
I have no idea how or why the problem went away earlier, but this seems to be the ticket. You guys might want to delete Soundflower from the topic now?
By the way, thanks for making me aware I don’t have to use Soundflower for Audacity’s output device.
And thanks for your responses and this forum in general!
Yes it is counter-intuitive but it is what I was suggesting doing. As I said, I have to reduce Audacity’s Audio to buffer myself in the alpha builds, but only if if I set Audacity to use Soundflower as the playback device. There is no longer a constant crackle as there used to be before the fix referred to above, but I get a click when I start playback unless I reduce the buffer.
Most people return the Mac playback device to built-in audio after recording with Soundflower, so they may not hear the problem.
You can’t set the buffer too short or the computer won’t be able to get back soon enough to top the buffer up.
First off, I mis-remembered. I meant the alpha version, not beta. 2.1.0, I think it was.
Second, I apologize for not being very scientific in my methods earlier. It now seems it wasn’t the buffer after all! Or rather, the buffer was one of two variables that needed changing, hence my confusion.
Earlier, with Soundflower as both input and output, reducing the buffer to 50 solved the issue. (Yes, it was your comment about reducing the buffer that made me try it. I had been increasing it before. I think the FAQ or wherever I got the original suggestion only said change, it didn’t say decrease.) So I thought this was what fixed it. Except NOW (in response to your last post) tried it with the buffer at 50 and then at 100 just to prove that’s what fixed it but to my surprise it worked both times without dropouts! Then I tried changing the output on Audacity from Built-in Output back to Soundflower where it was originally – and the dropouts came back! (At buffer = 100)
So the upshot of all this appears to be as follows:
With Audacity set to Soundflower as input and Built-in Output as output, it works fine with the buffer at the default 100.
If some idiot like me sets Soundflower as both input and output device, the dropouts occur.
If, however, that same idiot for whatever reason wants to keep Audacity set to Soundflower as the output device, he can fix it by lowering the buffer to 50.
Whew! Long journey for THAT bit of learning!! I hope this post will save others from my fate!
Was that with 2.0.6? That is pretty much what I find with 2.0.6, although with 2.1.0-alpha after December 21st, I can play Audacity to Soundflower with only some starting clicks at buffer of 100, and I can play to Soundflower without problems at buffer=80.
Yes, it was 2.0.6. The only reason I didn’t stick with the alpha version is the VU meter was kinda hard on the eyes (I assume that will be fixed?) and, well, it’s alpha, which to my mind always sounds sketchy until it’s a “real” release.