We have been using Audacity (Windows 10) for about a year to repeatedly mix serval audio files together to create a database for our signal separation research. This database consists of the desired (clean) audio, babble (noise) audio, and the respective mixture audio. We chose to write a MATLAB (Python) script to do this as our processing will also be done in MATLAB. When we tried creating approximately 6 mins of data, everything worked fine. However, as we stepped up the amount of data to 12 hours, Audacity crashes after ‘Normalizing’ about 8 mins of the clean data (we randomly Normalize the clean data to -5dB, -10dB, or -15dB before mixing with the babble). When using v3.2.2 we get no error message from Audacity (it just crashes); with v3.2.1 we get the problem details shown in the following text file:
Problem Details.txt (237 KB)
Thank you for taking the time to read about our problem. Any assistance or advice on how to proceed will be greatly appreciated.
I tried using an earlier version of Audacity and now it seems like I cannot get to open a pipe between MATLAB and Audacity. I am getting the following error:
Thank you for your responses, Steve. So, while using an older version (v3.1.3), I was able to open a pipe between MATLAB and Audacity. I am using a Python virtual environment and when I open Audacity inside of the environment, I cannot open a pipe; when I open Audacity normally, I am able to open a pipe. However, even with this older version, I still get the above read error. I will try v2.4.2 as you suggested and get back to you.
In case it’s important / relevant to the task in hand, note that Audacity 2.4.2 uses the old “AUP file + _data folder” project format rather than the new SQLite based “AUP3 file” project format. Audacity 2.x cannot open projects created by Audacity 3.x, though Audacity 3.x “should” be able to open projects created with Audacity 2.x.
Hey Steve, I have a quick question. What happens to the pipe when you close the Audacity project? When you close a project and the new (blank) project opens, can the previously-existing pipe still be used to send commands?
I’m guessing no, but I rarely use Windows, and named pipes are implemented differently than in other OS’s, so that’s just a guess.
On Linux (the OS that I use), the pipe is created by the server side app (Audacity), and then the client side app (Python) can connect to it. If either side of the pipe closes, the connection is broken. Even after closing both ends, the pipe still exists (rather like a zero byte file in the .tmp directory) but the ends of the pipe are not connected to anything.
If only the client app (Python) is closed and Audacity remains open, then the client app may be restarted and it will be able to reconnect to Audacity.
If only the host app (Audacity) is closed and the client remains open, then restarting Audacity will NOT connect to the client. The client must be restarted after Audacity has launched.
I recently updated to v3.2.3 and now I get a slightly different reason for Audacity crashing; the program says there is an exception stack overflow. It seems that with each (or some) calls to pipeclient, my code causes Audacity to generate an exception. I will have to check each command I write to the pipe to see which are responsible.
To Steve:
Hey Steve. Is there any way to see Audacity’s exception stack? I think Audacity can raise an excepion but continue to work anyway (without explicitly signalling that an exception has occured), which means I may have some difficulty in telling which commands cause the exceptions. Maybe if I cannot see the stack, there may be an option to get an alert for every exception that occurs? Please tell me if I am making sense here, lol.
To debug Audacity, you would need to build a debug version from the source code.
I’ve not built on Windows for a long time (I use Linux), so I’m not able to help you with this other than pointing you towards the current documentation.
Thank you so much…I’ll definitely give it a try! Also, I was just thinking that maybe I could read from the pipe to see if the exceptions are being sent there…if they are, I could try to debug using that info. I will be sure to give you an update on how things turn out.
So I tried building Audacity on Windows using cmake and VS 17 but there was a problem with opening the .sln file to do the build. I will have to try an alternative like monobuilder for the build phase.
I have a really silly question to ask though. Will trying to select all the tracks in a project raise an exception if all the tracks are already selected?
They are indeed similar…one with a macro while the other with scripting but essentially the same error. Not sure if this will be useful: I am back to getting the exception_ access_violation_ read error but I’ve managed to make some progress (I’m not entirely sure why though).
One of the things I did was to add pauses to my code to allow commands to complete (waiting for a response) before sending another command. I also tried deleting the old audacity.cfg file to reset the preferences (two preferences, including no warning when saving empty projects, were redone out of necessity).
The outcome was that Audacity ran for a significantly longer time (more data was produced) before crashing. It still crashes though, so the search for a proper solution continues.
That is very plausible…at the moment, I am checking to see if adding more pauses between commands will give Audacity the time it needs to execute without flooding the pipe.
Are you reading from the FromSrvPipe pipe, or only writing to the ToSrvPipe?
I’m not sure exactly how this works, but I believe that Audacity sends a bit of data to the “FromSrvPipe” each time that you send a command, so my conjecture was if your script doesn’t read from that pipe, its buffer will eventually become full.
Recently I started waiting for a response from the FromSvrPipe pipe, then reading that response, before sending another command across the ToSrvPipe pipe. That seemed to have lengthened the uptime of the pipe.
