On Mon, 1 Feb 2016 07:14:46 +0100, Christopher Arndt wrote: RTIRQ_NAME_LIST="usb" https://wiki.archlinux.org/index.php/Pro_Audio#M-Audio_Fast_Track_Pro http://lmgtfy.com/?q=uca222+linux

On Mon, 1 Feb 2016 09:26:28 +0100, Christopher Arndt wrote: It latter does provide additional information regarding this card. The former is what you need in your rtirq config. More information can be found here: https://help.ubuntu.com/community/UbuntuStudio/UsbAudioDevices http://www.linux-usb.org/USB-guide/x319.html http://wiki.linuxaudio.org/wiki/system_configuration#rtirq So what information are you missing? http://www.catb.org/esr/faqs/smart-questions.html

Hi all, I just wanted to give you an update on my quest for super-low-latency. I bit the bullet and compiled a rt-kernel. And the result is super-stable audio with a period of 32 samples @48Khz (for a total roundtrip latency of 3.5ms). With a (peak) cpu load hovering around 70% on all 4 cores I don’t get any xruns anymore. (even when running a bloated desktop that comes with mint :-) I only tested it running for a few minutes, we’ll see what happens when running for a few hours, but I’m happy so far. My conclusion is that the lowlatency kernel is nice for lowish latency with a load that isn’t too high, but it just doesn’t cut it for high demanding work. I want to thank you all for your input, I have learned a lot. cheers, Fokke

On Mon, 8 Feb 2016 11:14:45 +0000, Harry van Haaren wrote: Indeed, the rt config became tricky a while ago, especially for AMD based machines.

I used 3.18.25 from kernel.org, applied this patch: patch-3.18.25-rt23.patch.gz <https://www.kernel.org/pub/linux/kernel/projects/rt/3.18/patch-3.18.25-rt23.patch.gz>. The only option is changed from the default was "Fully Preemptible Kernel (RT)”. After that I had to edit kernel/locking/locktorture.c. an comment out the line #include <linux/rwlock.h> or it wouldn’t compile. (this part took me a while to figure out). This reason I choose this kernel was to stay close the the kernel version already installed on my system (3.19.x). I have to admit, i know very little about different kernel versions… If I would do it again, i would probably start out with the low-latency config rather than the default, but i’m not sure it it would make a difference. One caveat though, I haven’t tested this kernel very thoroughly, so i’m not even sure it won’t blow up in my face if I were to try and send an email or something :-) And also, I don’t seem to get hardware video acceleration (I have a intel builtin gpu). I don’t case for this too much as i plan to run this project in console only… I’m not sure how much there is to be gained by turning off all kinds of features in the kernel, but i know that trying this out takes a lot of time, especially if you don’t really know what you’re doing :-) cheers. Fokke

On Mon, 8 Feb 2016 19:44:49 +0100, Cedric Roux wrote: It's the vanilla + the rt-patch + configuration. https://www.kernel.org/pub/linux/kernel/projects/rt/

On 02/08/2016 08:11 PM, Ralf Mardorf wrote: Afaik the Ubuntu low-latency kernel doesn't really have a special config, just CONFIG_PREEMPT and CONFIG_HZ_1000. Jeremy

On Mon, 25 Jan 2016 12:23:09 +0100 Jörn Nettingsmeier &lt;nettings(a)stackingdwarves.net&gt; wrote: My 2 cents is that it's snakeoil ;) AFAIK, the important things are. 1. Use a properly configured realtime patched kernel. 2. Set a high priority of the soundcard interrupt, something like 97 is a good value. (If using a USB soundcard, set the priority of the interrupt servicing the USB hub instead). 3. Run Jack with realtime and memlocking enabled and at a priority of 80. 4. Make sure that you don't have any hardware/drivers that play havoc with your kernel scheduling. some WIFI adapters, NVIDIA, etc comes to mind. 5. Make sure that the system isn't suffering from SMI/NMIs which preempt the kernel and can take a long time to execute. This can be done with hwlatdetect script in the rt-tests package. 6. Use cyclictest from rt-tests to confirm that there are no latency spikes in how the kernel schedules threads. Possibly hyperthreading, cpu power management, etc could cause problems, and I don't have experience with all hardware out there, but IME on modern Intel hardware this isn't a problem. JACK2 also has a very nice profiling tool that can give a good idea about what is going on with the soundcard interrupt, clients, etc. Apart from that I think most things are snake oil, or ancient Internet lore, of course ymmv ;) -- Joakim

On 01/25/2016 12:53 PM, Joakim Hernberg wrote: Does this refer to the -m jackd option? What does that do actually, any pros/cons? Jeremy

On 01/26/2016 09:05 PM, Jeremy Jongepier wrote: Which should be the other way around of course... /me hides somewhere in a corner Jeremy

On Tue, 26 Jan 2016 20:53:55 +0100 Jeremy Jongepier &lt;jeremy(a)autostatic.com&gt; wrote: As I understand it, you wouldn't want memory being used for audio to be swapped out to disk as that could incur a lengthy timeout when it needs to be read back from disk, and thus producing xruns. -- Joakim

thanks for all your input, I’ll try and summarize here. First of all, booting into console mode, rather than running the full blown desktop seemed to eliminate most of the problems, although it’s still not quite a stable as i’d like. Also i don’t quite understand how all of that could interfere with my RT-thread. This was going to try and install a more minimal system anyway, and don’t need a graphical environment for this, but during developments it’s kind of nice to have. I still would like to see how far i can take this, and was really hoping i can continuously use 80-90% of all cpu cores without dropouts… Is that realistic with a lowlatency kernel? I am not currently locking memory. I thought a had plenty of ram, as not to cause any swapping, but i guess its good practice to wire memory, so i will give it a try. I don’t have a wireless on my machine, nor an nvidia card. just intel builtin graphics. This where my linux knowledge falls short, but If i don’t have that hardware, can I assume no drivers for it are loaded? lowlatency-kernel is not going to cut it? I wasn’t really able to find to much info on the difference between the two, other than than the rt-kernel is a “step up” and hard realtime vs soft. But nothing on how this is technically achieved did that. I’m not running jack but rather using alsa directly/ I did actually find that hyperthreading had an impact, turing it of made every thing much more predictable. Here’s the output of cat /proc/interrupts: CPU0 CPU1 CPU2 CPU3 0: 57 0 0 0 IO-APIC-edge timer 1: 3 0 0 0 IO-APIC-edge i8042 7: 44 0 0 0 IO-APIC-edge 8: 1 0 0 0 IO-APIC-edge rtc0 9: 3 0 0 0 IO-APIC-fasteoi acpi 12: 4 0 0 0 IO-APIC-edge i8042 16: 0 0 0 0 IO-APIC 16-fasteoi madifx 121: 7074 0 0 341 PCI-MSI-edge xhci_hcd 122: 13001 25946 0 342 PCI-MSI-edge 0000:00:17.0 123: 3409 0 0 0 PCI-MSI-edge eth0 124: 171029 0 0 0 PCI-MSI-edge i915_bpo 125: 4805 0 0 0 PCI-MSI-edge snd_hda_intel NMI: 17 12 13 14 Non-maskable interrupts LOC: 544121 436328 444080 462821 Local timer interrupts SPU: 0 0 0 0 Spurious interrupts PMI: 17 12 13 14 Performance monitoring interrupts IWI: 0 0 0 0 IRQ work interrupts RTR: 3 0 0 0 APIC ICR read retries RES: 13051 11975 11216 8004 Rescheduling interrupts CAL: 613 547 560 526 Function call interrupts TLB: 640 767 676 535 TLB shootdowns TRM: 0 0 0 0 Thermal event interrupts THR: 0 0 0 0 Threshold APIC interrupts MCE: 0 0 0 0 Machine check exceptions MCP: 31 31 31 31 Machine check polls HYP: 0 0 0 0 Hypervisor callback interrupts ERR: 44 MIS: 0 the local timer interrupts are getting fired all the time, but i guess they should. 123 eth0 is also updated rather often. But the one thats closed to 0.6s seems to be: 122: 13001 26147 0 342 PCI-MSI-edge 0000:00:17.0 But is there anything a can do about that? cheers, Fokke

On Mon, 25 Jan 2016, Len Ovens wrote: Check the actual priorities that rtirq sets. It seems to me the last time I checked that if an irq is shared by a, b an c and rtirq is used to prioritize c to 90 for example, a and b will end up at 86 and 88 or something like that even though they should be 50. This was some time ago and may well have changed. In days of old I found even swapping the slots cards were plugged into made a difference, but I have the same cards backwards in the i5 I run now with no problem. note: I use two audio cards, a delta66 and an audiopci. The delta has to be higher priority than the audiopci (which provides midi only) or I get xruns. -- Len Ovens www.ovenwerks.net

On Wed, 27 Jan 2016, Fokke de Jong wrote: Hmm, I have looked as best I can and it seems fasteoi is an interupt translator (best word I could come up with) and it in combination with IO-APIC is the same as what some systems show as: IO-APIC-fasteoi I do not know if this is kernel version or hardware. however it does appear to be tied to the madifx use and so not to worry about. PCIe is a different animal than PCI. The interupts are sent different too. Interupt conflicts should not happen. Do you monitor temperature? (I use Psensor) Which CPU governor do you use? Looking back at your first post, you are measuring time that your callback takes in terms of the wall clock. The fact that it sometimes takes a lot longer than it should does indicate that something else is taking some of that time. In another post you suggest that the interupts for 0000:00:17.0 seem to be about the right number for every .6 seconds. Have you looked up what device that is? ls /sys/bus/pci/devices in the 0000:00:17.0 directory you can look at the driver which may (or not) tell you more about what it is. cat uevent seems to give the most readable info. But someone who knows the file system better may be able to point to a better way. -- Len Ovens www.ovenwerks.net

Jonathan E. Brickman wrote: Doesn't JACK sit on top of ALSA? If so how is it possible for JACK with ALSA to perform better than ALSA alone? Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

On Thu, 28 Jan 2016 07:37:47 -0600 "Jonathan E. Brickman" &lt;jeb(a)ponderworthy.com&gt; wrote: It's not my intention to denigrate your experience, but my own experience shows that the only way to get xrun free audio using JACK is to follow my previous advice. There are many causes for xruns, but IMO/IME using a lowlat kernel simply won't provide xrun free audio... This conclusion seems to be corroborated by cyclictest results... Personally I attend to what I outlined previously, and I use a full KDE environment with opengl compositing enabled on an Intel GPU. I don't have to disable cron or anything else, and I have let most of the Internet lore just fall by the wayside, as it IME seems to be if not snake oil, then at least not applicable to my system. Of course YMMW ;) -- Joakim

On Mon, 25 Jan 2016, Joakim Hernberg wrote: hyperthread is only a problem with jack latency under 64/2... even on an older single core P4. (at least in my testing) -- Len Ovens www.ovenwerks.net