There is
nothing
as low level as alsa in any distribution.
What’s so hard to understand about the fact that even jack needs alsa to control HW?
The only exception when jack doesn’t need alsa is when it communicates with HW via firewire and the card still has to support FFADO.
Hey there, I know the pain you’re going through with Linux. Let me just tell you, that you’re approaching Linux with the wrong attitude. You’re judging it together with commercial products and their marketing strategies. Linux is not only free software in it gives you freedom to do anything with the open sourced code, but also it is often free beer, and then you should not expect to be heard for complaining the same way as one who has paid it. Instead, Linux grows from a scene of people who are enthusiasts and giving their free time to support and fix bugs and improve the whole system. Some distros are truly like that, people who use it know things, and then they are stable but it’s very normal that you first have to fix all kinds of bugs and set up a galore of things if you want to use it for special purposes (i.e. anything else than server or office desktop…).
So you should try to practice patience and try helping with the software in constructive ways, and when you want some serious support for your Linux or end-user experience then you have to pay for that distro or support. Many people will be willing to help you out of sympathy though - just don’t expect it to work like with a commercial product. It’s really free, and anyone with enough knowledge could fix the bugs for you or set everything up perfectly, and when enough people like that get together with others who help, these bugs just get fixed. You can even pay somebody to do it for you with a bounty code. If you want to use linux for some specific purpose, i.e. audio work, then you can also try using an audio-centered distro, which preconfigures some things related to the task.
I’m just going through setting up debian and it rulez, I get like ultra stable sound with the real time kernel, it rocks, I hope I can play guitar with this live without delay, not tried but latency looks promising. I had to fix up everything in my install, crossing fingers to get the last things resolved & then just use my system for months straight… Old thread, but this is the beginning of what to do… https://forum.renoise.com/t/linux-system-realtime-performance-tuning cyclictest ftw. am now at like 20-50 ns gaps with sporadic single drops 200-500 (intel gfx driver sucks, and nvidia hacked up for rt-kernel, even more, then I don’t want to miss luks). I think going for open source graphics drivers and avoiding the wrong ones (intel…) and then avoiding encryption can get you around or sub 10µs stable maximum latency dropouts for your audio and sound card threads, that is on a properly configured realtime kernel system on hardware that allows this (I do it with used lenovo workstation gear).
About your problem, you must understand something about the new “default” device. It’s dependent on your distro’s mixer, so in your case maybe pipewire, and it’s maybe not realtime stable. So go complaining to the linux mint people, but maybe there’s also fault in renoise about it somewhere. Do not expect latencies to work well below like 150-250ms. The mode in renoise is just for convenience I think, so you can listen to tunes without killing the sound server. Maybe it can be tuned, I don’t use pipewire because I still use jack (no it’s not dead, but the most stable for ultra low latencies…). The default output is the software mixer, and when you use the direct also code of the card, then the card gets locked up just for renoise, and other apps cannot use it - so it can work much more stable without pipewire. I believe the ability to use the default device is new to the current (3.4) version, so that’s maybe the difference that was introduced?
To make it work better, you can try to setup pipewire so it is more realtime stable. Also you mentioned that Renoise gives a warning about realtime priorities? Have you not thought these warnings are valid, why haven’t you researched them instead of ignoring them? In the renoise docs is written you should setup realtime priorities rights for your user. You can check in terminal with ulimit -r -l, and it should show something like “95/unlimited” for the two values. If you don’t get that output, you should try doing the steps prescribed in the Linux Faq (Linux FAQ - Renoise User Manual) way down at the point “Realtime Threads”.
This is actually done automatically when you install jackd2, and usually instead of what is written in the faq you’d write a file “/etc/security/limits.d/audio.conf” with the rights definitions ("@audio - rtprio 99, @audio - memlock unlimited), then “sudo adduser yourusername audio”, don’t forget to log out and back in before chekcing again with the “ulimit -r -l” command. I can help you further if you want.
But probably your sound system is just not stable enough, so it might not help. Why don’t you just keep using the old option of using the sound card directly with alsa? Renoise is a realtime audio program. I think it got more realtime stable with v 3.4 btw., I could set latency much lower, to like 4ms at times on a realtime kernel, that was not possible in the past, I believe. Even if you use alsa directly, the limits.d fix will help you making your sound more stable. Jack only allows going even more stable , also when you use it with pipewire. Just go through the hoops of setting it up right once, and seek help if you need it, then you can keep using it until your another update breaks it some day, or the computer itself breaks down from extended use or hardware failure 
.
Btw. I’m really thinking this must be a pipewire/LinuxMint specific problem, or your system setup or hardware.
I just tried on my system (okay, realtime kernel I admit, I can try again later on a standard kernel and without rtirq), I can use the “default” setting like any other program, no dropouts until I go very low in the buffer sizes (like below 64/3), it play dblue-tension cleanly… P.S.: this is on a laptop with some beef, with pulseaudio instead of pipewire installed.
Before we write on, what is your “Buffer Size” and “Periods/Buffer”, and have you applied the limits.d/audio.conf fix?
ALSA isn’t outdated. It’s built into the kernel and essential to modern Linux audio systems. It’s probably closest to what Windows has with audio drivers and MME or DirectSound?
However, achieving low latency like ASIO, playing multiple audio sources simultaneously, or precisely synchronizing them requires an sound server like JACK, pulseaudio, or pipewire.
Pipewire can handle mixed connections involving ALSA, JACK, and pulseaudio, and offers extremely flexible device and node management. Its high configurability can often be confusing, but that’s the trade-off for its power. It’s impressive how it allows users to build their own custom sound architectures with relatively simple configuration. In any case, each sound server was developed for its own important reasons.
well, it’s not as simple as that. Sometimes the buffer needs to be raised, because the system is not stable enough - then configuring the system better (realtime priorities, or soundsystem settings) can stabilize it at same or even lower buffer sizes. Samplerate is underrated, only some hardware has problems i.e. with 44100 and then you need to run in 48000. Higher rate only means samples zap through faster, might need raise buffer size and needs more cpu, so lowering it can release the cpu and thus remove crackles, if the cpu was maxed out by the system.
OK I’ve found a solution which appears to work VERY WELL across multiple computers, of varying age and crappiness, with the ALSA default device.
I’ve tested on the old MacBook Air (i5-4260U from 2014), a Thinkpad T400 (Core2 Duo P8400 from 2008), N100 (from 2023 but low power), and Ryzen 5 5600G (from 2021).
They all exhibited problems with the default settings, but they all worked properly with these settings:
ALSA, default (System Default Device)
Sample Rate: 48000 - using 44100 was doomed to crackle, even on the Ryzen
Buffer size: Anything that is a power of 2 - using a non power of 2 was doomed to crackle (or even be silent?) … the P8400 CPU could even manage a buffer size of 64 without issue (playing Hunz - Soon Soon for reference).
Periods/Buffer: 2 - anything else was doomed to crackle
Note I didn’t bother with any of the rtprio stuff (I know that it tells you to, but I’m specifically trying to get a great “out of box” default settings experience with as little tinkering as possible, because I could see that other apps achieve this)
I got the inspiration from martblek’s image (thanks for providing your settings).
All except the T400/P8400 were running Mint, with that one running Lubuntu.
In the interest of fairness, I will concede it’s not specifically a Renoise ALSA implementation bug, but I would suggest based on my limited testing that the default options that Renoise ships with for Linux seem to be problematic in many cases (which is why you all have your favourite work arounds, which is great, but please consider the experience of new users).
I propose that it would be better if the defaults were set to the above instead of 44.1/256/3. This would, at the very least, allow people to use the ALSA default device immediately and not have to spend several minutes/hours of their time searching and trying to figure out what the settings should be - and being led down the path of having to choose their own weird audio config (I don’t want to use Jack, I just want audio to work out of the box) or told to “install a different distro bro”.
I’m sorry if I’ve come across as difficult/stubborn, but I’ve intentionally focused on the problem of Renoise not working out of the box, compared to every other bit of software I’ve tried which managed to work without crackling. When I suggest that people use Linux, and tell them Renoise is great, I would like to think that they can just install Linux and download Renoise and it works, rather than report back and say “yeah I tried it, the sound didn’t work, I tried Googling but I got confused and went back to Windows”.
I realize I’m just one guy, I’m not on the dev team, and everyone else is using something else (Jack?) instead of the ALSA default system device, so you probably think I’m weird, but I’m sincerely just trying to make the experience better by default, because I noticed the problem ages ago and always opted to use the direct device which worked, but also meant Firefox would stop playing videos due to no sound etc, and made Linux a sub-optimal experience.
It’s only with the Windows 10 cut off coming up that I decided to nuke my final Windows build and be 100% Linux, so this was something that bugged me and I wanted it to be resolved.
If the defaults were sensible/functional out of the box, that would be FANTASTIC, otherwise I’ll have to remember those settings and keep applying them every time I install, which is definitely possible, but not ideal. It would also save other users having the same issues, and not give Renoise/Linux a bad name.
Given the low specs of the machines I was testing on, I can only assume that most people are using better machines than these, and should have no trouble with the same settings. Thanks to everyone who has offered their suggestions (and again, I apologize for being grumpy in my responses) - if any of you would like to test the same settings on your machine (ALSA default, 48k, 256 buffer, 2 periods) and confirm that they also work for you (or not), that would go a long way to verifying if these settings work globally and not just a “Works for Me on my 4 computers” situation.
2 Likes
That seems like a constructive suggestion. Thanks!
1 Like
Sometimes it’s not easy, but with time everything will work out :).
I have installed a Linux system for ages (rolling distro) and so I already have everything set up.
Internal sound card disabled in bios, realtime kernel, IRQ hacks in kernel parameters, etc.
During that time I have probably tuned the sound in Linux.
Unfortunately, as I wrote, this does not apply on the same PC for Win11 (dualboot).
I have problems with sound there. Interestingly, it does not appear in games 
Hi d2TiTus,
I was reading your topic, and realize some things I want to share.
The main problem is, i think, because the use of an normal Kernel in Linux. So, just like you, I ran into some problems.
But the first thing what is important, is the use of a good supported and well known sound card, so from the beginning I was aware of this. I never complain if something is not working out of the box with an normal sound card (the ‘built-in’ sound devices in a laptop or normal PC).
If I go back to the end of the ‘90s, I already decide to not use the default sound cards on board of the system.
My first sound card one was the Gravis Ultrasound. Later on the Sound Blaster, but from 2005 and still today (the same card for almost 20 years now) the ESI Juli@ (PCI version).
This German product, ESI Juli@ (Juliet), is very good of quality. I have it for 20 years now, it still works. It contains everything I want: MIDI IN/OUT, SPDIF connectors, analogue outputs.
They still support this card, there are Windows 10/11 drivers also for this sound card. What do you more? Support for the 20 years old product, it’s amazing!
So, back to my vision about this: I ran into some problems, and open the support page on Renoise support about Linux & Renoise. I did exactly what it says, and my problems are solved.
I run a low latency kernel, and that makes a difference. Because I thought the real time kernel was the way to go, but it can slow down your system some bit. The low latency is the best option in my opinion, not the RT kernel.
The RTCQS tool helped me a lot.
Running from the CMD (command line interface), it checks the things that are important to get good audio. Some things like: “not a good idea to mount the /boot dir”, is something that you can ignore, because otherwise the kernel won’t load. The kernel is stored there.
And the “Preemt RT” is also something I ignored. The rest in this GUI is green, and good to go now.
So, in general, and in short: avoid the use of the internal sound card, buy a good quality sound card (internal/external USB, etc.), use the low latency kernel in Linux.
That’s my experience, I hope your system is now up and running without any issues.
In my Renoise 3.5.2 preferences, the device type is ALSA, in/out: default system, sample rate: 48 kHz, buffer size 32 ( 2.0 ms latency ), periods/buffer: 3.
No glitches, no ticks, all ok!
Cheers. 
I recently installed Kubuntu and it came with pw-jack, so I never had to use ALSA. But I understand you wanting to stick to it. I’ll test these settings and see how they behave in my system.
Just wanted to chime in here with my experience as a potential new Renoise user.
I have a Thinkpad X1 Nano with an i7 running Ubuntu 25.10. I downloaded Renoise, started it up, and tried a couple of demos and they did not work. They’re extremely garbled to the point I can’t even tell what they’re supposed to sound like.
I got this message at startup and of course just tried to ignore it because I don’t even know if I want to use Renoise yet:
“Failed to create a RealTime priority thread for ALSA. Will create a non RT thread instead… It is highly recommended to use RealTime priority audio threads with ALSA AND Jack to get acceptable audio latencies, but you may need admin rights to create RT threads. Please see the Renoise for Linux FAQ on https://www.renoise.com for more details.”
Could this just link to: https://tutorials.renoise.com/wiki/Linux_FAQ#Realtime_Threads ? Ideally as a clickable link?
I then went through that process, and saw no noticeable difference.
I came across this thread and decided to try 3.2.2 as suggested and the demos work fine.
I don’t know if any of the developers are in this thread but many people here seem to be overlooking what @d2TiTus is trying to say: In a previous version, the “out of box” experience was significantly better, someone could at least do some initial evaluation before deciding if they want to go further, setup Jack, purchase a license, etc.
I understand that supporting Linux is difficult to do commercially (because I do so at work) due to the fractured landscape and seemingly infinite configuration possibilities and software combinations. Which is why, like @d2TiTus I wanted to add my feedback and first impressions because I like seeing projects like this that at least try to support Linux.
hey @tdilly
three steps.
1.) Configure your system to allow realtime audio: How do I configure my linux system to allow JACK to use realtime scheduling? | JACK Audio Connection Kit
2.) in the renoise Audio ALSA settings in the preferences, choose the actual sound card, instead of the “default” device. This started with 3.4 or 3.5 - renoise could now also use the main system software mixer, but it will not be very realtime-stable. Selecting a distinct sound card, will allow exclusive access.
3.) raise buffer_size to a high value (>1024) and buffer_periods you can also raise to 3 or 4. This will make renoise have a longer buffer and it can prevent dropouts.
Hppy Trckn!
1 Like
Also @tdilly, let me know if the settings I suggested (48k, 256 samples, 2 periods) work for you - I haven’t had much feedback from others, so while they work for me, it would be good to hear if they are useful as initial settings universally.
Thanks for your comments - I appreciate the support for a good initial experience, and I’m glad that someone else gets it.
Changing the output device from System Default Device to the specific device (hw:sofhdadsp,0 for me) seemed to resolve the issue. Changing the other settings didn’t seem to make much difference on their own.
1 Like
Hi D2TiTus, I have already react on your topic (see reaction above), but I want to react to your suggestion to let you know the experiences.
I have set my audio settings from JACK back to ALSA, and your suggestions (48K, 256 samples, 2 periods). Works perfectly, no problems, while I writing this, I play a track for a couple of minutes. I switched to the browser and back, and do other things with Renoise playing in the background, to give the system a little stress but still stable.
So yes, it works for me also.
1 Like