Hi!
I know there are some posts about this issue, but they are very old.
Since some months (don’t know when it started exactly), exporting became very slow (less than real time), and varies with buffer settings. Shouldn’t Ardour work in freewheel mode while exporting?
I have no other softwares opened and/or connected in jack.
I’m working with very long takes, and this is very boring.
any idea?
Right for Ardour version, but there was a KX studio repository update. A pre-compilation issue? I updated many packages that day, but I can’t say what else would have solved the problem:
Start-Date: 2018-08-20 12:30:09
Commandline: /usr/sbin/synaptic
Upgrade: drumgizmo:amd64 (0.9.14-1kxstudio1, 0.9.16-1kxstudio1), hexter:amd64 (1.0.2-1kxstudio1, 1.1.0-1kxstudio2), carla-bridge-wine64:amd64 (1.9.5+git20160114, 1.9.8+git20180819), distrho-prom:amd64 (20170617, 20180427), lufsmeter-lv2:amd64 (20180101-1kxstudio1, 20180404-1kxstudio3), obxd-lv2:amd64 (20180101-1kxstudio1, 20180404-1kxstudio3), distrho-mini-series:amd64 (20170617, 20180427), samplv1-lv2:amd64 (0.8.6-1kxstudio2, 0.9.2-1kxstudio1), sndfile-programs:amd64 (1.0.27-1kxstudio2, 1.0.28-1kxstudio3), samplv1:amd64 (0.8.6-1kxstudio2, 0.9.2-1kxstudio1), drumkv1-common:amd64 (0.8.6-1kxstudio2, 0.9.2-1kxstudio1), distrho-ndc-plugs:amd64 (20170617, 20180427), tal-plugins-lv2:amd64 (20180101-1kxstudio1, 20180404-1kxstudio3), juced-plugins-lv2:amd64 (20180101-1kxstudio1, 20180404-1kxstudio3), gxplugins:amd64 (20180213, 20180604.2), drumkv1-lv2:amd64 (0.8.6-1kxstudio2, 0.9.2-1kxstudio1), dexed-lv2:amd64 (20180101-1kxstudio1, 20180404-1kxstudio3), flashplugin-installer:amd64 (28.0.0.137ubuntu0.14.04.1, 30.0.0.154ubuntu0.14.04.1), artyfx:amd64 (1.3+git20171104-1kxstudio1, 1.3+git20180320-1kxstudio1), distrho-plugin-ports-lv2:amd64 (20180101-1kxstudio1, 20180404-1kxstudio3), synthv1:amd64 (0.8.6-1kxstudio2, 0.9.2-1kxstudio1), synthv1-lv2:amd64 (0.8.6-1kxstudio2, 0.9.2-1kxstudio1), flac:amd64 (1.3.1-1kxstudio2, 1.3.2-1kxstudio1), guitarix:amd64 (0.36.1+git20180124, 0.37.2+git20180604), ardour:amd64 (5.12.0-1kxstudio1, 5.12.0-1kxstudio2), drowaudio-plugins-lv2:amd64 (20180101-1kxstudio1, 20180404-1kxstudio3), pitcheddelay-lv2:amd64 (20180101-1kxstudio1, 20180404-1kxstudio3), klangfalter-lv2:amd64 (20180101-1kxstudio1, 20180404-1kxstudio3), qmidiarp:amd64 (0.6.4-1kxstudio1, 0.6.6+git20180814), padthv1-lv2:amd64 (0.8.6-1kxstudio2, 0.9.2-1kxstudio1), easyssp-lv2:amd64 (20180101-1kxstudio1, 20180404-1kxstudio3), arctican-plugins-lv2:amd64 (20180101-1kxstudio1, 20180404-1kxstudio3), calf-plugins-git:amd64 (0.90.0+git20180604, 0.90.1+git20180816), sordi:amd64 (0.16.1+git20170321-1kxstudio1, 0.16.1+git20180413), luftikus-lv2:amd64 (20180101-1kxstudio1, 20180404-1kxstudio3), padthv1-common:amd64 (0.8.6-1kxstudio2, 0.9.2-1kxstudio1), lv2-dev:amd64 (1.15.3+git20170321-1kxstudio2, 1.15.3+git20180413), distrho-plugins-lv2:amd64 (20170617, 20180427), synthv1-common:amd64 (0.8.6-1kxstudio2, 0.9.2-1kxstudio1), distrho-nekobi:amd64 (20170617, 20180427), samplv1-common:amd64 (0.8.6-1kxstudio2, 0.9.2-1kxstudio1), x42-plugins:amd64 (20170428-1kxstudio2, 20180320-1kxstudio1), suil-libs:amd64 (0.8.7+git20170321-1kxstudio1, 0.10.0+git20180711), distrho-mverb:amd64 (20170617, 20180427), drumkv1:amd64 (0.8.6-1kxstudio2, 0.9.2-1kxstudio1), mod-sdk-lv2:amd64 (1.1.1~git20170829, 1.1.1~git20180402)
End-Date: 2018-08-20 12:32:31
What update? The latest released version is still 5.12, which is the version you said you were running on 2018-05-07, and the 6.0-pre state of the source tree is as far as I have heard still considered not suitable for production use.
After last Ardour update, it seems to be solved. I’ll turn back here if I notice any regression.
Thank you for your help!
Are you using jackd at all? If you are using jackd as the audio backend, but not using any external software, you could try using the ALSA backend, that would eliminate jackd freewheeling as a potential problem, and make it easier to debug since all of the freewheeling behavior would be controlled entirely internal to Ardour.
Are you using 5.12? You did not say which version you were using (default disclaimer: you should not be running anything except 5.12 at this point).
yes, I’m using Jackd, and Ardour 5.12.
I made some test with Alsa, but it doesn’t work better. Internal chip HDA @48K with buffer at 512 exports ~4second/seconds, for a one track session with some CALF plugin.
CALF is probably the problem. The CALF plugins are, as of May 2018, still one of the most common causes of problems for our users. When they work, they work well. When they don’t work, they break things in a variety of ways.
DSP doesn’t work at full. And realtime is disabled, the speed varies with jack sample rate, and can be slower than real time.
I removed all plugins in a snapshot of a session, but the issue is still present…
There’s also a “realtime” checkbox in the export-dialog (timespan tab) to override freewheeling (useful if you need external send/return). Make sure this is disabled.
Other than that: What is the DSP load of the session? Freewheeling at best results in a speedup of 1/DSPload (or 100/DSPload%).
no idea?
Have you tried using plain ALSA instead of Jack?
@Blindekinder: Your response to x42’s request for the DSP load was rather cryptic (“DSP doesn’t work at full”). The expected response was something like “DSP load averages around 30%”.
Probably you will need to make a copy of your session available to download somewhere, this is not a common problem that other people see.
@Arnd: See third comment, Blindekinder replied “I made some test with Alsa, but it doesn’t work better.”
rather cryptic (“DSP doesn’t work at full”)
I checked, they work at ~46%, all 4 proc at different levels, no one at full.
Was it better?
DSP at ~12, with jumps higher…
@blindekinder: you wrote “they work at ~46%, all 4 proc at different levels”
That sounds like you are looking at processor utilization, such as would be provided by top or htop. DSP load is a specific measure unrelated to processor utilization in any easy way, it basically means how much unused time exists when processing the required audio samples. It will be a single number no matter how many processors you have.
You can see DSP utilization displayed at the top of the Ardour screen, or if using jackd with a tool such as qjackctl the qjackctl window will show DSP utilization.
12% DSP load is not very high, in the absence of other problems freewheel export should run significantly faster than real time, up to 8x per the comment above.
I can only repeat my earlier advice, “Probably you will need to make a copy of your session available to download somewhere, this is not a common problem that other people see.”
well, I can do that, but all my sessions are affected…
I can do that, but all my sessions are affected…
And none of my sessions are affected. Not sure what you want here, other people do not see the problem, there is obviously either a problem specific to your system or to how your sessions get setup. Running a copy of one of your sessions on a different system would help confirm or eliminate system specific problems.
Smaller and simpler is better both from an upload/download time standpoint, and from reduced complexity helping focus debug, so I would suggest creating a new session, record just one track with maybe three minutes of silence, and see if that still has a problem with slow export. If it does then you can tar and gzip the session directory and other people can try to export on different systems to see if the problem occurs elsewhere. If the problem occurs on other systems then you can upload to the bug tracker and the Ardour developers can did into the session to see what is causing the problem.
If the problem occurs on your system but not on any other systems then you will probably have to get on IRC and find someone to help debug your system configuration.
If the problem does not occur when you create a new session, then you will have to build up piece by piece what you normally add to your sessions to determine which change could be causing the problem. Do you usually add any external sends? Do you have any unusual routing configurations? Any analysis settings checked that could be slowing export?
Hi, sorry to be back here, but it doesn’t work. In the meanwhile I passed to Kubuntu 19.10 / KX Studio repos. Pulseaudio is suspended.
I tried ccaudle trick:
Result: export still very slow. I tried on a 96k session, with 1024/2 buffering, with no plugins: it exports at almost double of real time. I repeat export speed depends on latency settings.
