Go > Go To Folder >
Pick Audacity
Audacity Files
Those are the only ones I know about. I don’t have multiple users on my machine.
Besides the obvious problem of no experience with your exact selections of devices and software, you could have something actually broken.
Did you try a different USB cable? We have had recent noise and distortion problem get cured by changing the cable.
We have a pretty good track record, but the forum doesn’t always pull everybody out of the dirt.
Koz
Thanks boo coo. This is more helpful that you might think. The file there named “cfg” looks like it has some preference stuff. I’ll dig. Interesting that your note does not show a cfg file. I’ll see what happens if I hide mine.
If you have a line to developers, please send a gentle note suggesting that preferences make more sense as a per-user feature than as per-host. One user per host is a Gates mindset. Even windows is past that now.
Also there is a file named lastlog.txt. It’s from a run last evening and has a boatload of notices about not being able to find some runtime libraries. I’ll see what I can learn from that. Not finding a runtime library would be a reason to crap out quickly, which is what I often see. But other times it will get started and simply not see any input (in a way that rescanning does not fix).
I can’t use a different USB cable because it does not disconnect from the UCA222 A2D device. But I get some confidence that it’s delivering a signal because the mac itself has a crude input level meter in System Preferences–>Sound. That meter moves while Audacity’s does not. But in general that’s a good thing to check. I’ve seen many vexations turn out to be cable problems, and it’s often not something we think of soon enough.
Digging around I find no effective difference in how we install. The only real difference is you put a link in the dock and invoke the program with that, and I run it by its actual name in /Applications. That ought not matter, but who knows what’s behind Apple’s curtain.
I was wrong. You do too have a cfg file. For some reason stopped noticing its whole name.
Running without mine only just created a new one that differed only a little:
sofa:8> diff Xaudacity.cfg audacity.cfg
447,448d446
< [ActiveProjects]
< 1=/Users/jerry/Library/Application Support/audacity/SessionData/New Project 2023-09-09 15-49-34 N-1.aup3unsaved
sofa:9>
This looks like the only difference is the old one remembered where some unsaved stuff from a test landed. I can’t see how that would matter for the problem of not seeing USB input.
From fuzzy memory, that’s one of the “Start Over” recommendations. Trash that file and start or restart Audacity.
One of the cautions as you troubleshoot is to note any change in the symptoms, not just whether or not your particular problem clears up.
Koz
So far you’ve been inspecting the record process and technique. Does the playback work? Open up or create a short sound file in Audacity and see if the playback systems and services work.
Koz
Maybe closing in on something significant.
On a mac there’s a small area on the right end of the dock where it puts links to a few of your most recently run programs. These are in addition to the programs to the left of those that are pinned to the dock by having been put there deliberately. Programs can be executed from there, as you do when you move a link to Audacity there. If you’d run it some other way first, you’s see your link got there on its own because of that. But it would age out of its spot there if you ran other dock non-residents before running it again.
When I invoke the program from a dock link, it starts up but does not see its USB input. AND lastlog.txt gets a blast of lines about not finding runtime library entries.
The same thing happens if I start the program the canonical mac way: Use Finder to navigate to /Applications and click on the top-level package name “Audacity.app”. (I don’t remember. Maybe the “.app” part of the name is visible because I changed a default long ago. I do things like that because I like knowing what I"m doing.)
The other way of running the program that worked sometimes, but never for long, was to use a terminal to do:
open /Applications/Audacity/Contents/MacOS/Audacity
When that fails it just craps out quickly. I don’t see anything in lastlog.txt with a timestamp that would connect with this.
However, if I get Finder to look inside the package and navigate to Content/MacOS and click on the name “Audacity” I get a program that runs and sees its USB input.
So this evening, anyway, I have one way to make this work.I have other ways that the program will start up but not work. The clues for those cases are the messages in lastlog.txt about not finding runtime library stuff. It seems very odd to have a problem like this running something the canonical way that was installed the canonical way. It looks like something like a LIB path spec might be missing or incorrect. I’ll see if I can attach some of that log.
lastlog.txt (3.5 KB)
Yes, when record works playback does, too. Playback of a .wav I had lying around from playing with vlc when I was despairing of audacity worked fine, too. Kind of interestingly I tried a ringtone (.m4r) and Audacity said I needed to add an optional library for that. Not sure if I’m going to care enough. I’d only tried that file because it was at hand, so to speak.
I’d be much more interested if playback worked when recording didn’t.
Playback and Record can be separate things. I have preformed an event where Audacity Playback and Audacity Record were different shows.
Does your UCA222 USB light come on? Yes, I see the USB cable is bolted on.
What are the connections to your MBP? How did you get your UCA222 USB-A connection to work?
Why did you buy the UCA222 instead of the UCA202?
Koz
In a run where it does not see the USB input and produces all the runtime library errors I record nothing. I don’t know that recording doesn’t “work”. I know only that when I try I see flat lines in the display. It seems to be recording the “nothing” that it’s reading.
Yes, the UCA222’s LED lights up when I plug it in to the Mac. I have a few USB A female to USB C male adapters. Picked them up years ago when Fry’s was still a thing. They’ve been very handy during the transition.
I got a 222 because it was the version saw first. Later when I saw there were 2 versions it looked like the only difference was the color so I thought it didn’t matter. I think it’s only chance that I ended up with a red one.
I got a Behringer U-Control because it was by far the cheapest solution to my problem and I didn’t want to spend more for what I expected to be a short simple project.
Another development:
After learning yesterday that audacity keeps some state in ~/Library/Applications Support I got to thinking that my troubles sure seem like some persistent state outside the program itself might be horsing things up. So I changed the name of the audacity directory there and and the name of the then current /Applications/Audacity.app and did another installation from the same dmg.
The result of this fresh installation (so far) has shown none of the problems that have troubled me with Audacity since I started using it a couple weeks ago. It looks likely that there was something in the application support stuff from long ago that does not play well with the current version. Maybe later today I’ll root around and see if diff’ing things in the old and new directories turns up something likely. Right now I’d like to get some rest and think about other thing for a while.
Thanks much for your advice. Pointing me to the app support stuff was a big break. I don’t know exactly what the problem has been, but it looks like I now know how to make it go away.
My problems seem to have been the result of what happens if you don’t use audacity for a long time and then let its update get you right. It looks as though “cfg” things will just accrete incoherently if you do that. Here’s the difference only in the number of lines in the accreted mess compared to a completely fresh installation:
sofa:3> wc -l audacity.cfg …/audacity/audacity.cfg
448 audacity.cfg
247 …/audacity/audacity.cfg
695 total
sofa:4>
Perhaps the most startling thing in the messed up cfg is its first line:
Version=2.0.1
A “diff” of the two files is 330 lines, by far most of which are in the troublesome file. I don’t know enough about what most of it means to see if there’s one or a few particular things that caused my problems. To me it’s just a mess. Wish I’d known to look there sooner. But being an old-timer I expected things like this to be in a “hidden” file or directory in my home directory. When I didn’t see either of those I didn’t know where else to look.
The bottom line is, I think, that an installation guide ought to advise that if you have not updated for while, consider moving your cfg out of the way first and restoring your preferences the hard way.
Glad you sorted it.
You may be a victim of the Great Audacity Leap to 3.0.0. That was the one where they abandoned the split file format and made an enormous number of other changes.
The “Hero” old version is 2.4.2. I still use that one. You may have gone back a bit too far. 3.0.0 and 3.0.1 lasted about fifteen minutes. They got better after that. 2.0.1 would have been the high voice and wide-eye rush patch for 2.0.0.
Koz
It’s only fair to give you some of the credit, Koz. I’d never have found what was causing the problem without your advice. Whatever the references to “points” I see here mean, some should come your way for this.
In retrospect I think the reason why I sometimes moved on to different failures was because occasional re-installations screwed up my audacity.cfg file differently. That sent me down a new rathole each time. This has go to be one of the oddest computer problems I’ve looked at.
That can cause problems. There is no shortage of people with opinions on what should be in the manual. Where do you stop? How far back do you go?
You are the odd duck. I think there are zero point zero zero other people trying to upgrade from Audacity 2.01. Keep in mind that my machines cheerfully run both 2.4.2 and 3.3.3 with no apparent problems.
Thanks but you did all the legwork. I just pushed ideas here and there.
One of the early electronics magazines had a techie with a “Tough Dog” column. The writer described electronic failures that rolled right over normal repair people’s efforts to fix them and why. I hung on every word.
That’s where I got some of my odd repair techniques. If somebody wrote me a big check, how would I intentionally create this failure?
Never say, “This can’t possibly cause the failure, so I’m not going to check it.”
Never microscopically regard the problem to the exclusion of the rest of the machine or system.
There’s a couple of other handy tricks, but you get the idea.
Enjoy,
Koz
This topic was automatically closed after 30 days. New replies are no longer allowed.