Help me get back to a functional DAW (Xruns Galore)

[lykwydchykyn]

So, I've been having these Ardour crashes on my arch/Core2Duo system, and a newer laptop (i5) became available and I decided to upgrade.

First, I just swapped out the HDD so I could just have the same install on newer hardware. The crashes seemed to have stopped, but I was getting Xruns with the exact same latency settings (my audio interface hasn't changed at all, scarlett 2i4). I tried going through the arch wiki pro audio page again and making any tweaks that hadn't been made yet before. I also went through the BIOS and disabled anything I didn't need (bluetooth, speedstep, etc).

Nothing seems to help. It's not just that there are XRUNS, the audio very audibly glitches out every 5-10 seconds. Even with no audio software running, I get xruns.

Now I thought I'd go more extreme. I put a fresh hard drive in the new computer and installed AV Linux today, so that I had a known quantity to work with. Did all the upgrades, rebooted. The glitching is still there. On the bright side, the errors in Jack are more verbose:

Code: Select all

JackEngine::XRun: client = PulseAudio JACK Sink was not finished, state = Triggered
JackEngine::XRun: client = PulseAudio JACK Source was not finished, state = Triggered
JackAudioDriver::ProcessGraphAsyncMaster: Process error
JackEngine::XRun: client = PulseAudio JACK Sink was not finished, state = Triggered
JackEngine::XRun: client = PulseAudio JACK Source was not finished, state = Triggered
JackAudioDriver::ProcessGraphAsyncMaster: Process error

That block of errors accompanies every glitch.

I'd hate to have to go back to the C2D machine, but I'm at a loss here. Anyone have any wisdom for me?

[TAERSH]

Hehe, in my humble opinion: Pulse Audio is CRAP!

That's why I'm running my OS completely without Pulse Audio. Only ALSA and JACK.

Only having one single Xrun directly after a heavy song is loaded into the DAW.

[sysrqer]

It's worth a try disabling pulseaudio socket service but I don't think that is the cause of the problem, I just had a quick search with that error and saw people getting the same end result without pulseaudio running.

What about without jack running, do you still get the glitches?

What are your jack settings?

[lykwydchykyn]

On the old system, I was running 128/2 @ 44.1 and getting about 6ms of latency.

On this system, I've had to back it off to 512/4 to get a reasonably low number of xruns, and the latency is horrid. I haven't messed with any of the other settings.


I can't figure out why this system is so crappy by comparison; it's a faster processor, more cores, more RAM, faster RAM, and newer HDD.

EDIT: Forgot to mention, disabling pulse had no effect.

[lykwydchykyn]

So I also tried a realtime kernel tonight. No difference.

What it did help me realize is that this laptop has an Nvidia graphics chip, which means not only that realtime doesn't work out so well anyway, but also that it may just be the GPU locking up the system periodically. That might explain why there are Xruns when nothing is actually running.

I've tried with and without the proprietary driver as well. no dice.

[sysrqer]

Maybe have a look in top to see if there is something happening when this happens? Nvidia can be problematic but shouldn't be causing this. I'm not sure what else to suggest.

Do the glitches happen when you're not using jack?

[Loki Harfagr]

A shot in the dark, on the systems I use an NVidia card on I always include these tweaks in the optimization launcher script:

Code: Select all

	nvidia-settings -a GPUPowerMizerMode=1
	nvidia-settings -a SyncToVBlank=0
	nvidia-settings -a AllowFlipping=0
	nvidia-settings -a XVideoTextureSyncToVBlank=0
	export __GL_SYNC_TO_VBLANK=0

[lykwydchykyn]

Do the glitches happen when you're not using jack?

I didn't think to try that, so I loaded up a file in audacity using ALSA straight to the audio interface. I get a glitch about every 12 seconds consistently.

I kept an eye on audacity's output, as well as the system logs (kern.log, daemon.log, syslog, etc.), but nothing is leaving a conspicuous trail. The absolute regularity of it seems to suggest some kind of hardware polling to me, but I haven't found it yet.

[sysrqer]

That's what my hunch was as well.

How about networking/wifi, can you disable that and try again with alsa?

[lykwydchykyn]

I pretty much disabled everything I could disable: wifi, nic, bluetooth, WOL, USB wake, even the optical bay. Only thing I left enabled was external USB (since that's required for my audio interface). I was really hoping it was just WiFi, but that doesn't seem to be it. I kind of think the USB implementation on this laptop kind of sucks.

Thanks for sticking with me on this one, it's pretty baffling.

I'm going to work on reinstalling the Nvidia driver so I can try some of the settings Loki suggested.

EDIT: nvidia tweaks made no apparent difference. Thanks for the suggestion though.

[tramp]

Last time I've had trouble like this because of a mobo upgrade was relate to Hyper-treading. I was forced to build a kernel with Hyper-treading switch off. Since then I've no problem any more, except that I need to build my kernels by myself.

Oh forget to mention that I also disable interrupts for the i2c_i801 module by using options i2c_i801 disable_features=0x10 on the kernel build. This gives me one more free IRQ so that the new order of interrupts gives my sound-card it's own IRQ.
That said, newer, more powerful computers may beehive real bad when it comes to real-time audio performance.

[lykwydchykyn]

Last time I've had trouble like this because of a mobo upgrade was relate to Hyper-treading. I was forced to build a kernel with Hyper-treading switch off. Since then I've no problem any more, except that I need to build my kernels by myself.

Oh forget to mention that I also disable interrupts for the i2c_i801 module by using options i2c_i801 disable_features=0x10 on the kernel build. This gives me one more free IRQ so that the new order of interrupts gives my sound-card it's own IRQ.
That said, newer, more powerful computers may beehive real bad when it comes to real-time audio performance.

Thanks for the idea. I disabled the hyperthreaded CPUs manually, then also added noht to the grub command line. Unfortunately, the problem persists. I'll try disabling i2c also.

Not sure I'm ready to do a custom kernel, but maybe it's worth a try?

[lykwydchykyn]

Heavens be praised, lads; I found the problem.

While trying random things to fix the problem, I stumbled upon the fact that unplugging the charger makes the XRUNs (and audible glitching) stop. Smooth and clear sailing all the way.

Immediately when plugging in the charger, they start again.

Unfortunately, there isn't enough capacity in the battery for that alone to be a workable solution, but at least I know where the problem is now. I tried yanking the battery and running just on the charger to see if that would help (thinking maybe the charging hardware was at fault, and maybe pulling the battery would shut it off), but no such luck.

Then I had a thought: I'm using an old charger from a mid-00's dell, since dell has used the same laptop charger plug for decades. I have a new Dell laptop from work with a fancy-pants new charger. Thought it'd be worth trying that.

On the good charger: running more than 10 minutes with no XRUNs. Loaded up Ardour, added a MIDI track with Helm, played my biggest fattest cpu-hogging patches. No XRUNs.

TL;DR: it was the stinking LAPTOP CHARGING BRICK!

Now I just gotta scare up a good modern charging brick for this thing and I'm ready to roll again. Thanks everyone for the help and input!

[Michael Willis]

Good find! I had a similar problem when I recently bought a used laptop - it exhibited all sorts of strange behavior until I replaced the janky aftermarket charger.

[lykwydchykyn]

Hey, now that I have that worked out, what's the best way to get Ardour6 on AVLinux? I tried doing a flatpak, but it can't connect to Jack. Should I just compile it?