Excessive XRUNS with Ubuntu Studio, jackd and Ardour.

Moderators: MattKingUSA, khz, muldjord, deva

Post Reply
XRunner
Established Member
Posts: 6
Joined: Sun Dec 22, 2019 9:26 pm

Excessive XRUNS with Ubuntu Studio, jackd and Ardour.

Post by XRunner »

Hi:

I recently switched from Hydrogen to DrumGizmo. Using the stock DrumGizmo install in Ubuntu18 (two years and a half old) I downloaded both the Crocell and Muldjord kits and did the neccesary changes to my MIDI files so I would trigger the correct samples and loaded DrumGizmo as an Ardour plugin. When using the Crocell kit (in a 44k session, which I guess needs resampling) I got so many XRuns that the Ardour GUI froze when adding markers. Using the Muldjord kit I got better results, but still a lot of XRuns. These XRuns are accompanied by crackling noise, noise artifacts and plain noise when my computer cannot just keep up.

Following advice from an IRC member, I compiled the latest DrumGizmo from source and got marginally better results, but still a lot of Xruns on playback. I may be misinformed but it is my understanding that no XRuns should happen in a stable system (in fact, I got no XRuns in my previous workflow, which would route the MIDI data to Hydrogen and some other synths). The beat I am playing consists on 4 measures of snare count and a steady blast of 16th notes, three notes at a time, at 260BPM. The XRuns start with the blast.

A couple of interesting bits:
- Setting the buffer size to 2048 (from 256) made the XRuns decrease just a little bit.
- had DrumGizmo directed to just two Ardour buses. When I used 16 buses the XRuns decreased, but are still there.
- Setting the buffer size to the original 256 value with 16 buses still cause a lot of XRuns.

My current specs are:

Code: Select all

Processor:  Intel(R) Core(TM) i3-7100 CPU @ 3.90GHz
RAM (free -m): 3831
External audio card: FocusRite Scarlett 2i4. (there's a crappy onboard card too).
Ubuntu Studio: Ubuntu 18.04 LTS.
DrumGizmo v: drumgizmo-0.9.18.1
Jack settings: 44100 - 256 frame - 3 periods, 95 priority, realtime
.

I tried generic XRun stuff (to no avail) like:

- Removing the wireless USB stick.
- Using a single display
- Setting "realtime audio" and "CPU governor in performance mode".

My question: is this the expected behaviour of the plugin? Is there something I can do to get better performance? Of course, if you need any other data I would be more than happy to oblige.

Thanks a lot in advance.

User avatar
English Guy
Established Member
Posts: 473
Joined: Wed Oct 17, 2012 7:28 pm
Location: England

Re: Excessive XRUNS with Ubuntu Studio, jackd and Ardour.

Post by English Guy »

I found pulse audio was still impacting performance. I changed the settings to stop it respawning and start and stop it as needed with commands. (I put the commands into qjackctl 's settings)

XRunner
Established Member
Posts: 6
Joined: Sun Dec 22, 2019 9:26 pm

Re: Excessive XRUNS with Ubuntu Studio, jackd and Ardour.

Post by XRunner »

I tried preventing pulseaudio from spawning and stopping it through a stop script:

Code: Select all

#!/bin/bash
echo autospawn = no > $HOME/.config/pulse/client.conf
pulseaudio --kill
rm $HOME/.config/pulse/client.conf
and a start script:

Code: Select all

#!/bin/bash
#This is redundant, I know :).
pulseaudio --start
After running the stop script I can do:

Code: Select all

pulseaudio --check; echo $?
Will give me "1" until I run QJackCtl (which I use to start jackd), which seems to start it over again, causing "0" to be returned. Actually, running

Code: Select all

jackd -d alsa --help
seems to start it again (makes it return 0)... The only audio source I have connected is the Scarlett USB interface, so I can't be sure that pulseaudio is, indeed, dead... In any case, still got XRuns, the same performance as before, I'd say.

Did you notice this performance problem only with DrumGizmo or did it affect other applications?. I never experienced any other problem in either Hydrogen or any of the soft synths I ran.

Thanks for the input.

User avatar
deva
Established Member
Posts: 141
Joined: Sun Oct 23, 2016 10:15 am
Contact:

Re: Excessive XRUNS with Ubuntu Studio, jackd and Ardour.

Post by deva »

You can try a few things within the drumgizmo ui itself:
- Increase the diskstream cache size to ease the lod on the sample loader if you harddrive is the reson for the produced hick-ups.
- Disable the resampler (there's a checkbox for that) which will change the timbre of drums slightly if you run a 44k1Hz kit in a 48kHz session (or vice versa).

In general, running drumgizmo with resampling with very low jack buffer sizes can give xruns. I usually try to avoid resampling altogether and usually run with 2048 samples buffer size in jack.

Not mapping some of the output channels will have zero effect on the performance as drumgizmo renders all the channels anyway.

XRunner
Established Member
Posts: 6
Joined: Sun Dec 22, 2019 9:26 pm

Re: Excessive XRUNS with Ubuntu Studio, jackd and Ardour.

Post by XRunner »

Thanks for reaching out Deva.

I tried both approaches yesterday and didn't get good results.

First, disabling resampling (or switching to a new 48k session, or using the Muldjord kit at 44k) got marginally better results, but still was unusable. Using a very large buffer size still gave me Xruns and artifacts (a fraction of what I had before, tough).

Second I tried with unlimited cache size and it made most GUIs on the computer freeze. Some other sizes like 2GB gave me mostly the sams results. A very large Jack buffer was the better (still faulty) option.

One thing I also tried was to lower the BPM from 260 to 140, in case it was too much for my computer. Unfortunately I ran into Xruns too.

I guess I can try a smaller kit but perhaps I should direct my inquiries towards the kind of workflow that other users have. Do you use DrumGizmo "live" as you draw your MIDI events and play them back? Perhaps the plugin is too CPU intensive and recording to audio tracks (freeing the plugin afterwards) is the way to go?

I have devised an alternative (light kits on Hydrogen while setting up the beats and recording the live instruments, then using DrumGizmo for the "real" take) but I can't shake the feeling that something is off.

Thanks for the input. Very much appreciated.

PS: given than I got the attention of a developer and being a developer myself, perhaps I could help with some development tasks, you know, give back to the community a bit. Just in case you want to PM, my experience is mostly in C++, Linux, SDL2 and systems programming.

User avatar
deva
Established Member
Posts: 141
Joined: Sun Oct 23, 2016 10:15 am
Contact:

Re: Excessive XRUNS with Ubuntu Studio, jackd and Ardour.

Post by deva »

I think I have a few more ideas for what you can try, and even thought of a new feature which might be able to help in this use-case.

I'm not using DG myself for live playing, but I know a lot of people do use it like that, so it should be possible.
Have you tried running it in stand-alone jack mode instead of running it through Ardour? I'm aware that will remove the option to use plugins on the output channels but it should cut down heavily on the system resource requirements.

I think the reason why you experienced UI freeze with the cache option set to unlimited is because of swapping being activated. You should try to find a sweet-spot, where the swap is not utilized and the memory is maxed out.

You can try the Shitty-kit from the website, just to see if that changes anything. It is by far the smallest kit we have available. CrocellKit on the other hand is by far the biggest one...

IIRC the Intel i3 CPU does not have multiple cores and no hyper-threads either (ie. no real multi processing capabilities). DrumGizmo uses one thread (the one from the DAW) for audio processing and a second one for loading the samples into the cache. If there is only one core available it might give better results with different kernel schedulers. Also using real-time patches for the kernel and making it preemptive might make a difference.

The actual problem is that playing a blast-beat at 260 bpm on the ride cymbal will at one time be playing ~10.000 samples simultaneously, increasing with the length of the samples and the length of the blast-beat.
This is because DrumGizmo has no notion of "voices" and will happilly play as many simultanious samples as you instruct it to - until it starts producing xruns.
The feature I am thinking of it to add a per instrument max number of "voices", where you can instruct it to play at most, for example, 4 ride cymbals at once and the moment you activate number 5 it will choke (ie. gradually mute) the "oldest" one, which probably cannot heard anyway because of the 4 more recent ones already playing.

If you jump on IRC we can talk further about it, as well as your interesting PS proposal :-)

XRunner
Established Member
Posts: 6
Joined: Sun Dec 22, 2019 9:26 pm

Re: Excessive XRUNS with Ubuntu Studio, jackd and Ardour.

Post by XRunner »

Hi Deva:

I am at work (break time) at the moment, so I won't be able to jump in an try your suggestions, but will definitely try both the stand alone mode and the "shitty kit", as well as a more relaxed beat, since they are my most immediate options. Of course, if beat and voices themselves turn out to be the problem, such a feature as the one you mention would be great to reduce CPU load, not only in my case, but also for all users.

As for the hardware itself, if it helps, I will check when I get home. The product page at Intel says that this thing has 2 processors and 4 threads per processor, but hardware is hardly my field of expertise.

In any case I will try to investigate the matter further as soon as my schedule clears (holidays and children are a very bad recipe to sit in front of the computer). As for jumping into IRC, I will give it a try, at least to setup further chats.

Cheers.

XRunner
Established Member
Posts: 6
Joined: Sun Dec 22, 2019 9:26 pm

Re: Excessive XRUNS with Ubuntu Studio, jackd and Ardour.

Post by XRunner »

Good people of DrumGizmo:

I took some time to run more tests and got very reasonable results. The key seemed to be the CPU governor set to performance mode (I don't know why Ubuntu Studio resets this value when I restart my machine).

I ran all tests using the VST plugin, two displays, showing the main Ardour and mixer screens plus QJackCtrl. I ran them separatedly in the Muldjord and Crocell kits, with the default velocity and timing humanizers and sample selection. For the Crocell kit, I turned off resampling too.

For the Muldjord kit:

- Cache: 2200MB, buffer size: 256, 120BPM, got 4(7) Xruns, no glitches. This is the only test I did at 120BPM.
- Cache: 2200MB, buffer size: 256, 259BPM, 1(3) Xruns, ever so slight glitches. Seems that having loaded the samples in the previous test helped.
- Cache: 2200MB, buffer size: 512, 259BPM 0(1) Xruns, good quality.
- Cache: 2200MB, buffer size: 1024, 259BPM 0(0), good quality.
- Cache: 2200MB, buffer size: 2048, 259BPM 0(0), good quality.
- Cache: 1200MB, buffer size: 256, 259BPM, 2(5) Xruns, small glitches.
- Cache: 1200MB, buffer size: 512, 259BPM 0(1) good quality,
- Cache: 1200MB, buffer size: 1024, 259BPM 0(0), good quality.
- Cache: 1200MB, buffer size: 2048, 259BPM 0(0), good quality.

So, buffer size seems to be the most important factor here.

For the Crocell kit:

- Cache: 1200MB, buffer size: 512, 259BPM 19(205), lots of glitches that become noise. A very large change from the Muldjord.
- Cache: 1200MB, buffer size: 1024, 259BPM 10(33), glitches that become noise.
- Cache: 1200MB, buffer size: 2048, 259BPM 2(9), some glitches, specially in fast fills.

However, as soon as I turned all "sample selection" values to 0 I got 0 Xruns in the Crocell at 2048 buffer size, so I guess we can blame my disk drive or the huge number of samples in the Kit. In any case, I am sure I can work with the Muldjord kit without hassles. I just wonder now if a "Freeze track" (offline rendering of plugin audio to a static waveform) will be added to Ardour in a future release, so I can make use of the 8GB beast kits :).

In any case, I am willing to give a try to the voice limiting feature. I hope my experience can help other users of DrumGizmo.

Cheers.

User avatar
bluebell
Established Member
Posts: 1245
Joined: Sat Sep 15, 2012 11:44 am
Location: Saarland & Frankfurt, Germany

Re: Excessive XRUNS with Ubuntu Studio, jackd and Ardour.

Post by bluebell »

XRunner wrote: I took some time to run more tests and got very reasonable results. The key seemed to be the CPU governor set to performance mode (I don't know why Ubuntu Studio resets this value when I restart my machine).
/etc/init.d/ondemand from the package "initscripts" (can't be removed safely) waits 60 seconds and then screws up your governor settings.

I had to tweak it on all my Ubuntu machines used for audio production.
Linux – MOTU UltraLite AVB – Qtractor – https://soundcloud.com/suedwestlicht

XRunner
Established Member
Posts: 6
Joined: Sun Dec 22, 2019 9:26 pm

Re: Excessive XRUNS with Ubuntu Studio, jackd and Ardour.

Post by XRunner »

bluebell wrote:
XRunner wrote: /etc/init.d/ondemand from the package "initscripts" (can't be removed safely) waits 60 seconds and then screws up your governor settings.

I had to tweak it on all my Ubuntu machines used for audio production.
Didn't know that. I will look into it :).

User avatar
JamesPeters
Established Member
Posts: 86
Joined: Fri Jun 29, 2018 6:35 pm
Contact:

Re: Excessive XRUNS with Ubuntu Studio, jackd and Ardour.

Post by JamesPeters »

The voicing limiting feature is a great idea. I know several people who have struggled to get solid performance with DrumGizmo, and I know from my testing that having multiple samples of the same kit piece continually playing ("stacked", as the decay is still happening) affects it a lot. This is compounded with the fact that the larger kits on the DrumGizmo site are all playing bleed in every audio channel all the time. I'm working on a kit which has between 4 and 7 channels per kit piece depending on what it is (room and overhead buses, but no bleed); its performance makes a lot less demand on the CPU.

Post Reply