I am recording acoustic piano miked with two Rode M5 connected to a Steinberg UR22 audio interface. A USB cable connects the UR22 to my HP Z-Book. Everything works fine for a minute or two, then recording stop abruptly with the warning “Recorded audio was lost at the labeled location.” This is a consistent problem with my setup. I have excluded the Audacity temp file folder from virus scans. The problem persists. There is plenty of audio signal coming out of the UR22 audio interface. What, exactly, Audacity is receiving is another question.
There appears to be a problem with the UR22/Audacity combo. (btw, the same problem occurs when I use WavePad). Cubase AI/LE has its own issues, but this is not one of them. I suspect the UR22/Audacity combo is the problem because a Blue Yeti mike performs flawlessly, if you can tolerate the poor sound quality. The latter also seems to rule out a bad USB connector on the laptop, and the fact that Cubase does not drop seems to rule out the USB cable as the culprit.
Are users out there using a UR22 with Audacity without this problem? I am using the Yamaha Steinberg ASIO driver. Is the driver the problem? Is additional processing required between the Yamaha ASIO driver, Windows, and Audacity that introduces enough latency that Audacity senses a signal interruption and halts recording? If so, what is the remedy?
We haven’t seen this message reported on the forum for a while. Does this happen with Audacity 3.1.3?
Due to licensing compatibility issues, Audacity cannot ship with ASIO enabled. You can experiment with MME, Drect Sound and WASAPI to see which gives you the best results. Does a slower sample rate fix the problem?
Thank you jademan for you very helpful response. I visited the Audacity ASIO Interface Page and will go with the Steinberg ASIO SDK solution. It should be the most direct remedy. I have a 40-year carrier behind me with FORTRAN, c, c++, C#, T-SQL, python, myriad web services, etc In retirement, it will be entertaining to dust off those skills and build my own (personal) copy of Audacity. The only drawback is I will need to rebuild if I want to keep up with future releases.
Hi jademan. I made some progress but have problems with conan. CMake message is: Conan: checking conan executable
Conan: Found program CONAN_CMD-NOTFOUND
CMake Error at cmake-proxies/cmake-modules/conan.cmake:813 (message):
Conan --version failed=‘The system cannot find the file specified’
Call Stack (most recent call first):
cmake-proxies/cmake-modules/AudacityDependencies.cmake:14 (conan_check)
CMakeLists.txt:206 (include)
Thoughts? Also, is it appropriate to continue this discussion on the current thread or should I switch to a different forum? Am I too much in the weeds?
Right. Well, I should have warned you - compiling Audacity is not for the faint-of-heart. The best place to ask questions about compiling Audacity is here: Audacity dev on the #compiling channel. You could browse through there and see if anyone has had an issue similar to yours. - Or just post your question.
To Mr. Kozikowski: But a bad USB cable seems to be ruled out by the fact that Cubase works without this problem (using the same USB cable). It is something of an Easter egg hunt without a doubt. Prawdziwie.
Yes, but you have two different programs that fail. That points to different program’s reaction to a bad/ratty data stream.
Cubase works without this problem
I bet Cubase is better at covering it up. I also bet if you look hard enough, you’re going to find tiny glitches, holes, or missing sound in the Cubase show.
Doesn’t have to be the cable. It can be the sockets too.
It is also possible that the UR22 is set to 48000 and Audacity is set to 41400 bps sample rate. In this case simply changing the Audacity project rate (lower left-hand corner) could correct the issue.
Another possibility is that you are trying to record and monitor the audio on the UR22 simultaneously. While this should work in principle, it may be easier at first to monitor on the PC’s speakers.
BTW, I was doing a little digging and found what I believe are the current Audacity build instructions here:
However, these instructions will build the current alpha (development) version. To build the version corresponding to 3.1.3, I believe you would replace the git clone instruction with:
Hi jademan. I successfully CMake’d my project and built it in VS. It is the alpha version. It runs, records, plays back – all is wonderful – except no ASIO in the driver list, so I am not quite there yet. Nonetheless, I am quite pleased to be well along the yellow brick road. There is no reference to the Steinberg ASIO SDK in my VS project so my next task will be to learn why. BTW, I did go to the Discord! site but my account seems to be locked for now. Perhaps it flagged a 1950’s birth year and rejected me? LOL.
So within BUILDING.md (see my previous post), you will find the following:
Building with ASIO support on Windows
To enable ASIO support, please select audacity_has_asio_support=On in CMake after the initial configuration and then run select Configure again as described above. ASIO is only supported on Windows and only for 64-bit builds.
Yes, I think there is a rule that you must have been born after 1999 to use discord. Regardless, if you are still locked after tomorrow, let me know and I’ll make an inquiry.
My build of 3.1.3 was going well up to a point. v 3.1.3 wanted VS 2019, not 2022, so I uninstalled 2022 and installed 2019. There were some problems with conan versions so, as per the CMAKE error/suggestion, I edited the conan.config file with the flag ‘revisions_enabled=1’ in the [General] section. CMAKE chugged along until the very end until a fatal error occurred, along with the message:
WARN: wxwidgets/3.1.3.1-audacity: requirement expat/2.2.9 overridden by your conanfile to expat/2.2.9@audacity/stable
WARN: libpng/1.6.37: requirement zlib/1.2.12 overridden by wxwidgets/3.1.3.1-audacity to zlib/1.2.11
WARN: flac/1.3.3: requirement ogg/1.3.5 overridden by your conanfile to ogg/1.3.4
WARN: vorbis/1.3.7: requirement ogg/1.3.5 overridden by your conanfile to ogg/1.3.4
WARN: libsndfile/1.0.31: requirement ogg/1.3.5 overridden by your conanfile to ogg/1.3.4
ERROR: 404: Not Found. [Remote: audacity]
The 'libmp3lame/3.100' package has 'exports_sources' but sources not found in local cache.
Probably it was installed from a remote that is no longer available.
CMake Error at cmake-proxies/cmake-modules/conan.cmake:631 (message):
Conan install failed='1'
Call Stack (most recent call first):
cmake-proxies/cmake-modules/AudacityDependencies.cmake:255 (conan_cmake_install)
cmake-proxies/cmake-modules/AudacityDependencies.cmake:274 (_conan_install)
CMakeLists.txt:541 (resolve_conan_dependencies)
So, that is where I am at the moment. I smell success near but am not quite there yet. Will try some more tomorrow when I am fresh.
Koz:
I tried new USB cables but they did not fix the problem. Well, it was worth $9 to find out.
SUCCESS! I have build the current alpha 3.1.3 version with Steinberg ASIO support and my recordings no longer stop unexpectedly. There are a few skips here and there which likely can be corrected with some adjustments to my settings. Sound quality, while not Deutsche Grammophon, is good. The performer (me) needs more practice to improve his rough spots, and that is OK. It is the sole purpose of recording myself.
I decided not to fight the fatal CMAKE error I encountered using the stable 3.1.3.1 source and went back to the alpha version with which the MAKE file was happy.
Jademan: If you want any additional feedback from me let me know and I will document my experience in DISCORD (once I get in–I am working with Discord support at the moment to accomplish this).
Regardless, if you are still locked after tomorrow, let me know and I’ll make an inquiry.