Strange issue here that only happens with Renoise. I put several instances of DIVA (also tested with other CPU hungry plugins like Cadmium) into Renoise to increase the DSP load to ~50%. When using Renoise with Jack I get crackling in the output, but these crackles are not caused by xruns. There are no xruns and when I record the output there are no crackles. Usually I’m using Cadence from KXStudio . I tried to disable the pulse audio bridge, etc. but the issue is not related to anything I tried. It also is not affected if the Renoise GUI is open or not. Also the frame rate does not play any role. Sandboxing changes also nothing. It seems that I can even increase the crackling by scrolling large webpages or opening programs. I did the same test in Bitwig in there I don’t get crackling at ~50% load.
When using plain ALSA there is no crackling.
Could anyone please try to reproduce this? You just have to use a preset that isn’t to noisy, e.g. a sine pad or something. So you can hear it better.
Problem occurs with the stock Debian kernel and also with the RT PREEMPT kernel.
System is configured to RT audio and the realtimeconfigscript tells me that everything is fine (see below).
In addition I’m using https://alsa.opensrc.org/Rtirq to handle the interrupts.
Soundcard (xhci) is running with priority 95 and Jack with 80:
PID CLS RTPRIO NI PRI %CPU STAT COMMAND
201 FF 95 - 135 5.5 S irq/28-xhci_hcd
235 FF 94 - 134 0.0 S irq/29-xhci_hcd
716 FF 50 - 90 0.0 S irq/27-enp2s0
9 TS - 0 19 0.0 S ksoftirqd/0
~/realtimeconfig/realtimeconfigquickscan$ ./realTimeConfigQuickScan.pl
== GUI-enabled checks ==
Checking if you are root... no - good
Checking filesystem 'noatime' parameter... 4.19.0 kernel - good
(relatime is default since 2.6.30)
Checking CPU Governors... CPU 0: 'performance' CPU 1: 'performance' CPU 2: 'performance' CPU 3: 'performance' - good
Checking swappiness... 10 - good
Checking for resource-intensive background processes... none found - good
Checking checking sysctl inotify max_user_watches... < 524288 - not good
increase max_user_watches by adding 'fs.inotify.max_user_watches = 524288' to /etc/sysctl.conf and rebooting
For more information, see http://wiki.linuxaudio.org/wiki/system_configuration#sysctlconf
Checking access to the high precision event timer... readable - good
Checking access to the real-time clock... readable - good
Checking whether you're in the 'audio' group... yes - good
Checking for multiple 'audio' groups... no - good
Checking the ability to prioritize processes with chrt... yes - good
Checking kernel support for high resolution timers... found - good
Kernel with Real-Time Preemption... found - good
Checking if kernel system timer is high-resolution... found - good
Checking kernel support for tickless timer... found - good
== Other checks ==
Checking filesystem types... ok.
** Set $SOUND_CARD_IRQ to the IRQ of your soundcard to enable more checks.
Find your sound card's IRQ by looking at '/proc/interrupts' and lspci.
I reduced the buffer size to 512 with 3 periods / buffer and it’s almost not crackling at all. Very very rarely only.
The CPU usage is comparable to 1024 samples. So maybe this points to what the problem is?
Crackling without xruns with Renoise and my interface Zoom R8 when using Jack at DSP loads (shown in Jack or Renoise) > ~55%.
No issues with Bitwig / Zoom R8 / Jack
No issues with Renoise / ESI DAC interface / Jack
No issues with Renoise / Zoom R8 / Alsa
The problem with the combination Renoise / Zoom R8 / Jack gets even worse when I increase the buffer size from 1024 to 2048 samples. It becomes better when I reduce the buffer to 512 samples. Which is strange.
When I reduce the Multi CPU setting from 4 to 3 it also becomes better. I tried to figure out via IRC what the problem is but I absolutely have no clue. Why does Renoise behave different than Bitwig and why is only one interface / DAW combination affected?
Another thing I just observed: I’m using rtirq to handle the IRQs (https://alsa.opensrc.org/Rtirq).
When I set Renoise to 3 CPU cores I get much better results (less crackling) when IRQ handling is enabled,
i.e. the soundcard (zoom) is set to priority 95
189 FF 95 - 135 3.8 S irq/28-xhci_hcd
224 FF 94 - 134 0.0 S irq/30-xhci_hcd
9 TS - 0 19 0.0 S ksoftirqd/0
When I stop rtirq (sudo /etc/init.d/rtirq stop) crackling is much worse.
@taktik: Do you have any idea what can go wrong here? Is it a Jack issue or a driver / kernel problem maybe?
“The ESI DAC has Adaptive endpoints. Adaptive endpoints are usually tolerant to a larger packet rate drifts than Synchronous ones. So maybe Renoise with jack causes some specific load on the system that affects mostly devices with Synchronous endpoints (like the Zoom R8). In this case my suggestion to decrease MAX_PACKS value or even try to apply implicit feedback quirk still stands.”
Bought a new interface (Roland Rubix 24) and the same issue with Renoise as described above. Now it also occurs with Alsa so it’s a more general issue.
What I did: I tested some older Renoise versions and from 2.72 to 2.8.0 (i.e. with 2.8.0) it is getting worse:
With 2.72 I get crackles at high DSP loads, but these also correlate with xruns.
With 2.80 it’s crackling much more (tested with the same file of course) and I get less xruns. So it’s crackling without getting any xruns sometimes.
When using 3 CPU cores instead of 4 or lowering the buffer size from 1024 to 512 it is getting much better.
No issues with Bitwig or Reaper.
Only when using an ESI nano DAC (which has adaptive endpoints) it’s fine.
Maybe someone can reproduce this or do you have any hint why this happens @taktik?
I once had similar crackling in linux. No Xruns, but crackling sound, iirc. All tuning was properly done, rtirq, scheduler, and other kernel and cpu mode tunings. Are you sure that you use the right usb irqs where the sound card is actually hooked into?
I then went deep down the rabbit hole, and ended up using kernel tracing to try to find out which kernel process was disturbing the sound thread. Sorry, I cannot recall the detail on what and how I had done, it was quite some journey. It had turned out that the open nvidia video card driver kernel module was sporadically blocking for more than usual time, and thus the sound threads were late sometimes. I then installed newer kernel with newer video card driver - issue got fixed, no more crackling.
However while tuning, I found that renoise seems to make problems with very low latency, say sub 8ms. But above 10ms it should be stable.
Edit: maybe try to boot up bypassing the gfx driver, like with nomodeset boot option. Might fuck up your desktop resolution, but this way you might see if the gfx driver is the problem.
I have rtirq running which gives the interface a priority of 95, jack is running at 80. And everything else is (as far I can tell) optimized. I’m also using a RT PREEMPT Kernel from the Debian repo.
There’s a xruncounter script that checks at which DSP load the first xruns appear (https://github.com/Gimmeapill/xruncounter). When running it I regularly reach >95%, which is good I guess.
In Bitwig for instance I get some occasional xruns, caused by CPU / DSP spikes. I assume it comes from Bitwig as with Reaper everything is fine. Other people also mentioned it at KVR.
I have an onboard graphic chip, which should not cause any issues. And the interface is connected to an USB hub (the internal mainboard hub) where no other device is connected to.
As there’s a difference between 2.72 and 2.80 maybe taktik can tell. It’s not really a big issue, because when DSP loads are exeeding 50% I get xruns sooner or later, cause that a highly averaged number.
But in case you have linux and maybe even DIVA I can send you a file to check it on your system.
I open Renoise, load my file and hit play. It is set to 4 CPU cores. CPU load in Renoise goes up to 60% with occasional xruns. When I set it to 3 cores the CPU usage goes to ~65% and I don’t get any xruns.
Now the strange part: When I set it back to 4 cores the CPU usage goes down to 50% and the xruns are also gone. It’s also reproducible.
Well, sorry I can’t be of further assistance. For me Renoise runs just fine using my ubuntu systems.
Just one thought left…
You are using debian with an (old) longterm support kernel. And your machine is rather new. I know the linux driver ecosystem usually takes some time for good stable support of new hardware. Maybe you could try using a distro with more recent kernel/driver stack. Just try it, maybe the crackling will be gone. And don’t overestimate all the realtime kernel and tuning stuff. It is nessecary for very low latencies and then dropout free operation. With just a lowlatency (or even generic) kernel and cpu governor and rtprio/rtirq tuning renoise should run fine and stable at 15-30ms latency
I don’t think it’s a kernel thing. A difference a found between Bitwig and Renoise: Renoise uses all 4 cores to the same extent while Bitwig put a higher load on the first 3 cores. When I set Renoise to 3 CPUs I may get the same like in Bitwig? Renoise works also much better in Renoise with 3 CPU instead of 4. Just a guess …
It is maybe a sign that graphics or os is in the culprit somewhere. There is also the tip to set renoise processing to number of cores minus one, so one core is free for graphics/os tasks.
Well but just try to use your system with a newer kernel. Then you will see. Even if the machine is not newest - hardware support in linux is an incremental process, with hardware support for a device getting more and more with the months, as user report problems and things eventually get fixed or tuned. As for realtime scenarios things are even slower, because not many linux users do realtime tasks.
I do only rarely get xruns with renoise running with jack, or rather, I only get them when the renoise cpu load is very high. I don’t use plugins though.
“There is also the tip to set renoise processing to number of cores minus one, so one core is free for graphics/os tasks.”
Do you have a link where this is suggested? I wait with backport installation. As Bitwig and Reaper are really working without issues I don’t think it’s due to the kernel.
If setting CPUs to 3 (intstead 4) is the solution that’s the solution.
Reaper on the other hand handles things much different. Bitwig and Renoise are comparable regarding DSP Load when using the plugins and notes, but Reaper is much more efficient.
I was testing it with Debian 10 (same kernel) on a laptop and the Zoom R8. -> no problem …
So I assume that it’s caused be some settings on my other PC.
yeah some buggy driver must be messing with the sound processing. will be a tough job to find the problem. that’s why I suggested to just try very recent kernel -> highest chance of such problems are fixed. might as well be the pc bios, sometimes updates can fix problems like this.
It was the threadirqs boot option I added because of RTIRQ. It was not set on the other laptop.
I just don’t understand why this affects Renoise in such a way. Anyway, I think with Renoise everything is fine and the problem is on my side. As soon I know more I will add more info.
As you said I think this RT tuning stuff is not necessary for me as I can live with a latency of 10-20ms. Most important is to set the CPU governor to performance, to put the user into the audio group and to edit limits.conf.
…