When I try export big session (1-2 hours length) sometime it can be fail with dead ardour application.
I try set realtime export - not help. My last success try - open htop, find ardour threads and set nice -20 for ardour main process and -15 for him threads.
I see fast increment of VIRT and RES memory to 1-2 GB and more and more.
What is? Memleak or just coming OOM killer with my settings?
This isn’t a known failure mode. What does “fail with dead ardour application” mean? Are you using the JACK backend?
JACK or alsa without JACK not change result. Ardour (sometimes) just close, fast close, probably OS kill him. How I explain it? Try with debug mode? How? I can run it as you want and show any logs for you.
I also noticed once when came home that running Ardour ate all virtual memory available in the system (16 GB). Sadly, but I can’t tell what was the matter.
What versions of Ardour are we talking about ?
What if you disable plugins and do the export again ?
Are you using Linux, OS X or windows ?
Are you now read Linux forum, OS X or windows ? ))
Probably when disable plugins it can be success. Yes - plugins eat 100%. But why this should affect the fall? This is just resources (hdd, mem). And I have more resources.
Are you now read Linux forum, OS X or windows ? ))
Actually, for most of us, because of the stupid web styling on these pages, there’s no indication of what forum this or any other thread is in …
There might be a bug in one of your plugins that makes the export fail. Calf plugins have a long history of misbehaving, are you using any of those by chance ? If you are you could try disabling only those and export again to see if you found the cause of the problem.
@mhartzel this sounds strange. Why calf (or other) plugins works fine in realtime but fail when export? Export just generate waves and send generated values into temporary file instead jack or alsa buffer. This is should be very similar.
Ok, today I’ll try disable all plugins.
@paul how run ardour with debug mode for you?
Calf plugins have been known to for example prevent Ardour loading a session that previously worked fine. Export runs the plugins as fast as they can go (freewheel mode), realtime playback does not.
Any plugin just handle frames. Some plugins may have internal buffer (eq, reverb) for store information about wave. I do not know plugins who can not run faster than came up author. It’s impossible. Speed of the plugin limited only processor speed. It’s just “mov eax”, nothing more. Maybe only memleaks or segfaults (author guilty).
Yes 
Tell us how it goes when you disable plugins.
If you want to run Ardour in debug mode, here is how you do it:
https://ardour.org/debugging_ardour.html
I hope you find the cause for the problem.
Deep: you’re theorizing about things you don’t know enough about. There are MANY reasons why plugins can break when used in faster-than-realtime mode, some of which are some plugin APIs such as Apple’s AudioUnits have specific flags to (a) mark plugins as incapable of being used in this mode (b) tell plugins when they are being used in this mode. I appreciate that your simple view of what plugins are makes sense (and perhaps it would be a better world if it was really like that). However, your view is simplistic and de facto incorrect.
@paul At least for plugins that I use - it correct.
@mhartzel thanks! (no, I have not check, I’ll tell)
Deep: unless you’ve read the source code of a plugin, you have no idea what its internal organization is. There are plugins that superficially behave as you describe, but actually use multiple threads and synchronization primitives between them in ways that are not visible to the user until you try to use them in a faster-than-realtime scenario. You cannot tell this sort of thing as a user of plugins - only someone with access to the source code could describe how it works internally.
@paul but plugin developer should care about safe-thread (semaphore/mutex) implementations. I do not deny the existence of “dangerous” plugins. But really I hardly use such plugins. I use only: eq, compressor, flanger and saturator. Ok. let’s wait test in debug mode. Then we might know where problem, and talk about it.