occasional CPU overload

[xaverius]

Hi there,

from time to time the audio output is heavily distorted when I start my music audio setup, which is mainly based on a Dell XPS13 with Ubuntu Studio 22.04, Pure Data, Ardour and a Fireface 802 USB audio interface via Jack. If this issue occurs, there is nothing I can do except for waiting a longer time or restarting my laptop. Although restarting does not always fix it. I found out that this issue is related to a CPU overload (also the GUI is much slower then). I took two screenshots of atop when everything was working normally and when the audio output was distorted. Could you please help me to compare and interpret the screenshots? I was not able to identify a process that causes the trouble. Or is there anything else that I should consider? I'm especially worried about liveacts when I would have to get rid of this issue immediately if it occurs.

Thank you in advance!
André

[novalix]

Hi,

is that the very same Ardour/PureData project that causes these different outcomes?

[xaverius]

Yes, it is.

[novalix]

So the memory consumption in the bad example is much higher overall. Alas, there are null values for the virtual and real memory allocation (VGROW and RGROW) for the ardour and the purr-data processes. jackd has only a tiny bit of virtual memory allocation.
The kernel process controlling the usb interface connection is consuming much more cpu. Also the kernel process controlling the graphics interface is slightly up. Xorg is working hard, too.

First question is: Where is ardours, pure datas and jacks memory gone? Maybe the oom-killer has reached for his revolver, or the hardware is bad.
The rest may just be a cascading effect.

At first you should run memtest to rule out (or find) troublesome memory banks, i would suggest.

[merlyn]

In the good example irq (I would think it's the soundcard irq) is taking up 2%. In the bad example irq is taking up 34%. A USB interface shouldn't do that.

Is the Fireface 802 in class compliant mode?

[xaverius]

Thanks for your posts so far!

I executed a detailed on-board memory test in the BIOS and it passed successfully. And yes, the memory consumption is conspicuous in the distorted case. I saw that it is possible to have a closer look at what is going on in the memory with "atop -m". So, I'm waiting for the issue to occur again und will take further screenshots then. Unfortunately, this issue only occurs rarely. Regarding the USB interface I can tell that it did not help to restart the interface and yes, it is class-compliant.

[novalix]

The really strange thing is that there is no process in the list justifying the increase of memory consumption. My speculation is that the cause of the problems lies in the past of the snapshot atop is capturing and what we see are cascading effects of that event.
There is no dbus process listed in the bad snapshot. What has happend to that poor guy?

So another two questions:

What version of ardour are you running?

How long did that bios memory test take?

[xaverius]

The memory test took about half an hour (there was no memtest entry in the Grub menu) and the version of Ardour is "6.9.0 ds0".

[novalix]

So, regarding the possible hardware problems, this bios test can not reliably rule them out. It is a first hint, however.
There should be a (two) software package(s) of memtest in the repository.

Code: Select all

apt install memtest86

or

Code: Select all

apt install memtest86+

should install and activate the software in the grub menu.
It is not essential which of those packages you use. To rule out hardware flaws it is necessary that either of these programs runs for a longer period of time like over night.

My question about the ardour version stems from this bugreport.
The ibusd in your bad session doesn't seem to be causing problems, but it is still possible that this guy really caused the whole desaster in the first place and now hides behind the back of the bigger guys.

What version of ibus are you running?

Code: Select all

apt-cache policy ibus

If it is the buggy version, could you try the official ardour build (there should be a demo version)?

[xaverius]

I downloaded memtest from memtest86.com and executed "MemTest86 Free" via USB stick boot. It took about two and a half hours and passed successfully without any errors. And this is the version of ibus:

Code: Select all

xaverius@XPS13:~$ apt-cache policy ibus
ibus:
  Installed: 1.5.26-4
  Candidate: 1.5.26-4
  Version table:
 *** 1.5.26-4 500
        500 http://de.archive.ubuntu.com/ubuntu jammy/main amd64 Packages
        100 /var/lib/dpkg/status 

[novalix]

Hi,

that seems to be good news (for your expenses on hardware anyway) and a bit of bad news for our efforts of troubleshooting the problem.

The *buntu version you're running is not effected by that ibus bug. That was a shot into the deep dark anyway.

The memory issue path seems more and more unlikely. There still remains the possibility that some process slowly eats up memory and at some point the oom-killer gets triggered kills a process and the whole infrastructure of running applications gets out of control.
But in this scenario a certain amount of runtime duration would be required. It would be highly unlikely for such an event to occur right after the start in a freshly booted system.

If there is no hardware issue (i.e. a flaky usb interface connection can yield some random troubles), my next bet would be to look out for some graphics/ui fuckups.
If you start ardour from the command line in a terminal emulator, you can track down messages from the program about possible problems.

Code: Select all

/usr/bin/ardour &

should do (note: if you close the corresponding terminal session you close the application, too).
If the bad behavior occurs, you can see (paste/post) possible error messages of the program.

Good luck.

[xaverius]

Hi novalix,

Thank you very much for your posts. They were really helpful, although I haven't solved this issue yet. I completely agree to your last post; I had similar thoughts in my mind.

My audio setup is started by a script. So, I can observe error messages from Ardour easily. And there is still "atop -m" to look for conspicuous memory behavior. Let's wait for this issue to occur again...

Best,
André