Negative value Xruns

[FawkesThat]

I'm getting jackd reporting negative values for xruns, and scratching my head as to why.

Eg, "Jack: alsa_pcm: xrun of at least -852659.90 msecs".

I've done a lot of searching to try and pinpoint where this is coming from, and found an old post somewhere else which said this is a result of jack using a wrong clock somewhere. But, we're talking years ago so it shouldn't be a problem in the current version of jack2. Despite that I've tried with the --clocksource parameter on both of the h(pet) and s(ystem) options. This doesn't seem to have any effect.

$ jackd -h reports the jackdmp version as 1.9.12, current for my i5 Neon install running the 5.3.0-46-lowlatency kernel.

They're at fairly regular intervals, doubling when I double the buffer size. Fortunately there are no clicks or other visible noise in recording. DSP load is minimal - less than 3% most of the time - so this just seems to be a quirk I'd prefer ironed out so I can see when there's a real Xrun.

As an aside, I've spotted what looks like a bug in Cadence. None of the Clock Source radio buttons in the Engine tab of Jack Settings will 'stick' at a setting. Instead, the jack log shows "ERROR: Parameter value type mismatch: was expecting 'u', got 'y'"

I've checked the obvious for this xrun quirk - no interrupt conflicts, limits.conf set, rtirq running, threadirqs explicitly specified in /etc/default/grub - all looks good.

Anyone able to offer a little enlightenment?

[Jack Winter]

I've seen that too, I suspect that it's a problem with unsigned vs signed in the JACK code.