Hey. I have already been on the IRC about this, but I thought I would put it here as well.
I have an issue with Ardour crashing sometimes after about 1 hour of recording. We thought it was ram at first, but I upgraded the ram and watched top while Ardour was running. I never ran out of ram and the app only ever showed 100mb or so of memory usage.
We thought that the drawing of waveforms while it was recording might be the culprit, and I thought that had solved it as I was able to go for 2+ hours several times with that turned off. But last night, it crashed with that turned off.
The app simply goes away. It does not give an error message, it does not behave strangely before it dies, it just dies.
I know that this is being worked on, but if any of you have experienced this and found a workaround, I would love to hear it. Having to take breaks every 30 minutes to start my DAW over again so I don’t lose work isn’t really ideal for my podcast.
To be exact do you mean:
- Ardour crashes after 1 - 2 hours of continuous recording
- Ardour crashes after it has been running for 1 - 2 hours but only recording some of this time
What version of Ardour do you use ? Have you experienced this problem on just one computer or several ? What soundcard do you use, is it USB, Firewire or PCI(e) ?
One thing that comes to mind is the file format you are using. Maybe it’s maximum length gets exceed ?
Have you tried lowering the bit depth of the recording to 16 bits ? You can find the option in menu “Session / Properties” and there on the tab “Media”. You could also try the other file formats found there. This setting needs to be changed every time a new session is created as it always defaults to 32 bits.
I’ve always thought the the default recording depth of 32 bits is a bit overkill and also makes the computer work harder than necessary. My day-to-day soundcard can only output max 16 bits anyway
When I pull the file back up, I have the audio almost all the way up until the app closes in most cases, but once time I had nothing. It doesn’t seem to crash if it isn’t recording, I tried just leaving it open with jack running and it just sat there, open, pretty much forever. I had the same exact issue on a much much more powerful machine with massive ram and 3x ssds in raid, so it’s not system resources.
I am using an m-audio m-track eight and cadence/carla for jack routing. The problem first appeared when I updated to 4.2 from 3.x, I forget what the exact version of 3 I was using but on the same hardware I never had any crashes.
We thought it might be some power setting initially, but the machine does not turn off the screen or throttle the cpu or any other such thing after an hour, or at all, as it is a single purpose machine which is only powered on when we record, and the power settings are set accordingly.
I will take your advise on the 16 bit thing however, you are right, there’s really no reason to record my podcast in such high quality. Waste of disk space and since it’s writing 8 tracks to disk at once, lowering the “resolution” of the audio cannot hurt.
Please try using the “core file” mechanism described here http://ardour.org/debugging_ardour so that we can see a stack trace of the crash. It is only way to get an idea of what may have caused it.
oh, that’s something i can do for sure.
I have the page bookmarked. I will run this tomorrow while I do some chores around the house.
I don’t understand much about C debugging, but could the crash be related to reading peak data information ? That would explain why the crash comes later when bit depth is 16 bits compared to 32 bits and I assume the stack trace tells Ardour was trying to read peaks in thread 8 while it crashed.
Then again I don’t claim to understand the debug information
I upgraded to Ardour 4.4 and let two of my computers to record the whole night (8 hours). There were no crashes
On one computer I had selected Wave-64, 16 bit integer and on the other Wave (4GB size limit), 32 bit floating point as the file format.
The first computer os is UbuntuStudio 14.04 and the other is Gentoo.
I guess I must confirm your finding. Last night I selected an 8 hour range on Ardour timeline, started recording and went to bed. When I woke up in the morning Ardour had crashed.
Unfortunately I did not enable any debugging. UbuntuStudio had a window open that said:
Sorry, Ubuntu 14.04 has experienced an internal error.
ardour-4.1.0 assert failure: ardour-4.1.0: cairo-surface.c:928: cairo_surface_reference: Assertion ‘((*&(&surface->ref_count)>0)’ failed.
__assert_fail_base (fmt=0x7f7a617302b0 “%s%s%s:%u: %s%sAssertion `%s’ failed.\n%n”, assertion=assertion@entry=0x7f7a671a38e0 “((*&(&surface->ref_count)->ref_count) >0)”, file=file@entry=0x7f7a671e3828 “cairo-surface.c”, line=line@entry=928, function=function@entry=0x7f7a671e5210 “cairo_surface_reference”) at assert.c:92
__GI__assert_fail(assertion=0x7f7a671e38e0 “((*&(&surface->ref_count)>0)”, file=0x7f7a671e3828 “cairo-surface.c”, line=928,function=0x7f7a671e5210 “cairo_surface_reference”) at assert.c:101
cairo_surface_reference () from /opt/Ardour-4.1.0/lib/libcairo.so.2
cairo_pattern_create_for_surface () from /opt/Ardour-4.1.0/lib/libcairo.so.2
?? () from /opt/Ardour-4.1.0/lib/libcairo.so.2
The error window won’t you copy and paste, so I hand copied the messages here and tried not to make mistakes
The test system is:
Ardour 4.1 from Ardour.org
Alesis IO4 USB sound card
I recorded 4 tracks to a USB disk. (Normally I record to a SSD, but it was full
For the time being, disable waveform display in the preferences while doing long-term recordings.
The issues is a race-condition with rendering the waveform in the background while recording and not yet 100% understood… but we’re working on it.
@mhartzel: is there more below the stack-trace? the first frame inside one of ardour’s libs will be interesting. It’ll likely be a line in libcanvas.so libs/cavas/wave_view.cc
I found the whole UbuntuStudio crash report in /var/crash/ you can download it here:
The file also has the core dump information in it and after that comes stack traces. The name WaveView is mentioned a couple of times on the report.
My recording started at 02:08:05 last night and the crash report time stamp is 09:28:31, so it took 7 hours 20 minutes and 26 seconds of recording for Ardour to crash. This is pretty close to exact 440 minutes, and maybe this might give some additional clue. Since I was recording 4 tracks of 16 bit wav, and davidbuhau was recording 8 tracks with 32 bits and got the crash much sooner.
The wav files in session dir are all 2 348 154 924 bytes long.