High DSP in idle status [solved]

Installation & Configuration Linux
#15

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.

#16

Bi Directional vs one way latency.

 Seablade
#17

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.

#18

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/

#19

@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.

#20

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

#21

I managed to download it, thanks!
I also ordered an adapter to try connecting the sound device to the usb type c socket, then I’ll do some new tests.

#22

I think first investigate if this actually is a problem. Are you sure that the configuration is not taking advantage of more agressive power saving modes which lower CPU clock at idle? Does DSP go above 80% when a session is actually running? I looked through the older posts, I never saw any confirmation that you actually have high DSP useage and underruns while a session is running, only that the DSP looks concerning for an idle session.

#23

It’s great that you have done this test.

I’m sorry to hear about the result, it must be disappointing that the new machine does not work as expected.

I expect that it’ll be very hard to track the actual issue down. It could be anything from USB chipset, graphics cards/driver issues, or bus power-save/frequency scaling. It may also be some issues with the mainboard itself that cannot be configured…

Does this also happen with the internal/onboard soundcard? ie the issue is USB?

#24

There is always the option to buy a separate PCIe USB2 - card. There is no telling if that helps or not.

Edit: I forgot this is a laptop, no option for PCIe - cards.

#25

I don’t know if it matters in this case but you could try booting with the kernel command line parameters intel_idle.max_cstate=0 processor.max_cstate=0 .

It does wonders when it comes to reducing xruns at low latencies .

Here’s some info on the CPU C-States

#26

After XFCE login: clock 3493.300 MHz
After start Jack: clock 3519.477 Mhz, DSP 1-5%
After open Ardour session: clock 3457.470 Mhz, DSP 20-50%
During recording: clock 3433.569 Mhz, DSP 60-90%, many xruns

#27

With internal soundcard I don’t have bad DSP values on idle status. The values ​​fluctuate less and it seems more stable.

#28

It works, I find a reduction of about 10% of DSP but the values continue to fluctuate a lot with many xruns.

Edit: I have done other tests after reboot and now, with this solution, I can stay within 50% of DSP without xruns on recording. It’s good. However, I notice some xruns on qjackctl after stopping the recording.

#29

I did some tests using Guitarix and processor.max_cstate=0 appears to be unnecessary. It’s the intel_idle line that does the magic.

Are you using 2 or 3 buffers/period?
I saw that you didn’t find any improvements using 3 earlier but it seems to be the recommended value and giving the CPU just a little more time should help shaving off the odd xrun.

I would also suggest using at least 64 frames/period, to reduce the risk of xruns even further.
You shouldn’t be able to notice any timing problem using softsynth or guitar effects even at a 44/64/3 setting and if you aren’t using software instruments/amps you may as well set it to 128 frames/period or even higher.

#30

Just out of curiosity: what make and model your laptop is ?

I’m out of ideas, but one more thing comes to mind. Maybe the chipset is not initialized correctly. These kinds of bugs are fixed in EFI, so you should probably install the latest EFI upgrade if one is available.

I tinkered with x42 ALV drums plugin yesterday on my 4 core i7-3630QM laptop and was seeing DSP loads varying from 7 - 60% with nothing else but this one plugin in the session. That seemed much for one plugin so I did some tests. These results might give you some ideas for further testing. Test were done with Alesis IO4 USB sound card, Buffers = 1024, Periods = 3, x42 AVL drums playing drum samples.

Manjaro default kernel 4.19.113, CPU Governor = Powersave, DSP Load 7- 60 %
Edit window mixer strip showing a-compressor that updates volume graphics

Manjaro default kernel 4.19.113, CPU Governor = Powersave, DSP Load 8 - 44 %
No Edit - window mixer strip showing

Manjaro default kernel 4.19.113, CPU Governor = Performance, DSP Load 5 - 56 %
Edit window mixer strip showing a-compressor that updates volume graphics

Manjaro default kernel 4.19.113, CPU Governor = Performance, DSP Load 4 - 40 %
No Edit - window mixer strip showing

Manjaro Realtime kernel 4.19.116-rt45-2, CPU Governor = Powersave, DSP Load 7 - 8.5 %
Edit window mixer strip showing a-compressor that updates volume graphics

Manjaro Realtime kernel 4.19.116-rt45-2, CPU Governor = Powersave, DSP Load 7 - 8.8 %
No Edit - window mixer strip showing

Manjaro Realtime kernel 4.19.116-rt45-2, CPU Governor = Performance, DSP Load 3 - 4.3 %
No Edit - window mixer strip showing

Manjaro Realtime kernel 4.19.116-rt45-2, CPU Governor = Performance, DSP Load 2.9 - 3.5 %
No Edit - window mixer strip showing
Kernel options: intel_idle.max_cstate=0 processor.max_cstate=0

Manjaro Realtime kernel 4.19.116-rt45-2, CPU Governor = Performance, DSP Load 2.8 - 3.4 %
No Edit - window mixer strip showing
Kernel options: intel_idle.max_cstate=0 processor.max_cstate=0 mitigations=off

Conclusion: Realtime kernel gives consistent performance, Performance Governor lowers load.

#31

@peder
probably in the end I will use configurations with higher latency, before I wanted to try to replicate the performance of the older PC.

@mhartzel
My laptop is an Asus N580VD-FI038T with i7 7700HQ cpu.
Thank you for test data, you have high DSP load only with normal kernel, I will do the same test on my system to be sure that the realt time is working properly. Updating the EFI can also be an idea.

#32

I received today the adapter for the usb type c socket, connect the sound card to it i have excellent values, DPS <10% in idle and <40% in recording. I thank everyone for the valuable advice and sign the thread as solved.

Ardour 6: heavy xruns
#33

That is great to hear.
Have fun recording and mixing!

#34

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.