Audacity crashing on Big Sur

I have a mid-2014 Mac Book running Big Sur and Audacity 2.4.2
My goal is to record calls at home (trying to avoid going in to the radio station in this time of Covid)
I have a Blue Yeti for my voice in my little dead sound silo in the basement
I have Soundflower running to connect the google call with Audacity
I created an Apple Midi Aggregate combining Yeti and Soundflower, and set up the Audacity Device correctly (input is aggregate, 4 channels) - Apple set up in System Preferences is correct for this set up also (re input and output)
For a brief, shining moment it all worked and I recorded myself on the Yeti and the google call I made on the 4 tracks. It was an exciting moment. And just that - a moment.
Now I cannot repeat that initial brief success - every time I make a call while poised to go in front of the Yeti and hit the record button Audacity either closes itself altogether, or stops and I get the spinning rainbow wheel.
Any advice?
thank you

Does Audacity crash if you try to record using the internal microphone and play back with the internal speakers?
– Bill

No it doesn’t

Nor does it crash if I record into Audacity with the Yeti , or just use the Soundflower add on - it seems to be the Aggregate that it can’t manage

Have you checked the aggregate device in Audio MIDI Setup? I’m wondering if you disconnected the Yeti mic that the aggregate device would fail? Something changed between your first recording and subsequent ones.
– Bill

Thanks Bill - I’ll try that and see what effect (will be a few hours - have to run a long errand at the moment)

Good evening Bill, and thanks for your patience
I’ve attached the three relevant screen shots (I think they’re the relevant ones)
And indeed, on this evening’s test run all went well. Bit of a mystery that…
Perhaps the lesson is to double check every setting just before lift off.
I’ll try again tomorrow and see if it holds.
Thank you
Screen Shot 2021-01-29 at 6.49.29 PM.jpg
Screen Shot 2021-01-29 at 6.48.05 PM.png
Screen Shot 2021-01-29 at 6.37.42 PM.png

Did a test run and everything worked fine until I pressed Stop
Then Audacity immediately crashed
Fortunately the recording was recovered by Audacity and could be saved, but that seems a bit dodgy as a way of having to do business all the time.
I did not take a screen shot of the crash message - do you need to see that? I’ll run it again and assuming it crashes again I’ll have something to show you.

I’ve been playing with this on my Big Sur Macbook Air. I’m using Blackhole instead of Soundflower, and an AT2020 USB microphone.

It seems (from two trials) that I can set up the aggregate device (consisting of the AT2020 and Blackhole) and get it to work once. On second try I get a PortAudio error or not sound at all.

I’ll continue to investigate.

– Bill

myself on the Yeti and the google call I made

It’s nearly impossible to record your live microphone and a chat call at the same time on one machine. Google Voice, Skype, and Zoom are actively fighting you. It’s their job to maintain perfect, total, absolute control of the computer sound pathways at all times. There is no “and a recorder” unless the recording is being hosted by Zoom, Skype, etc. That’s why those recording services are offered.

There was a forum post from someone who got the service to work only to have the chat program collapse the conversation and rebuild it in real time without the recorder.

There are certainly ways to do this with multiple machines, but nobody wants to do it that way.


So I’m a Windows guy, so I cannot help you with particulars of MAC and Soundflower, etc. but I had a similar issue with Audacity working sometimes and crashing sometimes. When I set Audacity’s sample rate (lower left-hand corner) to the same speed as my device it corrected the problem.

I hope this helps. :smiley:

Thanks Windows guy
I experimented with BlackHole just now, which proves to be stable after a couple of computer reboots, but zero phone input. Only buzzycracky noise, no voice, etc. I notice on the audio midi set up it indicates “no input” and “no output” controls for BlackHole. That might be an issue?
Anyway, for now it looks like I’m stuck with soundflower, which, when I restart the computer and make sure all the settings are correct, seems to remain stable for a single phone call.

Update on BlackHole as alternative to Soundflower: was trying to use 2 channel BlackHole and that really did not work. Then installed 16 channel BlackHole, followed the instructions for input and output in Audio Midi (such that Yeti microphone is the 17th and 18th channels). Proceed to Audacity. It takes me a while to realize I have to select 18 channels because of where the Yeti is in the track stack. Having selected 18 channels I press record, and crash. Press record again, and crash. Then it works on the 3rd try, with all 18 tracks present, which I leave alone (ie leave deleting the unused tracks until after completing the recording).

This experience very much mirrors what was happening in Soundflower.

It works, but is unstable, and crashes from time to time at the end of the recording such that one has to rely on the Audacity recovery to preserve the recording.

Kind of scary for radio interviewing, when it’s A Thing to get the folks on the other end of the line God forbid one would have to redo the interview.

Any thoughts anyone, on how to stabilize? Either in BlackHole or Soundflower?

Or is there some other way?


It’s nearly impossible to record your live microphone and a chat call at the same time on one machine.

Koz, I’d find it hard to argue with you - the “nearly” seems to be my experience - it does work but I do get the feeling I’m fighting the entire time


I also managed to get it to work… once. As you so aptly describe, it felt like fighting the system continuously. I would not be able to describe the steps to get it to work - it felt more like luck than a solid strategy. If I ever need to do it again, I’ll stick with Linux :wink: (It’s not “easy” to do on Linux, but there are a couple of tried and tested ways that work reliably).

As it turns out the Windows guy’s advice has made a big difference. I’m working on FM radio, so using the sample rate of 32000Hz is probably at the very edge of quality, but in doing this it is an infinitely more stable set up, and the station tech says quality acceptable.
Now, if I could just get rid of the clicks from peoples’ phones…