Debugging ALSA issues and some questions

[lilith93]

I decided to use ALSA instead of Jack in the next weeks to see how it goes and have some questions:

I got a "Bus Error" reported in the terminal window from Reaper shortly after switching to ALSA and Reaper crashed. I've seen the same error with Jack when using the "Server Synchronous Mode". However I don't know if this is related.

Are there any log files in order to debug ALSA issues like the log window in Jack?

Maybe that's part of the problem?: I set RT priority in the ALSA perferences of Reaper to 80 (that's the suggested value in Jack). In Reaper the default ALSA RT priority is 40. So, I better set it to 40?

What's the best method to stop the connection to ALSA in Reaper? Switching to the Dummy Audio interface? Or is there any button like "Disconnect Audio"?

[Glennbo]

I just checked my audio configuration and I have RT Priority set to 50 which says it is the hardware default. Auto-suspend Pulse Audio and Disable Power Management are both ticked, but the option for Lock Process Memory is not ticked. Also the Allow Projects to Override Sample Rate is ticked.

[lilith93]

Originally Posted by Glennbo

I just checked my audio configuration and I have RT Priority set to 50 which says it is the hardware default. Auto-suspend Pulse Audio and Disable Power Management are both ticked, but the option for Lock Process Memory is not ticked. Also the Allow Projects to Override Sample Rate is ticked.

I have it like this at the moment:



I'll test it and hope I don't run into problems. Otherwise I might have to write an email to the support or so..

[Glennbo]

Originally Posted by lilith93

I have it like this at the moment:

I'll test it and hope I don't run into problems. Otherwise I might have to write an email to the support or so..

The disable power management is one that could make some difference, but you do need the permissions to use that one.

If you issue the command

ulimit -a

what does it come back with on the lines for real-time priority and max locked memory? Those can make a difference if not tweaked, but then you are running a lot of instances of heavy CPU consuming plugins, so you may already have those set to 98 for priority and unlimited for locked memory.

[lilith93]

Originally Posted by Glennbo

The disable power management is one that could make some difference, but you do need the permissions to use that one.

If you issue the command

ulimit -a

what does it come back with on the lines for real-time priority and max locked memory? Those can make a difference if not tweaked, but then you are running a lot of instances of heavy CPU consuming plugins, so you may already have those set to 98 for priority and unlimited for locked memory.

I have a desktop pc and I don"t think there is any powermanagement. Also unlikely that this would cause a crash. Yup, I have it set to 95 and unlimited. Kernel is the stock debian kernel.

[Glennbo]

Originally Posted by lilith93

I have a desktop pc and I don"t think there is any powermanagement. Also unlikely that this would cause a crash. Yup, I have it set to 95 and unlimited. Kernel is the stock debian kernel.

You are correct that it is unlikely to cause a crash, but with the stock power management even on a desktop (which I am also on), there will be timers kicking off and counting down to blank out screens, spin drives down, throttle USB ports, and such every time you stop moving the mouse or keying something in on the keyboard, so I let REAPER disable the whole mechanism when I'm working on music.

How much of a performance boost that might add, I don't know, but there wouldn't be a box to tick if it didn't help to some degree, and I figger every process I can stop and give the CPU time to REAPER the better.

[JamesPeters]

Here are my OS tweaks (Xubuntu 20.04):

• Install lowlatency kernel
• Install indicator-cpufreq (for choosing the frequency governor, set to "performance" when using DAW, basically the same thing you'd do in any other OS to ensure the CPU frequency doesn't throttle)
• Disable xiccd in startup (color managment for monitor in Xubuntu, not needed, took extra cpu)
• Do not disable screensaver or power management in startup. Let them run, but set them to do nothing. Performance is best this way.
• Libre Office. Options - Advanced - Java Options: remove the tick for Use a Java runtime environment
• In "/etc/sysctl.conf" add line "vm.swappiness = 10"

From Linuxaudio.org about "vm.swappiness":

"This setting changes the so-called swappiness of your system, or in other words, the moment when your system starts to use its swap partition. You can check the current value with cat /proc/sys/vm/swappiness, in most cases it is set to 60. This is too high, it will make your system start using swap too fast which might influence the overall performance."

Here are my Reaper settings:





Also under "audio" -> "Audio settings":

-Close audio device when stopped and application is inactive

So if I click away from Reaper when it's not playing, I can get audio from other apps.

It's great for low latency use (with that USB device: Focusrite Scarlett 2i2 3rd generation) and stable (no xruns) up to 90% CPU, including responsive UI. No other OS tweaks were done (other than some preferences involving font, color, etc.)

Perhaps when using multiple audio apps at the same time, and using Jack to connect them, you need to do other changes to the OS. I don't do that though.

[lilith93]

@JamesPeters: Thanks for that. There are some points which are new to me (e.g. the Java and xiccd thing.

"Also under "audio" -> "Audio settings":

-Close audio device when stopped and application is inactive
"

Perfect, that's handy.

How did you optimize your Alsa paramters? Did you have problems, because some are not set to the default value?

I wonder when Reaper is getting a "bus error". When I search the forum for "bus error" I don't find any entry. I have reaper currently running with Alsa to check how long it will survive.

The USB cable from the interface to the computer is 3 m long. That should be fine as the maximum is 5 m. Does anybody know what happens when using a cable that is too long?

[lilith93]

"-Close audio device when stopped and application is inactive"

This option works as long not many plugins or some specific ones are used. Some plugins seem to stay active in the background. Even if I disable all FX it's not working.

[JamesPeters]

Originally Posted by lilith93

How did you optimize your Alsa paramters? Did you have problems, because some are not set to the default value?

Default was ok, when using this audio device (Focusrite Scarlett 2i2 3rd generation). The settings I ended up with work a bit better when the CPU is being used near 100%. I tested various settings, including opposites of what I was being told by others.

"Render ahead" setting was something recommended on the forums that I'd learned about a while ago.

With a PCIe audio card, I may have set the RT priority for ALSA in Reaper higher. I also did a couple extra things (assigning realtime priority etc.) in the distro too...but I don't recall if those settings made a difference in themselves, or if it were coincidence (with the other Reaper settings).

Originally Posted by lilith93

The USB cable from the interface to the computer is 3 m long. That should be fine as the maximum is 5 m. Does anybody know what happens when using a cable that is too long?

I don't know, since I'm only using the short cable that came with my interface.

Originally Posted by lilith93

"-Close audio device when stopped and application is inactive"

This option works as long not many plugins or some specific ones are used. Some plugins seem to stay active in the background. Even if I disable all FX it's not working.

Are you using any bridged plugins (Windows, LV2, etc.)?

I don't have this problem, but I only use native Linux VST and JS plugins.

[lilith93]

Originally Posted by JamesPeters

Default was ok. The settings I ended up with work a bit better when the CPU is being used near 100%. I tested various settings, including opposites of what I was being told by others.

"Render ahead" setting was something recommended on the forums that I'd learned about a while ago.



I don't know, since I'm only using the short cable that came with my interface.



Are you using any bridged plugins (Windows, LV2, etc.)?

I don't have this problem, but I only use native Linux VST and JS plugins.

Nope, no bridged and no Windows plugins.Just found it: A track was armed. Now it works perfectly. Reaper was running the whole day with Alsa without crashing while I was in homeoffice. Hope it stays like that.

[JamesPeters]

Excellent! I'm glad to hear it!

[lilith93]

Got again the "Bus Error" and Reaper crashed. I absolutely don't know where to start to debug this. With Jack everything is running fine, at least Reaper never crashed with that message.

In the journal I found this messages which appeared shortly or at the same time as the crash:

Mai 20 18:47:42 marco kernel: traps: reaper[6137] trap stack segment ip:7fa56ec6d859 sp:7ffda6246fc0 error:0 in libSwell.so[7fa56ec47000+a8000]
"

Don't know if this is related as I have a bunch of these:

Mai 10 02:05:54 marco kernel: reaper/mediaafx[9976]: segfault at 0 ip 0000000000000000 sp 00007f81db7fdd38 error 14 in reaper[400000+88a000]
Mai 14 20:44:22 marco kernel: traps: reaper[3469] trap stack segment ip:7f2951767859 sp:7ffe10a55630 error:0 in libSwell.so[7f2951741000+a8000]
Mai 16 16:42:59 marco kernel: traps: reaper[2699] trap stack segment ip:7f24f2a87859 sp:7ffdaf5d6690 error:0 in libSwell.so[7f24f2a61000+a8000]
Mai 16 18:06:46 marco kernel: traps: reaper[1274] trap stack segment ip:7fbd11b04859 sp:7fff0b571520 error:0 in libSwell.so[7fbd11ade000+a8000]
Mai 17 01:01:24 marco kernel: traps: reaper[7401] trap stack segment ip:7effd1ac5859 sp:7ffc2bbfc4d0 error:0 in libSwell.so[7effd1a9f000+a8000]
Mai 17 01:55:43 marco kernel: reaper[8641]: segfault at 11d ip 00007fae0c598859 sp 00007fffac476720 error 4 in libSwell.so[7fae0c572000+a8000]
Mai 17 02:18:49 marco kernel: traps: reaper[8693] trap stack segment ip:7f0dd97e6859 sp:7ffd434ae140 error:0 in libSwell.so[7f0dd97c0000+a8000]
Mai 17 22:38:26 marco kernel: traps: reaper[8953] trap stack segment ip:7f7019032859 sp:7ffcc046a770 error:0 in libSwell.so[7f701900c000+a8000]
Mai 17 23:30:49 marco kernel: reaper[8988]: segfault at ffffffffffb86902 ip 00007f8373c9dab0 sp 00007ffc9a8b8b00 error 5 in libSwell.so[7f8373c7e000+a8000]
Mai 20 18:47:42 marco kernel: traps: reaper[6137] trap stack segment ip:7fa56ec6d859 sp:7ffda6246fc0 error:0 in libSwell.so[7fa56ec47000+a8000]