Trying to make a UCA222 work with a 2023 MacBook pro running MacOS 13.5.1 has been frustrating. A good clue came from a blog post about a similar problem with mic input. It said to start Audacity using “open /Applications/Audacity/Contents/MacOS/Audacity”. That produced a popup asking to affirm that you want to open the mic. So apparently the mic issue is a permission problem.
I tried this. It got me that popup about the mic, which is weird because the mic is not my input. But I agreed to open it anyway, and that didn’t help my USB problem. Reasoning that there’s a permission problem with USB, I next tried that “open” command prefixed by “sudo”. Was asked to open the mic again (that must be a bug), and this time Audacity started reading the USB device!
Running Audacity as root is a very bad idea, but I see no other way to make the UCA222 work. I’d be delighted to learn better. Thanks.
Windows guy here. Both Windows and Apple require that you give Audacity “microphone” permission before you can do recording of any kind. I don’t think you need any kind of root permission, but then again, I am a Windows guy.
For MacOS permissions, see: Control access to the microphone on Mac - Apple Support
Thanks. I could see it was not getting input from the mic. What makes me wonder is how if it can be made to ask for permission to use the mic it can’t also ask for permission to use a USB device when there’s a problem with that. If it did I’d be less bothered than by running the whole process as root.
The real underlying problem seems to be how permissions are set on this version of MacOS. I’d fix it that way if I could find the right place to do it. As an old unix guy I’d expect that to be something in /dev that maybe starts with the letter ‘U’. But Apple thought different.
The order counts. If you run Audacity and then plug a USB device in, Audacity won’t see it. Transport > Rescan Audio Devices.
Or plug the device in and then start or restart Audacity.
Koz
Thanks for the interest. I am aware of that potential problem and could not be more certain that it is not what has vexed me in this case. Audacity shows that input is expected from “USB Audio CODEC”, a choice that would not be available if it had not found that device. In addition, it’s difficult to see how running Audacity as root would work around a problem like that.
The imprudent kludge of running as root almost certainly indicates a permission problem. If I understood what apple has done with the old fashioned /dev I could change the troublesome permissions and run a little more safely.
But did you actually check it? We are warned against the New User Error: “This can’t possibly be it, so we won’t check it.”
This particular series has two actions: Possible security lockouts and the order of appearance. You gotta hit them both. I agree. Running your production session as root is not desirable.
Koz
First, let me say that I appreciate your replies. But I must insist that I have checked this. The need to rescan is just about the first thing I learned about Audacity. I’m not one of those people who never makes a mistake, but I have not made that one.
I am a software developer with experience going back to the 1970s. Just about half the bug reports I’ve fielded were mostly misinformation, so I try to be careful when composing my own. Again, I’m not beyond getting something wrong, but the point you raise is not what’s wrong with how I’m trying to use Audacity.
For the record, I’ve just installed MacOS 13.5.2, which made no difference for this. Still need to run as root to get Audacity to use USB input.
I just tried this with my Macbook Air, 2020, M1, macOS 13.5.1. Behringer UFO202.
On plugging in the UFO202 a system dialog appeared asking “allow device to connect”.
Then started Audacity 3.3.3. Changed input to USB Audio CODEC, Recording channels: 2. When I hit record I got the “allow Audacity to connect to microphone” dialog. To Apple, any audio input device is a “microphone”. This may be the first time I tried to record on the Macbook with Audacity 3.3.3 (I keep many versions of Audacity on my machine and give them unique names, so it may have been the first time I tried to record with “Audacity 333”.)
Recording then proceeded as normal.
It is weird that you were asked twice to give Audacity permission to use the microphone. Does that happen every time you try to record (whether you start Audacity normally or as root)?
There doesn’t seem to be any significant difference between our machines, unless yours is an M2 and that makes a difference?
Is there someone reading this who could test with an M2 Mac and a USB audio interface?
My 2023 MacBook pro says it has an M2 “pro”. I’ve not paid enough attention to know what the “pro” denotes. To me it’s just a qualifier that Apple is especially fond of. It would seem peculiar to me if this difference in our CPUs mattered for this purpose, but that’s over my head.
As far as I’ve been able to learn the 202 and 222 differ only in the color of the plastic shell. In fact if you look carefully at the back of a 222 you see it says it’s a 202. They did not bother to get a new die for the injection mold when they changed to red shells.
When I invoke Audacity the normal way I get no dialog and it does not record from USB.
If I invoke it this way:
“open /Applications/Audacity/Content/MacOS/Audacity”
I get the popup asking for permission to use the mic even though I’ve specified USB AUDIO CODEC as the input (and made sure t rescan if necessary), and Audacity will record nothing.( Earlier on jademan replied that Audacity always wants to ask about the mic. Apparently this reaches me only when invoking the program from a terminal with the “open” command.)
If I invoke Audacity as:
“sudo open /Applications/Audacity/Content/MacOS/Audacity”
I get no dialog, and recording works as it should. The lack of dialog this way makes sense because when running with UID zero you pretty much get to do whatever you ask for.
I think that is a misquote, but I am used to the abuse. 
As @billw58 said:
To Apple, any audio input device is a “microphone”.
Again, I am a Windows guy. If the system requires root access, perhaps something in your installation is messed up. I vote for uninstalling the app and downloading a fresh copy from here: Mac | Audacity ®
And use the installation instructions on that same page.
jademan: I downloaded a fresh copy of 3.3.3 and installed it. The result of this trial is confusing. First thing I noticed is that the mac won’t use the new copy until I try to invoke it by clicking on the top-level package name (/Applications/Audacity.app). That does not work, but it provokes the popup about approving something downloaded from the internet. Until that is propitiated MacOS won’t use the program.
After that I can run the program with the open command in a terminal as:
open /Applications/Audacity.app/Contents/MacOS/Audacity
Very encouraging to get it going without “sudo”, and input levels showed it was getting stuff. Recording worked fine. I started getting excited, but the sky soon fell.
Pushing it, I quit Audacity and started it again the same way. It still worked. Played with a while, and tried to restart it again. Now it would not even start. No indication why. The open command eats the exit code of the program. Trying to see what’s the matter by running the program directly (./Audacity) got a quick exit with an error code of 255. Don’t know if Audacity means anything by that. In old days 0xff was just generic bad news. It was getting late, so I decided to look at this in morning.
Today I installed another copy from the dmg I got last evening. This one is surviving a few restarts, so maybe I was too tired to get thing right last night. I still cannot invoke the program from the top-level package name, but the fully qualified name of the executable file as an argument to “open” works. I’ll write a script to make that a little less clumsy. By the way, I’m not seeing any prompts about using the mic now.
The installation that I’d been using until yesterday evening was the result of whatever update happened automatically when I fired up Audacity for the first time in a long time a couple weeks ago. I compared the executable from that update with the new one using the unix cmp command. That showed them byte-for-byte identical, but the installations likely diddles with more than only those files, so I’ve no idea for what else to look at.
I feel much better having a way to run without su’ing. I’m still anxious about how the installation stopped working after a little while last night. I’ll be watching for that. At worst I’ll keep the dmg around and do new installations when I want to use Audacity, but I’m encouraged.
Thanks for the advice.
Me again. A few hours later the installation that was working no longer does. The input level meter in System Settings–>Sound shows something coming in from USB, but Audacity’s input levels do not move. (For the record I’m doing plenty of gratuitous rescans just in case.)
Another fresh installation works. I still need to invoke it from a terminal with an open command. Still don’t need “sudo”, which is a much appreciated improvement. It isn’t prompting about the mic anymore. So how long do I get per installation?
Must say it looks like something about MacOS, or at least my copy of it, does not like what I’m doing. Sure wish there was someone else out there with a 2023 MacBook pro trying to use Audacity to read from USB Audio CODEC. It would help to know if I’m uniquely hosed.
I have a running joke about a Technology Threshold. You have achieved The Threshold when you improve something so much it stops working.
That’s another semi-joke. People who know how to sudo tend to have entertaining, unusual, and unique problems.
Koz
I’ll swear to the deity of your choice that the only use of sudo on this computer has been for the “open” commands trying to make Audacity work. And I have not used it elsewhere for quite a few years. I’ve been a standalone programer (boot, kadb, vmunix, …) developer. I’ve seen the damage done.
About that Threshold: So much software is so bad that anything any good gets extended and distended to the point of breakage.
I wasn’t pointing at that particular command or series of actions. Just knowing that you might want to “grep” something later might lead you to make slightly different setup choices than, say, your mum, assuming she isn’t a Developer.
And speaking of Developers, what are the chances of an Audacity Developer trying 333 on a fifteen-minute old M2 MBP. I’d go with zero. You may have discovered a bug-adjacent failure.
We could take this in the subjunctive. If more people had put Audacity on this version of MBP, more people would have turned up instabilities.
Koz
Jerry, as I am a Windows user, you are have exhausted my level of understanding on this issue. Perhaps as you suggest, some such pro will comment here.
This isn’t likely, but it’s worth a shot. Are you using drives other than your internal drive? Audacity hates external, USB, network, Internet, and Cloud drives.
Audacity thinks it should be able to do its most critical, difficult jobs on whatever drive it can see. Picture Audacity trying to perform overdub and critical real time musical timing with an iCloud drive in Schenectady.
Worse than just failing, Audacity becomes unpredictable and unstable. Much like what’s happening to you.
Koz
Feeling reason to think one is uniquely beset is not a good thing for one’s emotional wellbeing.
No external storage at all while doing this. Backup device disconnected. Onboard SSD only choice, which really ought to be about as good as it gets for regular folks.
OK. Under influence of fresh Starbucks®, I went back through your postings (It’s late morning in LA, land of fruits and nuts).
This is an illustrated history of how I install Audacity.
I download the .dmg (disk image file) from an approved vendor. I keep a closet of .dmg files, each parked in its own version number folder.
Please note I’m obsessive enough to never use spaces in file or folder names. Double click the .dmg file and it opens an installer graphic.
I admit, this took me completely off-guard the first time it happened. What the frog are they trying to get me to do? Drag the icons. Drag the earphone picture onto the folder picture. A very Mac thing to do.
But that’s not what I do. I create a custom folder in Go > Applications…
… and I drag the icon into that. The system seems perfectly happy with that and I’m sure it’s going nut-house in the background setting all it’s application files, folders, and settings. We should remember an Audacity install picks up settings from previous installs. This is good and bad depending on whether or not you were trying to escape a bad install.
When it gets done shuffling and crunching, I open the folder and drag the “program” app icon down to the desktop toolbar. It doesn’t actually drag, but it does create a handy icon down there.
You can get rid of this icon at any time by dragging it to the trash.
From that point on, I summon the toolbar (it pops up) and click on the headphone. Audacity launches.
The install process creates a “drive” on the desktop.
You can drag that to the trash. It’s job is finished.
I’m guessing you started using Terminal commands somewhere in the process instead of following the graphic trail.
What happens if you follow the pretty pictures?
Koz
Depending on what you mean by “LA” (an elastic concept) we’re four or five hundred miles apart. I’m in the state capital. If you ever have business up this way, get in touch and I’ll pop for some refreshing beverages.
No, I did not use terminal during installation. I used it only to try to get a conventionally installed Audacity to run.
Because I’ve been struggling only with version 3.3.3 I have only one dmg, one that I grabbed from the project web site a few days ago. I keep different installations of that apart by changing their names in /Applications. It sounds weird to have multiple installations of the same release, but fact is that they have behaved differently. This is troubling and likely caused by something other than Audacity itself, seems to me.
By “desktop toolbar” I assume you mean what Apple calls “the Dock”. Dragging stuff in and out there is normal Apple activity. You can also right-click (touchpad 2-finger press) on an item there to select “options” that include “remove from dock”. (After a couple decades I’m getting used to some of this GUI fiddling. Really only got interested in Apple’s hardware after they started using FreeBSD for their kernel.)
The dmg you see on the desktop during an installation is the mount point of the (pseudo) disk. If Finder were open at the time you’d see it in the left margin there under “Locations”, along with something to click to “unmount” it. Doing that would make it disappear from the desktop same as dragging it to trash.
I’ll try following your pictures later today. I don’t see anything obvious in your way that should produce a different result, but there’s things going on I don’t know enough about. Had to get back to some of my regularly scheduled programming for while, but didn’t want to appear disinterested for too long. Appreciate the help.
A question: do you know where Audacity squirrels away preferences? I expect those to be per-user and in a “hidden” (that is, having a name that begins with the period character) file or directory in the user’s home directory. I see no likely entry in my home directory.