jack output clicks/pops?

[dormirj]

hello,

(thanks to this forum) i'm currently running ubuntu studio with kxrepos using jack through my rc-300 as audio interface, using the rc-300's ins and loop tracks as manipulation source for supercollider- now i'm running jack with standard settings and once it gets a little bit going i always have clipping/clicks and popping sounds in my audio, is there some "beginners guide" for optimizing jack and audio output? is the input too high maybe? i've also tested with the mod duo app and also got these clicks and pops, despite ram and cpu being not too loaded (always under 30% so far).

EDIT: pulse is turned off, if this is of interest to this problem.

i assume there's going to be a whole lot of different religions on this issue, but i'd love to have a few starting points.

greetings;
dormir--

[folderol]

When you say 'standard' jack settings what exactly do you mean? What did you use to set it up?

[dormirj]

standard settings as of qjackctl from ubuntu studio install--

[dormirj]

sorry for doublepost-- i get http error, when i attach 2 files.

EDIT: i seem to get the http error when adding the other screenshot... don't know why;

imgur:
http://imgur.com/a/yHEzw

[folderol]

I'm rather surprised you're having to use such a large frames/period.
I don't know the rc-300 at all. Presumably the audio is coming in from it via USB. I don't think it will help much, but it's normally recommended to use 3 periods/buffer for this.

Can you tell us more about the computer. Is the bios set for 'performance' ? (or whatever your MOBO calls it!)
What CPU have you got?

[dormirj]

i've tried it with max performance and also smaller periods and periods/buffer setting 3. machine is a lenovo x200t with core2duo as seen below. kernel is 4.8.1 low latency, some adjustments from the audio configuration checklist were made for example to the limits.conf. i don't think its really a performance issue since my computer is nowhere near its limit in resources, i'm doing very simple stuff currently.

dormir@automne:~$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Duo CPU L9400 @ 1.86GHz
stepping : 6
microcode : 0x60c
cpu MHz : 800.000
cache size : 6144 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts nopl aperfmperf eagerfpu pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm tpr_shadow vnmi flexpriority dtherm ida
bugs :
bogomips : 3724.01
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Duo CPU L9400 @ 1.86GHz
stepping : 6
microcode : 0x60c
cpu MHz : 1600.000
cache size : 6144 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts nopl aperfmperf eagerfpu pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm tpr_shadow vnmi flexpriority dtherm ida
bugs :
bogomips : 3723.77
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

[folderol]

Looks like your CPU might be stepping. One processor is apparently running at less than half it's spec, and the other one is running about 80%

[dormirj]

ok, i tried turning off speedstepping completely from the bios, the clicks persist, so i don't feel it's related to the cpu.

here's a small clip of a droneloop playing where you can hear the sounds in question:

http://www9.zippyshare.com/v/CRvakQmd/file.html

[Jack Winter]

Normally what you'd do for lower latency, is make sure you have a lowlatency (or disputably a realtime kernel) installed. If you have a lowlatency kernel then add the "threadirq" boot flag for the kernel.

Set JACK to run realtime at priority 80.

Change the priority of the soundcard (in your case the usb hub) to 95 (or similar high value), easiest might be to use the rtirq script, but the best might be to do so manually. This is however somewhat complicated in the case of a usb soundcard.

Other considerations might be, that 3 periods/buffer or 48k vs 44k1 might work better, and so might using another usb port, removing other usb, devices, etc.

You could also be unlucky enough to have some device that has a driver that stops preemption for longer periods. WIFI drivers come to mind, but there are others too.

That said, 1024x2 really ought to work well, if it doesn't then something is not working well. Maybe the fixes for the driver weren't entirely successful?

[dormirj]

kernel is lowlatency. jack was already running at priority 89 in my last tests, but i will try to get the usb priority up there too.

Maybe the fixes for the driver weren't entirely successful?

that's also one of my worries, we'll see if there is some progress--

[gimmeapill]

Just chiming in as this was not mentioned yet: are you sure to use your fastest USB port? no Hub? no faulty usb cable?

[dormirj]

Just chiming in as this was not mentioned yet: are you sure to use your fastest USB port? no Hub? no faulty usb cable?

well, same setup on the hardware side plays flawlessly in windows, so i assume its not an issue with hub/cable/rc300 --

EDIT: tried out threadirqs bootflag and rtirq and usb gets elevated to priority 85, so that works in theory, clicks persist though.

[gimmeapill]

gimmeapill wrote:
Just chiming in as this was not mentioned yet: are you sure to use your fastest USB port? no Hub? no faulty usb cable?

well, same setup on the hardware side plays flawlessly in windows, so i assume its not an issue with hub/cable/rc300 --

EDIT: tried out threadirqs bootflag and rtirq and usb gets elevated to priority 85, so that works in theory, clicks persist though.

Yeah, most probably a software issue then.
any luck with the rt quickscan?
https://github.com/raboof/realtimeconfigquickscan

[Drumfix]

@dormirj: Guess we have to look more deeply into the driver.

Unfortunately i was unable to download your USB loggings. Can you upload them again?

[dormirj]

i will put up some more logs: from linux and windows for comparison.

no progress yet sadly--

greetings;