Here’s another happy Audacity user. Thanks for all the brilliant work.
Since my fresh installation of Linux Mint 15 (Olivia) Cinnamon 64 bit, I’ve come across some strange error while working with Audacity 2.0.3. I can’t make out anything from the computer logs (it might just stop logging because of the following error, perhaps).
I use Audacity for working on editing long interviews (mostly 2 hours in length). On my desktop, everything works fast and smoothly. But now, when I start working on any file, I notice that at a certain point I can still work in Audacity, but the rest of the Linux Mint environment stops responding. It DOES give mouse tips on items at the panel, switching workspaces using ctrl+alt+left also works, but I can’t use ALT+TAB or select different windows, for example a web browser or text editor.
Apart from some glitches (sometimes Audacity doesn’t respond, either) I can work on my audio file. If I wanna shut down Audacity, I have to do that by shortkey ALT+F4, using the mouse on the window does not work.
I considered it to be a kernel error, or something with the X-server, or imported settings in my hidden folders from an earlier install, but removing all hidden folders/settings did not help.
Perhaps someone does recognise this kind of behaviour?
I must say that this behaviour acts up at some points. After 10 minutes or so, most of the times, I can suddenly interact with other windows as well. Until it ceases to function again and the above described behaviour is back again. So it almost feels like waiting for a buffer to restore.
I don’t know where my posts have gone, but here I go again.
The above shown tab from the Settings screen shows the linux map /var/tmp/audacity-temporary (something like that)
I don’t have an option for changing buffers or so.
I changed the above mentioned folder to a new folder in my Home folder: /home/Audacity/. I considered maybe I did not have the rights as user to
put temporary files there, and I am pretty sure I can do that in my Home folder.
Alas, I just noticed that to problem continues to exist. I have trouble thinking what I could be. Still having the idea that it could be something like a buffer problem, for the problem does not occur continuously, but is ‘interrupted’ by a few minutes of time in which I CAN access other screens.
Good, that’s what it should look like, and so rules out one possibility.
For testing purposes you don’t need to do that. Just Save the open Audacity project somewhere that you have write permission, plenty of free space, and fast disk access (NOT a network or external drive).
Until a project has been saved Audacity will use the temp directory (as defined in that preference screen) to store temporary data (including any recording data and “Undo” data). Working with audio produces a lot of data.
If the project has been saved somewhere, Audacity uses the saved “_data” folder to store this data instead of the temp directory.
If there is some problem with reading/writing from/to the temp folder, then the problem should disappear if you save the project to a local hard drive where you have read/write access and plenty of space.
In order to combat the huge amount of spam that was being posted to the forum we have regrettably had to implement a “moderation queue”. This means there will be a delay before your posts appear on the forum. We aim to approve all legitimate posts within 24 hours (usually much quicker).
There are audio in/out buffers, but they are tiny (typically holding about 0.1 seconds of audio).
Disk write occur in blocks of 1 MB by default (still too small to account for the behaviour).
Tell us about your system specification - there may be some clues there.
The audio data is saved in “blocks”. By default, each block is a 1 MB file with a .AU extension.
I’ve noticed (while “extreme testing”) that Audacity has a serious problem with Swap. IF Audacity is trying to use Swap, then that could explain why the problem is occurring, but normally Audacity should have no need to use Swap at all. Could you try running Audacity while also running a system monitoring application (you may have “System Monitor” available as a “System Tool”). Look to see if Swap is being actively used while running Audacity - if it is, then we need to find out why and whether it is Audacity that is accessing Swap.
Interesting. I’ve been looking at the system monitor, and as I can see, it only uses around 665 MB of random access memory, not swap memory. Which is explained by the 1 mb blocks Audacity project are built from.
Could it have been the graphics card driver, perhaps? I don’t see why this would affect only Audacity, but I’ve changed it several times, now using a third-party closed driver for ATI Radeon, but I can now type this message and run Audacity at the same time. To me, it’s not an explanation, but perhaps to someone else?
I’m using fglrx-updates in stead of fglrx (2.9.010) or xserver-xorg-video-ati. Both of which I used beforehand (after re-installing).
It’s possible.
When possible, Audacity use a cache for the waveform display, but often the waveform needs to be updated, Updating the waveform is pretty heavy duty stuff - sometimes taking longer to calculate than the actual audio processing. I’ve not much experience with video driver issues on Linux as I’ve had few problems in that area (I’ve mostly used Intel or NVidea graphics on Linux).
The only way that I can reproduce the issue is with Nyquist - normally Audacity uses very little RAM on my machine. With reference to Nyquist I think it is already on bugzilla, though I suspect that the problem goes beyond Nyquist (suggested by the problems that occurred when we had the option to use RAM as the temporary data location).
