High DSP in idle status [solved]

Hi all! I’m trying to configure a system for music production based on Arch linux. I’m running Ardour 5.12.0 and when I start a new project, before to record anything, I have DSP moving between 30% and 60%.
The problem occurs both using JACK and connecting directly to ALSA. No errors in Adour’s logs.
How can I investigate the problem? Is there any tool I could use?

If you have a USB audio device then use Buffers = 1024, Periods = 3 as a starting point. Smaller buffers will cause higher load.

If you have plugins on your tracks those will process audio even though Ardour is in stopped state. More plugins will cause more load.

Hi Mikael,

thank you for you reply.

Yes, I use a USB Roland Rubix24. With this device, on an older pc with AVLinux2018, I can work for hours without xrun on 48000kHz, buffer 64, periods 2. I would expect to be able to do it also in this new pc.

I have the same anomalous value of DSP also with another USB device on the same pc.

Considering this and other tests I’ve done, I think the problem is due to some hardware or software conflict, but I don’t know how to find out.

There may be several USB - busses on your computer. Check if you can find a USB - port that is on it’s own USB bus with no other devices on it. Other devices on the same bus can interfere with your sound cards communications. Put your mouse on each USB - port one by one and give the terminal - command: lsusb This lists all devices on the USB - ports and what USB - bus the device is on. Identify your mouse on the lsusb - output and then you know on what USB - bus the current USB - port is.

Also you can change your computers USB3 to behave like USB2 from the EFI (disable xhci - mode). Some devices don’t work correctly on USB3.

I hope this helps, I’m out of ideas :slight_smile:

Also try with another USB - cable, sometimes the problem is physical :slight_smile:

I tried to:

  • disable all about USB on bios
  • disable all internal and external connection to USB bus for leave only the audio device
  • change cable
    nothing change.
    Any other ideas?

Try using the AVLinux2018 Live session to see if there’s something particular with your Arch install.
Is Arch using a real-time patched kernel? I believe AVL does.

You can also try and disable HyperThreading on your CPU. Some people think Ardour works better without it.

Disable wifi and bluetooth. On laptopts wifi - card may be on the USB bus.

And try buffers = 1024, periods = 3 just see if it makes a difference.

Here my USB and KERNEL situation:
[ravaz@ArchLinux ~]$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 0582:01e0 Roland Corp. Rubix24
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
[ravaz@ArchLinux ~]$ uname -r
5.4.26-rt17-1-rt

Networking and wifi disabled.

I tried open a new Ardour project in safe mode (with all plugins disabled) and there has been no improvement in the situation.

I have also tried:

  • to disable HyperThreading (there is no this function on my cpu)
  • 1024 frames 3 periods, DSP is near 5%
  • live of AVLinux 2019 (I can’t find 2018 image) 64 frames 2 periods, DSP 10 - 20%
  • live of AVLinux 2019 1024 frames 3 periods, DSP 0.7 - 1%
  • old PC AVLinux 2018, Ardour 4.7, same USB audio device, 64 frames 2 periods, DSP 7 - 10%
  • old PC AVLinux 2018, Ardour 4.7, same USB audio device, 1024 frames 3 periods, DSP 1.3 - 1.7%

Stupid question, have you set the CPU governer? If your CPU is throttled back, you will see high DSP usage, most people set their governer to performance as a result.

        Seablade

Is this a laptop ? If so wifi needs to be disabled from EFI or using a physical switch on the laptop. Disabling wifi on the os won’t help since it won’t disable the wifi - hardware.

Yes, it is set to performance. I followed the Professional Audio guide on Arch wiki to configure the system.

Yes, it is a laptop. I tried to disable wifi and LAN in EFI and nothing changes.

I don’t know if it is an error and if it is important, I saw that Ardour calculates an incorrect latency time: now on Jack 48000Hz 64 frame 2 periods I have a latency of 2.67 msec, at the same time Ardour which is connected to Jack indicates a latency time of 1.3 msec.

I can see that your sound device has Zero latency monitoring. You are probably aware that when you use that you don’t have to have low latency on your computer. Buffers = 1024, periods = 3 work fine in this case. I guess you are trying to use guitar effects, soft synths and the like because you are trying to drive latency down.

Right ?

One thing I noticed is that you may be comparing different kernel and Ardour versions on your computers. These might have an effect also.

I found a working torrent for AVL2018.6.25 but I’m not sure if the site is safe, Firefox disabled a javascript cryptominer when I entered the site. Then again this is how some sites tried to monetize legally, so it might be ok. I can send you the torrent if you want or the address of the site. AVL2018 isos seems to have vanished from the net, maybe some shasums are still availabe to validate the download. I’m downloading the image right now.

Bi Directional vs one way latency.

 Seablade

The buffer-size (nominal process block duration per cycle) is 1.33ms (64 / 48 kHz).
The latency (capture + playback) is at least twice that, so 2.66ms. Round trip latency is usually even longer.

Ardour displays the configured buffer-size in the status bar and setup dialog.

Ardour6 has an optional toolbar item to display round-trip latency (incl. measured systemic latency, plugin latency, and disable PDC.

I would not. In my experience most recent PCs are worse for reliable low latency operation, in particular for USB devices.

I have an old Thinkpad X60s that allows to configure hardware IRQs in the BIOS, and allowed to configure a dedicated IRQ for a port. That box managed to reliably run USB 2 * 64/48k for days.

Check with lsusb --tree if you can get a dedicated port.

A 10 years newer X250, twice the CPU speed… that cannot handle this low latency reliably even with a rt-kernel. Usually needs at least 3 * 64/48k but even then there are occasional NMIs or TRM IRQs :frowning:
Without an rt-kernel and rtirq it even has issues with 256/48k.

With USB devices try using 3 periods/cycle: https://www.linuxmusicians.com/viewtopic.php?f=47&t=10707

and another thing to perhaps try:

See also https://manual.ardour.org/setting-up-your-system/the-right-computer-system-for-digital-audio/

@mhartzel
Yes, and also because it is easier to record without have to use compensation.
I have found the torrent file to but there are no shares.

@x42
I can get a dedicated USB Type-C port but right now I am missing the adapter. I will test it.
Forcing USB 2.0 or using 3 periods does not produce changes.
To confirm it’s an hardware problem I have tried same AVL2019 live on both the computers and actually the old one gives me much lower DSP values with the same configuration.

So I think there is nothing else to do, however other suggestions are welcome.

I’ve dowloaded the AVL-2018.6.25.iso, it seems to be genuine, I can verify the checksum is valid. Here is the working torrent, I can always put the iso for download for a limited time if this torrent does not work. It did work yesterday.

You can validate the iso checksum at waybackmachines copy of AVL - sites download dir in 2018. It may also be possible to download the iso directly from there, but I have not tried it.

https://web.archive.org/web/20180628000001/https://download.linuxaudio.org/avlinux/

sha256sum:
0a137e213ce26a152856936e94a17f947535ff0a122b5a3778b104047ea1f22f