xruns(this discussion is not for smart ass remarks, it's to help each other)

[funkmuscle]

OK, I hear that xruns causing audio drops and destroys your recordings, drop outs, etc.
I use Drumgizmo and some tracks are crazy busy.
I use either Ardour (mostly) or Reaper to record from midi to audio. I get crazy xruns if the drums are doing anything crazy especially in Reaper.
Reaper is so bad that it seems to slow down while recording the audio tracks that I turn down the volume due to the cracking, popping and hi-pitched squeals. Ardour is not that bad but still, say one bar of busy drums and I'll get about 500-600 xruns.
The reason I'm posting this is to ask about audio loss (even though if anyone has suggestions of fixing this I'm all ears ).
When I would listen to that audio, I notice no loss in audio quality. The drums sounds exactly the way they should.
Remember we're making music and not all are engineers who will sit there and scrutinize things. I've played stuff for my music fans friends and they all say stuff sounds like what they hear on the radio and so on. Even my musician friends who don't do their own recordings. So besides the annoying noises and the sometimes impossible working environment xruns create, should we be crying over xruns and audio quality?
I mean you'll get guitarist who will listen to what I'm playing looking for mistakes or where I've punched in a correction in a guitar solo but when you really thing about it, they are more music lovers than musicians.
They are critics yet they are more who just wanna enjoy the music or whatever creative folks create. I'm just saying that the average listener will not notice the audio drop offs caused by xruns. I have never noticed xrun drop-offs.

So maybe we should just keep on making music instead of fighting an issue that seems to be there no matter what! I've noticed this has frustrated many and gets in the way of us being productive because we waste time trying to solve it
...but again, if any fix for reducing this issue I'm still all ears for the solution.

[merlyn]

As a general principle if you're getting Xruns put the buffer size up.

DrumGizmo is a special case. There was a discussion in the DrumGizmo sub-forum about overlapping samples. A very busy DrumGizmo part results in many, many samples overlapping which is a lot to calculate. An Xrun happens when the buffer can't be calculated in time.

Also Xruns can happen on recording or playback. Xruns on playback are unpleasant but they won't end up on the exported audio unless the audio is exported in realtime. Unticking 'realtime' on the export allows as much time as is required to calculate the output without Xruns.

Xruns on recording are a problem. That means the recording buffer had a gap in it when it was written to disc and that will always be there. (This could be repaired in audacity if the bursts of Xruns are small).

Ardour creates markers where Xruns have happened on recording and there is an option to stop recording if there are Xruns. I think that shows that Xruns on recording are to be avoided, but Xruns on playback don't affect the finished product if the export is not in realtime.

[ufug]

The reason I'm posting this is to ask about audio loss (even though if anyone has suggestions of fixing this I'm all ears ).
When I would listen to that audio, I notice no loss in audio quality.

I have wondered the same thing! I understand what an xrun is, but I would like to know why some are problematic and others are not. I frequently get some xruns during a session, maybe a dozen or 20. But I almost never get an audible click, even when tracking audio. So I don't worry about it.

I used to have Ardour/Mixbus set a marker on xruns, but I stopped doing that because if there's no perceivable problem, there is no use. It would be nice to see a marker added only for real clicks/audible artifacts.

If an xrun falls in the forest...

[merlyn]

To clarify -- when I used the term 'Xrun' above I am referring to an audible click.

[CraigPid]

Maybe not really the answer you were looking for... I tried using drumgizmo a couple of times and had a similar situation. To get around it I recorded the midi tracks to audio tracks and then archived the midi tracks.

[JamesPeters]

To keep CPU lower, try to not use resampling in DrumGizmo. Set your project sample rate to whatever the kit's sample rate is.

Also if you have enough RAM to load the entire kit, set the disk streaming slider all the way up (so it won't disk stream). That should help.

The timing humanizer might be messing things up slightly too, when it tries to "go back in time". Basically it needs to add latency to the plugin when doing that. If you play it realtime (with a controller), you can encounter problems. I try to use plugins with zero latency as much as possible, reserving use of plugins that have latency for mixdown/mastering only. In Reaper you can see how much latency the plugin is adding by looking at the fx browser window, at the bottom left beside "CPU" (you'll see "xx/xx spls"). The minimum latency possible for a plugin is your audio device driver's blocksize (so for me, 64 samples is the minimum latency since I use 5 periods of 64 samples in ALSA in Reaper). So even if a plugin calls for 3 samples of latency, Reaper needs to compensate for the minimum blocksize of 64 in this case. So beware of that.

Some DrumGizmo kits that I've seen use all 16 audio channels for every kit piece (proximity, room, and bleed for everything). That plus they sometimes have long decays for the samples. So imagine all those audio channels playing, and "stacking" since currently there's no automatic "killing" of overlapping voices (hit a cymbal 10 times quickly, all 10 times are going to ring out completely using all 16 audio output channels). This particular challenge is probably going to be addressed in a later build of DrumGizmo (see this post in particular in the last couple paragraphs).

And if you use a drum kit that doesn't have bleed on every channel, and shorter decays for some of the samples, that'll help. I'm making a kit which uses between 4 and 7 channels depending on the kit piece, and the decays are more modest in length. (It had been put on hold for a while but I'm finishing it soon.)

Also, in Reaper, using the realtime process too much can bog down the CPU. There's a certain thread which needs to be reserved so everything runs realtime. Normally you can run lots of plugins since Reaper is very efficient with CPU, but if you bog down the realtime process you'll have problems. Here are 2 things to consider:

-An opened MIDI editor can demand more of the realtime process. You can change this behavior to some extent by opening preferences and going to Audio -> Buffering and look at those options. I have my "behavior" set to 2, and "disable media buffer for tracks with open MIDI editors" checked. Besides that my settings are stock (on that page). Also you can close the MIDI editor if you're not editing the MIDI at the time (when recording and/or playing DrumGizmo from a controller).

-A record-armed track (with monitoring) will demand more of the realtime process. If you don't need that (if you're not playing drums from a controller, and are only programming MIDI with the tools in Reaper), turn off the record arming and monitor. For that matter, turn off record arm for any track you're not actually recording. I think by default in Reaper 6, it automatically arms a track and enables monitoring when added to the project. That behavior can be changed in preferences under Project -> Track/Send defaults ->record arm (and under Record Config make sure you don't have monitoring enabled by default).

[CrocoDuck]

It happened to me in the past to have xruns while recording, and not being able to hear them in the recorded track.

The opposite also happened to me: they were clearly audible in the track.

Finally, it also happened I could not notice any click in the recorded track at first, only to hear them when I listened again to the track with less fatigued ears, or after having changed the mix or while listening on another system.

The last one is pretty concerning to me: recording something with sneaky clicks in it that are not completely obvious, but that can be heard in some unlucky circumstances.

Hence, to avoid becoming paranoid, and listening to my track over and over to check whether the xrun results in audible stuff, I just decided not have xruns in the first place. It gives me peace of mind, and the ability to focus on what really matters.

[TAERSH]

It happened to me in the past to have xruns while recording, and not being able to hear them in the recorded track.
The opposite also happened to me: they were clearly audible in the track.

I can confirm this also. In e.g. Audacity, when zooming in to the recorded wave, one can view also the xruns.
But I also experienced another issue.
I composed two songs of a length more than 30 minutes. One is 32 minutes the other 39.
Both are using MIDI and Audio. Sequencer is Qtractor. Vocals are also recorded.

The more the end of the song is near, the more the Audio and MIDI went out of sync.
Since the day I switched to the use of a real time kernel all of those issues are gone.

I'm using either 4.19.15-rt12 or 5.0.21-rt15.
Both are 64bit kernels and I'm using these kernels also on my 32bit systems.
Both are taken from Studio 13.37 (3.2 & 3.3).

[rhydermike]

Best of luck sorting this out. I had ridiculous number of xruns recently when troubleshooting a new setup, and what helped was making sure that the CPU governor was set to "performance" rather than "ondemand".

There's a script that you might already know about at:
https://github.com/raboof/realtimeconfigquickscan

that run a check of your system config for audio.

[glowrak guy]

In rare cases, software doesn't handle cpu multi-core/multi-thread properly.
My temptation is to max out all the priorities for audio, use all the
cores/threads available to process it, and then some OS call in the shadows
gets short shrift and causes a problem.

So in qjackctl, my priority is 70, a bit lower than the /etc/security/imits.d/audio.conf setting of 95 allows room for.
In Reaper, I never max out the number of available cpu's, and when using Kontakt plugin,
I use just one core, advised by the LinVst coder, as I recall, which made a good difference in removing xruns

In testing IK's Lurssen Mastering Console, I bumped up the frames setting to 1024,
at 256, it was all snap crackle and pop.

If a tune is a keeper, but some subtle clicks are heard, I playback the area
at slow speed in audacity to make it easier to pinpoint them.
Cheers

[S1gmoid]

You can use taskset to set process CPU affinity (ie. assign cores to tasks)... I believe this can be a very important part of a realtime or low-latency setup.