Ardour3 freezes at startup

Hello Paul,
I’ve downloaded Ardour source code, compiled and installed it according to your instructions.
The program starts, configures itself for the first time, asks for a new session and open the main windows. But as the log states:
Scanning folders for bundled LV2s: /usr/local/lib/ardour3/LV2
the program freezes. No way to wake it afterwards.

I would like some help, if possible.

Thank you in advance,
Andre Felipe

could you please share details on the system/OS/compiler etc…

afelipe: http://ardour.org/debugging_ardour

In general, I do not support self-built versions of Ardour.

I also had a similar problem with the self-build version. I ended up buying a pre-packaged version…

I’m having this problem on DreamStudio 12.04 since the 3.5.357 release. Suspecting that it was a build error I paid for the prebuilt version. Same issue. It freezes on the splash screen, and by launching from command line I see that it’s freezing while trying to scan lv2 plugins. I’ve tried several sessions, all of which previously worked, and am getting the same error.

I just tried creating a new session. Same behaviour.

I tried setting the timeout all the way to 10,000 ms (I leave it at 5000 by default), to no avail. I ran ardour in debug mode, and submitted a proper bug report, here: http://tracker.ardour.org/view.php?id=5913

Well, I’ll be. It was an error with jost-vst. I removed the app and now ardour loads. Strange that it wouldn’t do so with the latest version of Ardour but would with a previous version. No matter, I use festige now anyway. Thanks for the help!

You’re welcome Joe! Thanks for letting me know it worked.
I’m glad we ran into the same issue.
Cheers, Brian

A data point from me - I just upgraded to Ardour 3.5.357 and had the session hang while loading tracks.

$ jackd --version
jackdmp 1.9.9.5

I upped the timeout in qjackctl, restarted everything and all went fine. Thanks to BrianSully for having that tip already in the thread when I came looking for info on this topic.

Hi, me again…

Could this hang be caused by me using an old version of libjack.so…?
Am just looking at the wscript file under, /Ardour3-3.5.357/libs/backends/jack

It seems to mention something about libjack version 0.121.0 (apologies, this waf stuff is new to me).

“autowaf.check_pkg(conf, ‘jack’, uselib_store=‘JACK’, atleast_version=‘0.121.0’)”

The backtrace says I’m working off,

$ ls -ltr /usr/lib/i386-linux-gnu/libjack.so.0*
lrwxrwxrwx 1 root root 17 Oct 18 2011 /usr/lib/i386-linux-gnu/libjack.so.0 -> libjack.so.0.0.28
-rw-r–r-- 1 root root 79784 Oct 18 2011 /usr/lib/i386-linux-gnu/libjack.so.0.0.28

I’d have thought the build would have failed if I had not got the correct libraries but maybe there’s something up with the dependancy checking(?) I’ll try and dig out 0.121.0 next week sometime, see if it helps.

In the meantime, if you get a chance, Andre, could you let me know if increasing your jackd timeout had any effect or if you’ve managed to get a backtrace during the hang.

Enjoy the weekend folks,
Cheers, Brian

@BrianSully

What is the output of…

jackd --version

  Seablade

$ jackd --version
jackd version 0.121.2 tmpdir /dev/shm protocol 24

@afelipe

fyi:

I rebuild jack client (libjack.so.0.0.28) so with -g and re ran the hang.

Client is just hanging waiting on a socket read from a jackd server that has timed out & given up on it.

I’m going to leave it there as I don’t the problem here.

Might have been nice if the client timeout & tried to reconnect or maybe printed a notification but either way uping the jackd timeout (as per manual) sorted it for me.

I can’t say anymore about the original issue Andre reported without more info from him (ie backtrace output, did timeout increase have any effect etc).

Cheers, Brian

Back trace below.

[Thread 0xaddbab40 (LWP 15206) exited]
^C
Program received signal SIGINT, Interrupt.
0xb7fdd424 in __kernel_vsyscall ()
(gdb) bt
#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb5ec09db in read () from /lib/i386-linux-gnu/libpthread.so.0
#2 0xb2020e94 in oop_client_deliver_request (ptr=0x9c298b8, req=0xbfffc18a)
at client.c:247
#3 0xb2020f60 in jack_client_deliver_request (client=0x9c298b8,
req=0xbfffc18a) at client.c:278
#4 0xb2027145 in jack_port_register (client=0x9c298b8,
port_name=0xa0d73ec “LTC In/audio_in 1”,
port_type=0xb20ab560 “32 bit float mono audio”, flags=1, buffer_size=0)
at port.c:273
#5 0xb20a1d1e in ARDOUR::JACKAudioBackend::register_port (this=0x9a18ab8,
shortname=…, type=…, flags=ARDOUR::IsInput)

Hi Andre & all

Just a though but you might want to check your jackd timeout (qjackctl->setup->settings->timeout).I was having the exact same problem running ardour from gdb (it was freezing at ‘Scanning folders for bundled LV2s…’ etc).

It turns out I forgot to increase my jackd timeout (as one does when running through gdb).

I bumped it up to 5000ms and it loaded no problems.

While it was hanging I looked at the backtrace in gdb,

"
[New Thread 0xaddbeb40 (LWP 14653)]
Scanning folders for bundled LV2s: ./…/build/libs/LV2
[Thread 0xb01ddb40 (LWP 14645) exited]
^C
Program received signal SIGINT, Interrupt.
0xb7fdd424 in __kernel_vsyscall ()
(gdb) bt
#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb5ec09db in read () from /lib/i386-linux-gnu/libpthread.so.0
#2 0xb2021b35 in ?? () from /usr/lib/i386-linux-gnu/libjack.so.0
#3 0xb2021cae in jack_client_deliver_request () from /usr/lib/i386-linux-gnu/libjack.so.0
#4 0xb2026d01 in jack_port_register () from /usr/lib/i386-linux-gnu/libjack.so.0
#5 0xb20a1d1e in ARDOUR::JACKAudioBackend::register_port (this=0x9a18eb8, shortname=…, type=…,
flags=ARDOUR::IsInput) at …/libs/backends/jack/jack_portengine.cc:394
#6 0xb7b55881 in ARDOUR::Port::Port (this=0x9a48dd0, n=…, t=…, f=ARDOUR::IsInput) at …/libs/ardour/port.cc:74
#7 0xb790f96d in ARDOUR::AudioPort::AudioPort (this=0x9a48dd0, name=…, flags=ARDOUR::IsInput)
at …/libs/ardour/audio_port.cc:36
#8 0xb7b5d5ba in ARDOUR::PortManager::register_port (this=0x9788fc4, dtype=…, portname=…, input=true,
async=false) at …/libs/ardour/port_manager.cc:287
:
:
:
"

I guess maybe it was waiting for something to come back from jackd to say its port is registered (or something) but jackd has timed out and given up(?). Either way increasing the timeoue seemed to do the trick for me.

Of course, your hang may well be due to some other reason(s) completely.
The only way to tell for sure is to get a backtrace as per the link mentioned previously in this thread etc…
(run ardour in gdb, ctrl c at hand then enter ‘bt’ …i think…)

But first up the jackd timeout, see if it makes any difference.

Hope this helps.

By the way, off topic I know but I’ve just setup Ardour in last week & am playing around with it. What a brilliant piece of audio software!
Thanks so much & well done to all involved, am blown away by your work and its quality.
Music can only benefit as a result.
I’m really looking forward to leaving windows behind & moving to ardour & linux for producing music form here on.

Cheers, Brian

sorry, forgot to add,
I’m using Ardour3-3.5.357, built on,

$ uname -a
Linux Bernabeu 3.11.0-18-generic #32~precise1-Ubuntu SMP Thu Feb 20 17:54:21 UTC 2014 i686 i686 i386 GNU/Linux

Cheers.

http://ardour.org/debugging_ardour

I had the same problem on my Laptop and the problem was discoDSP’s Discovery VST synth, the sound banks was copied to a wrong path and the VST did not load. A simple method for finding which VST that cause problems is to fire up Carla plugin host and let it search for plugins. When Carla find a VST with problems, the search goes idle showing the name of the plugin that causes the problem. That has worked for me so far.