Ardour gui freezing up while transport is moving

Hi, I’m experiencing a frustrating issue with Ardour 4.7 ever since installing AVLinux 2016 on a fresh system.
Ardour is the only app on the system that is behaving this way…
Ardour opens and loads either a new session or an existing one without problems, I start the transport (play or record, doesn’t matter) and it all works fine for a few seconds, but then if I’m doing something like resizing the height of a track in the recorder window, soloing a track, or I take it out of record mode (i.e. I punch out), the screen freezes up and the only way I can bring it back is to press the reset on the PC and reboot. The channel assignments don’t affect it, they can either be logically routed to the master or monitor section or not assigned at all.

When the GUI freezes up the song will keep playing to the end, if it was running. The transport display stays put. The meters stay where they were. The mouse pointer can still move around, but you can’t click on anything. Even things outside of Ardour, like the application launcher and virtual screen controls don’t work. Keyboard commands don’t work either.
This happens every time, the only random thing about it seems to be that a mouse click on some Ardour control triggers the freeze. I’ve also tried starting Ardour with the plugins disabled (I hadn’t activated any, though), and it does the same thing.

I’m not sure what diagnostic info you may need to troubleshoot this, but I can tell you that it does this using Jack or just using alsa without jack. I have two Delta1010 cards installed and configured, but even if I only specify one of the cards in the audio setup it still does it. I’ve searched the internet on this and no one else seems to have reported an issue like this.

Some details of the system are: 32 bit AV Linux 2016 install, 4.1.5-rt5-avl2 (i686) kernel, 2 GB ram, 3 Ghz, Intel E8400 dual core 3GHz processor, nothing in the usb ports, networking turned off, NVidia GF114 (GeForce GTX 560 SE) video card, 2 Delta1010 interfaces optimized with rtprio, .asoundrc (combines the 2 deltas), one card is clocking the other via spdif, etc.
I don’t want to clog up the post with unneeded info, so please let me know what other info might be useful here, thanks!

Hi,

That’s strange, especially with nVidia graphics. Can you try the latest 4.4.6 kernel and post back?

Just out of curiosity, because I ran into a somewhat similar thing recently, you wouldn’t happen to have your RAM overclocked would you?

Hi,
No, the ram is not overclocked, at least I don’t think so. I inherited the box from my son and reconfigured it. I’ll default the bios to make sure and post back.

Also, I’ll upgrade the kernel. I may not be able to post back about this till tomorrow because of work, but thanks to both of you.

ah alright. It was worth a shot haha. I asked because I was running my RAM overclocked and when I ran ardour up to around 60% DSP load, it did this same thing on me. Dropped the speed back down and it never happened again.

(so my assumption was my ram clock wasn’t stable and caused lockups on heavy load, nothing wrong with ardour. The specs on your PC are what led me to ask, 2GB with a core2duo for audio sounded like overclocking might be happening and you could be running into the same thing)

I made sure the memory is being clocked at its normal rate, and installed kernel 4.4.6. Then rebooted.
Unfortunately it still does it. While the track was running, I was able to start and stop the click, solo and un-solo the track ( for this test I’m using a test session with one stereo track), and then I resized the track and it froze up as before.

Update - The screen has now also frozen up after zooming in on the waveform and starting playback. The song ran for a couple of bars, then froze on its own - this is the first time it has frozen by itself, without me clicking the mouse.

No ideas??
I find that very surprising based on the level of expertise I’ve seen here!
Right now I’m reading up on troubleshooting the Xwindows system, if anyone has a good handle on these types of issues and thinks I’m looking at the wrong area please let me know, this system is unusable for recording the way it is.

@icb: you have a problem that is extremely rare. For that reason, the rest of us are not really in a position to make useful suggestions. I personally have never seen this, or heard a similar report.

If Ardour is not the only thing to freeze, if your whole gui freezes, then the problem might be the display driver.

Your processor seems to be quite old and so don’t suffer from bugs of Intels newer chipsets, but another thing that might be worth looking at is power saving and frequency scaling.

I have a newer processor (Intel N2930 @ 1.83GHz) and this machine had alomost exactly the symptoms you describe. The whole desktop froze from time to time and the problem was not related to processor load. I could happily do heavy program compiling for hours with no problems, but as soon as I started clicking on gui elements I got freezes. Ardour or Jack somehow stressed the machine more, so I got most freezes when using Ardour. Later I also noticed getting freezes when clicking gui elements in Firefox or scrolling its window.

The culprit in my case was the Haswell chipset and it’s faulty processor power saving states. It took me 6 months to track down the problem and the thing that helped at last was starting the machine with kernel option “intel_idle.max_cstate=0”. This stops processor power savings that try to save power by constantly fluctuating processor speed and putting parts of the processor circuits in power saving mode whenever possible.

You could try to downgrade or upgrade the display driver and put processor frequency scaling to “performance” mode. You also could try to disable all power saving features of your processor and chipset.

In my case disabling processor power savings also made audio recording more reliable. I can now use lower buffer sizes in Jack when I need it.

I’ve had that vey same problem too and it always happens with rt kernels. I think AVlinux comes with an rt kernel by default. I’ve tried multiple rt kernels from several sources, I’ve compiled my own, and sooner or later my PC always freezes with the same behaviour: if something is playing it carries on and you can move the mouse, but all the graphics freeze and the only way to get control back is to reboot.

Try installing a lowlatency kernel from the kxstudio repos - I’ve never had problems with these and performance will be almost identical to the rt one.

Sad news. Kernel option “intel_idle.max_cstate=0” made no difference, changing to the Liquorix kernel also made no difference. Any assistance would be appreciated. Does anyone have experience using Ardour with latest planet CCRMA? thinking about trying that one.

Success! (at least so far). I should have tried this a lot earlier I guess, but removing Ardour4 and ArdourVST altogether and then re-installing “ardour” from the AVLinux repo has resulted in a gui that appears to work. I’ve never had a linux problem actually get fixed by deleting and reinstalling before, but there you go. There must be something different about “ardour” vs. “Ardour4” in the AVL repo. GTK2 maybe? Does anyone (Gmaq) know if this is the case?

Hi,

‘ardour’ is Debian’s packaging of Ardour and would use Debian’s dependencies to build unlike the bundles of Ardour from here that use their own dependency stack. ‘Ardour4’ is the KXStudio package which in truth is ardour.org’s bundle simply wrapped in a Deb package. I do not personally package Ardour (but I do custom package ArdourVST) because it doesn’t exist anywhere else.

Anyway it would appear that your video hardware likes Debian’s package better for some reason.

To clarify there are only Kernels in the AVL repo, all the multimedia goodies come through Debian’s own repos or the KXStudio repos…

Thanks guys!
I’ve been working on other parts of my studio for a couple weeks but I’m getting back to the DAW problem and i’ll definitely look in these areas now.

Ignotus, I was really hoping I wouldn’t have to drop the RT kernel, but you describe a problem so identical to mine that you probably have nailed it. I’ll post back with results.