Linux: ALSA performance degraded severely from 3.4.0 onwards

Help, Support & Bugs
1

The ALSA performance under Linux used to work fine up until 3.3.x, but from 3.4.0 onward, it’s glitchy as hell. I thought it was just me or my computers (because I use crap ones intentionally), but I saw on Reddit others having problems. Since others were having problems I realized it’s not just me and my computers. I narrowed it down to being a problem in more recent builds.

I realize there are a bunch of steps suggested to set up real time threads and all that, or you can use Jack, but Linux audio is a nightmare in general, so it’s best when it Just Works, and it used to work fine - without all the faffing about. Even when you do the rtprio stuff, ALSA is still a hot mess. You can sometimes get something reasonable if you stand on one leg, set your buffer to something huge, and the moon is in the right phase, but it kind of doesn’t work properly in general.

I went back through all the old versions, and identified when the problem started. As mentioned, it’s 3.4.0 onwards.

I got another Redditor to verify the behaviour by downloading an older version, and they confirmed it Just Works for them too in the older versions, and degrades with the later builds.

Is there a good reason for the performance to suffer so much in recent builds and there is nothing that can be done (apart from the mess that is Jack), or is this a genuine bug that can be fixed so that Renoise on Linux is a useful DAW again?

I’m happy to be the guinea pig for any tests or logs required and I have plenty of crap hardware to test on.

Thanks in advance and I will happily send crypto for beer money to the dev who fixes this (because I read about the plight of underpaid Renoise devs in the Bug Report Etiquette).

2

First, try avoid using the default ALSA config. The default config is using a software mixer and is in general slower than the direct HW drivers.

Then, try disabling the capture device. Syncing the capture and playback ALSA device is tricky. Full duplex on ALSA requires way more buffering than running only the playback device.

Finally, try using Jack instead of ALSA directly in Renoise. Jack’s ALSA implementation is better than the one from Renoise ones. There are decades of work and finetuning in Jack, which we simply can’t copy paste or redo. So, it’s unlikely that Renoise’s ALSA impl will ever be better than the one from Jack.

—

If this doesn’t help, we’ll need a bit more info here. Describe your setup and the upload the song that you are testing it with. Nothing really changed in the Linux ALSA impl for Renoise 3.4/5., but I’ll double check this. Once we have more info on the setup I can also try checking this against older versions of Renoise.

3

My setup is a fresh Linux build - it’s usually Linux Mint, but I’ve tried others and they behave the same. The machine I am using right now for this testing is a 2013 Macbook Air. Previously it was an Intel N100 but I installed Windows on it because Renoise wasn’t working in Linux properly. I can’t remember the exact specs of every machine I’ve tested it with, but it’s consistent behaviour - crackly. No idea what the guy from Reddit used. I’ve got much better machines here that I could test it with, but the fact it works fine on this Macbook Air with 3.3.2 and not on 3.4.0 makes me think that something did change. Firefox audio works with ALSA and I don’t have to jump through hoops, so while I’m sure Jack is better than ALSA etc, I just expect the defaults to work in Renoise since every other app manages to work - and Renoise used to work too.

I simply install Renoise, leave everything as default, click OK to the warning about realtime threads, and open Demosong - Hunz - Soon Soon.xrns and play it. It’s not just this particular demo song. They all play poorly in recent builds, and fine in prior builds.

I have attempted to resolve it with setting up the real time threads stuff, but this doesn’t seem to work in the recent builds. As I mentioned, setting the buffer to something HUGE (like 4096 or 8192) sometimes works, but this is an awful solution.

Where do I disable the capture device? Do you mean the In device within Renoise? That’s set to None.

4

More symptoms as I probe around:

I installed 3.4.0 again, and I can’t even play a single sample (a short kick sample) without crackling at 512 buffer length. I upped the buffer length to 2048 and it was still bad. Tried 4096 - still bad. 8192 - I got silence. Down to ~6000 - still silence. Wouldn’t even make a noise - then complained that it couldn’t open the ALSA device. I tried running as root. Still silence, weirdly, even though it looked like it should be working.

Installed 3.3.2 again - bingo, golden @ 512 samples, running as my normal user. I could play sounds as expected. 3.4.0 ALSA is screwy in all sorts of ways (and don’t take that personally like I’m bitching, I’m actually a big fan, and just trying to help - I love Renoise… I’ve been a user since v1.5 and it never used to behave like this).

5

You should try using Pipewire-JACK instead. It’s better to use JACK than ALSA on Renoise. Here’s how you set it up on Linux Mint:

Install pipewire-jack:

$ sudo apt install pipewire-jack

Then run the following commands:

$ sudo cp /usr/share/doc/pipewire/examples/ld.so.conf.d/pipewire-jack-*.conf /etc/ld.so.conf.d/
$ sudo ldconfig

Then restart Pipewire. Alternatively, you can just restart your session by logging out then logging back in:

$ systemctl --user restart pipewire

JACK should now work on Renoise. If you’re still having performance issues, I suggest rooting out any bottlenecks that’s causing poor performance with Renoise using rtcqs which will tell you the cause of Renoise or any other DAW having poor performance on your system. Try to follow the instructions in the links they provide which are guides on how to solve these bottlenecks. If you want a distro that is already pre-configured for music production, then I suggest using Ubuntu Studio instead of Linux Mint.

6

I was the “other redditor”

I have ALSA problems in Ubuntu Studio as well. Only JACK works.

ALSA does work in renoise ver 3.2.4 though, so something seems to have changed more recently.

Not a big deal for me, Ive never had problems with Jack (some people seem to have… strong opinions on it) but it is what it is.

7

Just to chime in, I’ve had rock solid performance with Jack2 and Renoise up to 3.4.2. With 3.5.1 and newer I get xruns about every two seconds, with the expected crackling, regardless of frame or period settings. That’s with a dedicated Soundcard for Jack2 without pipewire-jack.

Edit:

Buffer length does have an impact, at 512 an idle, empty project in 3.5.2 produces more xruns than at 1024.

16:22:05.250 XRUN callback (1).
JackEngine::XRun: client = renoise was not finished, state = Running
JackAudioDriver::ProcessGraphAsyncMaster: Process error
JackEngine::XRun: client = renoise was not finished, state = Running
JackAudioDriver::ProcessGraphAsyncMaster: Process error
16:22:10.256 XRUN callback (2).
16:22:12.255 XRUN callback (3).
JackEngine::XRun: client = renoise was not finished, state = Running
JackAudioDriver::ProcessGraphAsyncMaster: Process error
JackEngine::XRun: client = renoise was not finished, state = Running
JackAudioDriver::ProcessGraphAsyncMaster: Process error

Does Renoise have any --verbose switches for logging?
8

What Multicore/CPU support you have ?Try limit cpu cores in Renoise.

9

Hm, now this is a bit weird…

I’ve had 6 of 8 CPUs set to “Realtime audio CPUs” in the Config, haven’t changed that setting in years. Now changed the setting to 2 of 8 and the xruns disappeared with 1024 buffer size, yay! :slight_smile: But after restarting Renoise the xruns have returned. :frowning:

I lower the buffer size from 1024 to 512, 256 down to 128 frames, and as long as I open the config after loading a song and change the “Realtime audio CPUs” value to anything else, everything runs great without xruns. If I start Renoise and do not touch this setting, I get xruns again. Output of Renoise when changing is this:

Renoise LOG> Player: Creating slave threads...
Renoise LOG> Player: 2 threads enabled. 8 CPUs are available.
Renoise LOG> System: Changing a threads priority to '99' FAILED (error: 1)!
Renoise LOG> System: Changing a threads priority to '99' FAILED (error: 1)!

(Max priority for realtime is 98 on my system, that would explain the error messages)

10

I appreciate the people telling me how they’ve managed to work around this problem with pipewire/jack or whatever, or they’ve fudged around with settings and I’m sure these solutions may work, but I wish to reiterate the point that IT USED TO WORK FINE.

It’s simply a case that something has changed, and it’s made the ALSA performance worse. What used to be fine without requiring tricks and fiddling about, has become god awful with everyone having to put in effort to avoid using it because they clearly had problems with it and needed to find a solution.

I’m saying “Hey guys, why not fix the thing that’s broken - which used to work - so that out of the box everyone can probably get acceptable performance, and if you need better latency than that, you can do all this weird stuff that is being suggested to get your low latency for recording or whatever”. Compare it with DirectAudio and ASIO. DirectAudio is higher latency (ALSA), ASIO is low latency (Jack) - but what DirectAudio doesn’t do is crackle and grate your ears in the newer versions.

I’m not new to Linux, Renoise, or all these hacks to make audio better in Linux. But I’m getting sick of tech getting worse over time and people just putting up with it. The “enshittification” of everything. So please, I’m glad you have your way of avoiding this bug, but can we at least acknowledge it’s a bug that was introduced in 3.4.0?

For everyone that doesn’t believe me, please go back to 3.3.2 and try ALSA yourself so you can understand what I’m talking about here, instead of trying to “help” with my settings. I don’t want settings. I just want the ALSA audio to work how it used to.

11

Can you edit that post to say 3.2.4 otherwise it’s confusing for any dev trying to understand this.

12

Sorry to be grumpy, but if your issue is not with ALSA in new versions, can you make your own topic? This is not the “mother of all Linux audio problems” topic. I just want this one particular issue fixed because it’s tripping up a lot of people and they think Renoise in Linux sucks when it used to be great.

13

I apologize for misunderstanding the situation you are in. I don’t know what the solution for performance issues with ALSA are. I would say maybe try resolving bottlenecks in performance with rtcqs but I assume that ALSA used to work fine before 3.4 despite not resolving realtime bottlenecks? Does ALSA on Renoise 3.4+ work fine out of the box on distros like Ubuntu Studio by any chance? I personally cannot test ALSA on my end because I keep getting “device or resource is busy” error and I’m not really interested in solving this issue since I’d rather just use JACK on my end. Maybe it could be a bug caused by implementation of new features? I don’t really know. I guess it’s up to the devs to find out.

14

Sorry to have hijacked your topic, back to ALSA then :slight_smile:

I installed 3.3.2 alongside 3.4.2 and 3.5.2 and ran a few tests, I managed to get extremely crackling, slowed down audio in the newer versions, the UI with all meters ran in slow motion. No In Device, Out device was set to default (System Default Device). In Version 3.3.2 there was no “System Default” device, so I had to explicitly select the hardware. My dedicated soundcard hw:1,0 worked properly, onboard hw:0,0 worked after killing pipewire-alsa. Went back to 3.4.2 and 3.5.2 and now they suddenly run without issues.

If think there is a possibility that your fresh Linux does not provide direkt ALSA access, but the pipewire-alsa layer, like many current distributions. You may check if pipewire is running with:

ps -A | grep pipewire

In my case described above, pipewire-alsa has set the samplerate of the soundcard to 44800 and when I select System Default Device as output with a sample rate of 44100 in the newer versions, pipewire-alsa will not change the cards sample rate, but try to resample in realtime.

After killing pipewire and letting Renoise 3.3.2 take control of hw:0,0, the sample rate on hw:0,0 was changed from 44800 to 44100 and stayed at 44100, even after restarting pipewire. I guess thats why the newer version suddenly worked again.

My theory does somewhat fall apart if you have no traces of pipewire installed on your system, though.

If you want to output of pipewires samplerate, use this:

pw-metadata -n settings

15

I have Mint 22, it does ship with pipewire-alsa out of the box.

Running your “pw-metadata -n settings” command shows clock.rate of 48000, with clock.allowed-rates [ 48000 ].

Running Renoise 3.3.2 with defaults (hw:0,0 selected, default device doesn’t exist), the sample rate is 44100, but it doesn’t crackle.

Went back to 3.4.0 - strangely it worked. In this case, hw:PCH,0 was selected, set to 44100.

It is the same device, but with new names. Clearly something in the ALSA implementation has changed because the devices enumerate differently (hw:0,0 vs hw:PCH,0), AND there is a System default device (which plays nothing at all when selected, even after reinitialize, at either 44100 or 48000). Trying to change between System default and hw:PCH,0 was giving me “Failed to open the ALSA device”, but I clicked Reinitialize and it worked.

So NOW in 3.4.0 (same machine): System default device doesn’t work at all. Selecting hw:PCH,0 is working at both 44.1 and 48kHz. Exiting the program and restarting with System default device selected, set to 48k to match the pw-metadata. Still silence. OK - assume bugs.

Move to 3.4.3 - same major version, latest release with bugfixes:

  • System default device @ 48kHz crackles.

    System default device @ 44.1kHz crackles.

    hw:PCH,0 @ 44.1kHz - works fine.

    hw:PCH,0 @ 48kHz - works fine.

It appears not to be a resampling thing. I never touched/restarted the pipewire daemon, and every time I ran that settings command I saw 48000, despite what I had Renoise set to.

It feels like the System default device is not just figuring out which entry in the list to behave as (eg, auto select hw:PCH,0 in my case), but has some behaviour of its own. It seems to have been introduced in 3.4.0, and perhaps some fixes made through to 3.4.3.

16

Version 3.5.2:

System default device @ 44.1kHz, crackles

System default device @ 48kHz, crackles

hw:PCH,0 @ 44.1kHz - works fine

hw:PCH,0 @ 48kHz - works fine

These devices should be equivalent in my mind. I only have one card (at least while I don’t have an HDMI cable plugged in), so the default device is my only device, right?

The easiest solution at this point seems to be get rid of that System default device, because it doesn’t work. Or rename it to “ALSA abstraction layer - software renderer” or something that indicates it’s not the same as choosing a device from the list. Or keep it there, but make the option act exactly like one of the other options, instead of whatever it IS doing at the moment.

Making it the default option is a terrible idea, since that’s what everyone’s first impression is going to be, and it’s crap. The suggestions about setting up rtprio etc are no longer relevant since they aren’t fixing the problem caused by this “System default device”.

I haven’t had to set any rt priority or anything for my user, and I can run with a 64 buffer on this crappy old Macbook with hw:PCH,0 with no crackling on that Hunz Soon Soon song.

With “System default device”, I can’t even get smoothness with 1024 buffer or 4096. It’s just a bizarre device from what I can tell.

17

The “System default device” is the, well, system default device given to Renoise, which in many Linux distributions is currently pipewire, impersonating ALSA. Pipewire works great for consumer audio and offers interfaces for alsa, pulse-audio and jack. The problem is that samplerate, bit depth, buffer sizes, etc are all managed by pipewire and the settings in Renoise for the default device don’t change the actual ALSA-device settings.

I can think of three ways to tackle the problem:

1. Configure pipewire for professional audio, use wireplumber to set sample rates, buffers, periods of your hardware. If you have pavucontrol installed, set your sound card to “pro audio” in its configuration. If everything is setup correctly, the “System Default Device” should work just like direct ALSA.

2. Use a second, dedicated soundcard (i.e. USB) just for Renoise over ALSA or even better over Jack2 with QjackCtl to configure the low level settings. Consumer stuff stays on “System Default Device”, pro audio takes hw:1,0. You will have to disable the dedicated sound card for pipewire, otherwise it will try to grab that one, too. Can be done in pavucontrol under “Configuration”.

3. Kill the pipewire process before starting Renoise and use hw:0,0.

Edit: Or maybe take a look pipewire-jack, it has jack’s options for audio routing und works well with Renoise, but buffer size, periods and sample rates ara -again- configured in pipewire.

1 Like
18

Exactly. We didn’t add the “System Device“ in Renoise versions < 3.4 because it performs slower than the direct HW devices, but in general it’s more “compatible” and avoids that audio gets locked for other applications. It usually works just fine on my setups, but requires larger buffer sizes for the above mentioned reasons.

@d2TiTus when you avoid using the system default device, which other problems are left then? Is the hw:PCH,0 @ 44.1kHz device on your system still causing issues?

19

Now that I understand that “System default device” is actually a completely different device than one of the HW devices, it does halfway explain why the ALSA audio became terrible once it was introduced. I don’t think it makes it clear enough that it’s different - I had no idea until I went down this path, and other people ask about getting Linux audio to work and most of the advice is all the old advice about rtprio etc, which won’t fix it if they’re still using that default device, because they might only have one device so “logically” they leave it set as that. Maybe a warning saying “this is potentially crap - if you have problems, use a hardware device instead of this one” might be better.

Even better, and just to be a pain, I’ll ask why the default device still has to perform so badly when for instance my Firefox doesn’t generate crackly crap when using https://codepen.io/gil/pen/ggvzQP and it doesn’t ask me anything about any the device or settings. It somehow just works, through ALSA without having exclusive access to my sound.

Like I get that the hw device works, but now let’s assume I want to use the system default device: why so awful, even with large buffers?

20

If I remember correctly, this was once handled by “alsaconf”, through which you could set the default device. Or even better, according to this wiki.
I vaguely remember how I set up the configuration file “.asoundrc”.