On 5 September 2012 at 13:02, Simon Wise <simonzwise(a)gmail.com> wrote: Yes, identical. The card in the system with xruns works fine in the system with no xruns. Yes, as far as I can tell. Great question. I didn't check. I suppose that /proc/interrupts will tell me. Thanks! -- Kevin

On 5 September 2012 at 9:11, Jeremy Jongepier <jeremy(a)autostatic.com> wrote: Xrunning system says: 0 [PCH ]: HDA-Intel - HDA Intel PCH HDA Intel PCH at 0xf7e20000 irq 70 1 [M1010 ]: ICE1712 - M Audio Delta 1010 M Audio Delta 1010 at 0xa040, irq 16 2 [NVidia ]: HDA-Intel - HDA NVidia HDA NVidia at 0xf7080000 irq 17 Fine system says: 0 [Intel ]: HDA-Intel - HDA Intel HDA Intel at 0xfbff8000 irq 30 1 [M1010 ]: ICE1712 - M Audio Delta 1010 M Audio Delta 1010 at 0xec00, irq 17 I'm using the Delta 1010 cards on each system with Jack & Ardour. Xrunning system says: CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 0: 129 0 0 0 0 0 0 0 IO-APIC-edge timer 1: 3 0 0 0 0 0 0 0 IO-APIC-edge i8042 8: 1 0 0 0 0 0 0 0 IO-APIC-edge rtc0 9: 0 0 0 0 0 0 0 0 IO-APIC-fasteoi acpi 12: 17478 0 0 0 0 0 0 0 IO-APIC-edge i8042 16: 56322 0 0 0 0 0 0 0 IO-APIC-fasteoi ahci, ehci_hcd:usb1, firewire_ohci, snd_ice1712, nvidia 17: 154 0 0 0 0 0 0 0 IO-APIC-fasteoi snd_hda_intel 23: 289 0 0 9 0 0 0 0 IO-APIC-fasteoi ehci_hcd:usb2 49: 10439 82409 9643 133 0 0 0 0 PCI-MSI-edge ahci 50: 5 0 0 0 0 0 0 0 PCI-MSI-edge ahci 51: 1 0 0 0 0 0 0 0 PCI-MSI-edge xhci_hcd 52: 0 0 0 0 0 0 0 0 PCI-MSI-edge xhci_hcd 53: 0 0 0 0 0 0 0 0 PCI-MSI-edge xhci_hcd 54: 0 0 0 0 0 0 0 0 PCI-MSI-edge xhci_hcd 55: 0 0 0 0 0 0 0 0 PCI-MSI-edge xhci_hcd 56: 0 0 0 0 0 0 0 0 PCI-MSI-edge xhci_hcd 57: 0 0 0 0 0 0 0 0 PCI-MSI-edge xhci_hcd 58: 0 0 0 0 0 0 0 0 PCI-MSI-edge xhci_hcd 59: 1 0 0 0 0 0 0 0 PCI-MSI-edge xhci_hcd 60: 0 0 0 0 0 0 0 0 PCI-MSI-edge xhci_hcd 61: 0 0 0 0 0 0 0 0 PCI-MSI-edge xhci_hcd 62: 0 0 0 0 0 0 0 0 PCI-MSI-edge xhci_hcd 63: 0 0 0 0 0 0 0 0 PCI-MSI-edge xhci_hcd 64: 0 0 0 0 0 0 0 0 PCI-MSI-edge xhci_hcd 65: 0 0 0 0 0 0 0 0 PCI-MSI-edge xhci_hcd 66: 0 0 0 0 0 0 0 0 PCI-MSI-edge xhci_hcd 67: 11 0 0 0 0 0 0 0 PCI-MSI-edge mei 68: 71 0 0 497508 0 0 0 0 PCI-MSI-edge em1 69: 0 0 0 0 0 0 0 0 PCI-MSI-edge p121p1 70: 816 0 0 0 0 0 0 0 PCI-MSI-edge snd_hda_intel NMI: 20 23 16 26 3 3 2 2 Non-maskable interrupts LOC: 41295 171368 36696 193528 13059 9923 8421 11449 Local timer interrupts SPU: 0 0 0 0 0 0 0 0 Spurious interrupts PMI: 20 23 16 26 3 3 2 2 Performance monitoring interrupts IWI: 0 0 0 0 0 0 0 0 IRQ work interrupts RTR: 7 0 0 0 0 0 0 0 APIC ICR read retries RES: 31602 6824 1130 666 841 419 249 359 Rescheduling interrupts CAL: 474 704 676 725 704 745 722 777 Function call interrupts TLB: 420 366 352 427 930 717 170 414 TLB shootdowns TRM: 0 0 0 0 0 0 0 0 Thermal event interrupts THR: 0 0 0 0 0 0 0 0 Threshold APIC interrupts MCE: 0 0 0 0 0 0 0 0 Machine check exceptions MCP: 9 9 9 9 9 9 9 9 Machine check polls ERR: 0 MIS: 0 Fine system says: CPU0 CPU1 CPU2 CPU3 0: 35 0 0 0 IO-APIC-edge timer 1: 4 2 5 3 IO-APIC-edge i8042 4: 0 0 1 1 IO-APIC-edge 6: 2 0 2 0 IO-APIC-edge floppy 8: 0 0 0 1 IO-APIC-edge rtc0 9: 0 0 0 0 IO-APIC-fasteoi acpi 12: 313 271 45 48 IO-APIC-edge i8042 14: 0 0 0 0 IO-APIC-edge ide0 15: 0 0 0 0 IO-APIC-edge ide1 16: 14878 13436 479 480 IO-APIC-fasteoi uhci_hcd:usb1, uhci_hcd:usb6, pata_marvell, nvidia 17: 0 0 0 0 IO-APIC-fasteoi ICE1712 18: 164 165 328 289 IO-APIC-fasteoi uhci_hcd:usb5, ehci_hcd:usb7 19: 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb4 21: 9 10 11 9 IO-APIC-fasteoi uhci_hcd:usb2 23: 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb3, ehci_hcd:usb8 28: 1672 1672 4348 3307 PCI-MSI-edge ahci 29: 33 40 38 5319 PCI-MSI-edge eth0 30: 70 71 67 69 PCI-MSI-edge hda_intel NMI: 0 0 0 0 Non-maskable interrupts LOC: 10557 10313 10611 11666 Local timer interrupts SPU: 0 0 0 0 Spurious interrupts PMI: 0 0 0 0 Performance monitoring interrupts PND: 0 0 0 0 Performance pending work RES: 431 221 441 425 Rescheduling interrupts CAL: 3098 1409 3750 1325 Function call interrupts TLB: 682 535 805 608 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: 1 1 1 1 Machine check polls ERR: 3 MIS: 0 Xrunning system says: ondemand ondemand ondemand ondemand ondemand ondemand ondemand ondemand Fine system says: cat: No match. There is no scaling_govenor file in the .../system/cpu/... tree. This kernel is 2.6.33. Whereas the other system kernel is 3.5.3. Excellent resource. I was also going to try installing the CCRMA RT kernel and any "accessories" it might require. Thanks much! -- Kevin

On 09/05/2012 12:41 PM, Jeremy Jongepier wrote: If you add the Planet CCRMA repository to your yun configuration installing the meta package "planetccrma-core" should bring in all the needed goodies, I think. That includes rtirq, and the default configuration of Fedora's jack, rtirq and the rt patched kernel should have all the right irq priorities, etc. -- Fernando

On Wed, September 5, 2012 12:24 pm, Kevin Cosgrove wrote: That would give me xruns too. I was able to change slots. Also try to keep some distance between the video card and the audio card. (if you can) See if you can set IRQ in the bios for that slot to something else if there is only one. I find the same thing with USB audio. I have to find a USB plug on my laptop that does not share irq with anything else and only plug the audio IF in that one plug. Nice. What may help if you don't want to use performance is to set it to user and then set a lower than top speed. I seem to get less problems setting my system to 50% speed than with the (faster) ondemand setting. cpufreq-set and cpufreq-info are great to play with this stuff. the -info one will tell you what frequencies you can choose from. I found choosing the exact frequency didn't always work, slightly higher or lower would though. Play with it. Read the man page. My laptop runs at 1.6Ghz, but also has 1.33, 1.06 and .8. I can do a lot more than I would think at 800Mhz as it turns out. rtirq can help. If used wrong it can make things worse... for example the stock setting is bad for FW or USB audio IFs. It comes with the snd first or second. as someone else says in another message put snd_ice1712 and then snd after. This will put your internal IF in it's proper place, second. I do the same with USB cards. I find out which USB plug has no other irqs with it (USB3 on mine) and put : usb3 snd usb as the order. This puts my external audio first, then the internal crap audio and then whatever other usb stuff there is (in a laptop that includes webcam in the lid and SD reader and maybe other things too... take a look through dmesg for all the stuff that is USB) Be aware that putting: snd-ice1712 snd will put all that other stuff on irq 16 between your ice and your internal card and you may wish to explicitly make them lower. Check your priorities after you have it going: ps -eLo pid,cls,rtprio,pri,nice,cmd | grep -i irq Look at the third column over. -- Len Ovens www.OvenWerks.net

On Thu, September 6, 2012 2:07 am, Jeremy Jongepier wrote: I'm on the wrong machine just now, but I found when I specify usb3 and then usb strange things happen. My comment was check what the changes to the script do, it is not always what is expected. On this machine it is pretty good. my config line is firewire snd usb3 usb i8042 I'm not sure why I left it this way actually as I do not use FW... I think I have the port turned off in bios. Anyway, the usb ports are priority 75 and 74 and i8042 are 70 and 69... not 5 apart. On the netbook it is even stranger. -- Len Ovens www.OvenWerks.net

On Thu, Sep 06, 2012 at 08:50:03AM -0700, Kevin Cosgrove wrote: Under Debian, it is /etc/default/rtirq, not sure about Fedora. Cheers, S.M.

On 09/06/2012 06:04 PM, Kevin Cosgrove wrote: http://www.rncbc.org/archive/#rtirq look for the rpm (built on opensuse though, i guess it's ok for fedora) cheers -- rncbc aka Rui Nuno Capela rncbc(a)rncbc.org

On 5 September 2012 at 22:28, "Len Ovens" <len(a)ovenwerks.net> wrote: OK. I see it now. I've never had to fight the interrupt problem before. There are two PCI (legacy) slots in this ASUS P8Z68 DELUXE GEN3 1155 Motherboard. I intend to use both of them as I have a pair of M-Audio Delta 1010 audio adapters. I'll look at the manual for my MB and see what I can do. A happy accident. Very interesting. It's also interesting that my system with no xruns has RT priority for jackd turned OFF. ??? I just discovered that last night. Wow. That makes sense. The internal IF is only used for playing my music collection's files and the audio for on-line things. I'm only using USB for mass storage. Eventually I hope that my Behringer BCF2000 will be usable again with ardour. I'm hoping ardour 3 will restore that functionality. In order to look for conflicting IRQs with my audio interface? This is looking as complicated as slackware was in 1996, back when I had to build a special kernel with each OS release. Thanks for the detailed info! -- Kevin

On 6 September 2012 at 10:01, "Len Ovens" <len(a)ovenwerks.net> wrote: Tell me about it. I have need for high channel counts. My drums alone really want 11 channels. I'm not hearing good things about trying to chain multiple high channel count firewire interfaces. I don't see any audio interfaces built for new PCI slots. That leaves me with legacy PCI, and MB manufacturers are leaving that by the wayside. Ugh. Again, thanks for the advise.... -- Kevin

On 6 September 2012 at 13:10, Paul Davis <paul(a)linuxaudiosystems.com> wrote: Looks like the HDSPe is a PCIe card allowing connection between the computer and an external Multiface, Multiface II or Digiface. It looks like the HDSPe retails for about $550US and a Multiface II runs for about $950US. I'd need two of the Multiface II units. Those units are listed in the ALSA pages, which is good news. It's *REALLY* nice to see an available solution. But, it does seem just a bit out of my price range. Of course, that's my problem. ;-) Thanks.... -- Kevin

On 7 September 2012 at 4:15, Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> wrote: Ah, I didn't know that non-RME gear would work with RME. I suppose I should have thought through the ADAT interconnection options. That's a nice way to go. Full sync across all channels would be a must for me tho. At times, like now, I second guess myself and wonder if I should have just bought the bullet, and gone with RME in the first place. Cheerio.... -- Kevin

I just had to look... and sure enough they do exist: http://ca.startech.com/Cards-Adapters/Slot-Extension/PCI-Express-to-PCI-Ada… May require some case modification, but the connector on the 1010 looks low enough maybe not. A spacer would help hold the card in place. The spdiff connections would be covered though. In some of the cases I have seen the card hold down is a separate bar and could be mounted higher. That is not a too outrageous mod if you look at something like this: http://www.jrigg.co.uk/elec/interface.html The other plan... perhaps more outrageous is to put both cards in the old computer and use netjack to turn it into an Ethernet audio interface... I won't even try to explain that one... though if I had the systems I wouldn't mind trying it out. -- Len Ovens www.OvenWerks.net

On Thu, September 6, 2012 8:57 pm, Ralf Mardorf wrote: Could be better. The bridge will be the same as what the MB supplies for it's PCI slots. The extra power plug means cleaner power and enough drive for the analog audio circuitry. Latency will be the same. Audio jitter is more effected by whats in the card itself. The second link I gave (http://www.jrigg.co.uk/elec/interface.html) actually goes into some detail about that. MIDI is slow at 3khz for words and half that for a key down event. I wish I could use my boca board for that (from BBS days) with 16 uarts. 16 outputs one for each synth. But I think it is actually an isa board. If I ever use it again it will be with netboot dx66 or something and just enough OS to get it to network. Anyway, jitter is more in the software and drivers and how they handle (or don't) the midi signal. -- Len Ovens www.OvenWerks.net

On Thu, September 6, 2012 9:58 pm, Kevin Cosgrove wrote: The review looks bad for audio cards. I guess there is an onboard regulator that does not allow enough current :P So the onboard reg would have to be bypassed and an external one added. Better price though. -- Len Ovens www.OvenWerks.net

On 09/07/2012 01:31 PM, Kevin Cosgrove wrote: There should be no problem with power. We are running tons of Delta66's and I used to have a few 1010's as well. Easy cards to work with (so I'm surprised at the problems you are having). The 1010's had problems with some capacitors in the break-out box (in the power supply doubler or quadrupler circuit) - replacing them fixed the issue. -- Fernando

On Sat, 2012-09-08 at 14:59 -0700, Len Ovens wrote: If there isn't enough current for an IO card, the cause might be a undersized power supply unit. Whatever the specifications for maximal current for PCI slots are, if the PSU is to weak, it can't provide the needed current. Sum up the power consumption of the CPU, all HDDs, DVD drives, cards, USB gear etc. and compare it with the maximum current the PSU can provide. Regards, Ralf

On 7 September 2012 at 13:31, Kevin Cosgrove <kevinc(a)cosgroves.us> wrote: I did try the mentioned card, getting mine through Newegg. The card works with the PCI card portion of the M-Audio Delta 1010 system. This *really* helped my xrun issue. They went away completely. But, mechanically it wasn't so good. The S/PDIF connectors of the card that used to stick out the back of the computer were covered up, and the DB-25 connector barely fit. Also, the card is pretty wobbly, and there's no way to screw down the daughter (e.g. Delta 1010) card of the pair. If this is the only choice available, it *DOES* work. But, I'm going solve the interrupt problem without resorting to this. I hope this info is useful to somebody. Cheerio... -- Kevin

On Fri, 07 Sep 2012 04:15:20 +0200 Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> wrote: You would have to connect both ADAT out and in, when using the RME as master clock, since the clock has to go via adat from the rme to the ada8k device? --- Joakim

On 6 September 2012 at 8:43, Kevin Cosgrove <kevinc(a)cosgroves.us> wrote: I did a search for "irq" on this website http://www.manualowl.com/m/Asus/P8Z68-DELUXE%2FGEN3/Manual/263040?page=91 and found a page (2-14) that lists the (non-alterable???) IRQ assignments for my motherboard. The good news is that one of the legacy PCI slots has less stuff on the IRQ. The bad news is that one of the PCI slots has lots of stuff on that IRQ. Looking at IRQ 16 above, my nVidia shows up. It's PCiE x16, and my motherboard seems to have 3 of those slots, with one slot being on a different IRQ. I suspect moving the video card might help, right? Basically, my strategy would be to disable drivers I don't use. For instance, I don't have any firewire gear. Next, I'd move anything I could to a slot using a different IRQ than the one I want to reserve for the Delta 1010. Seem like a good plan? Thanks! P.S.: I had this system custom built for audio work. If/when I get this working, I'll provide feedback to my system builder as to what works well. I'll also post my solution here. -- Kevin

On Thu, 06 Sep 2012 10:02:11 -0700 Kevin Cosgrove <kevinc(a)cosgroves.us> wrote: FWIW, I have a similar system with an Asus P8Z68-V PRO GEN3 + Intel i7-2600k CPU, I have an rme multiface PCI card in a slot that gives it IRQ 18 all to itself. The only irq priority manipulation I do is to run chrt -f -p 98 `pgrep irq/18-snd_hdsp` from /etc/rc.local. I also have the system running with the default ondemand governor. I don't use an external NVIDIA card as the built in HD3000 GPU works a treat for low latency audio even with a full KDE install with compositing kwin. If I did use a NVIDIA card I would most likely use the nouveau driver that lately has become very good for low latency audio. Kernel is 3.4.9-rt17. Running cyclictest -m -Sp99 -i100 -d0 shows me kernel scheduling latencies of well under 0.1ms no matter how hard i push the system, and that is with the ondemand governor... All in all very pleased with this system, and I think you will be too if you move the soundcard to another slot, having less stuff on it. Another tip, if you have to use a slot that shares IRQs, then you have to raise the priority of all the soft interrupt threads that share the IRQ with the soundcard, otherwise you will get a lot of xruns. --- Joakim

On Fri, 07 Sep 2012 10:30:35 +0200 Jeremy Jongepier <jeremy(a)autostatic.com> wrote: All soft interrupts run at 50 by default, so they are all "raised" by default.. Empirical testing on a couple of machines shows that it is indeed beneficial to raise the priority of associated soft interrupt threads. There is so much hearsay and mumbo jumbo about linux audio floating around, that I would not make such a statement without having a foundation for it.. Of course seeing the wide variety of hardware and the fact that we all seem to run from up to date to years old software, makes any statement very much a your milage may vary... --- Joakim

On Fri, 07 Sep 2012 11:40:33 +0200 Jeremy Jongepier <jeremy(a)autostatic.com> wrote: Yes I do. Quite possibly the situation has changed since 2011, as the rt patch is constantly evolving and being merged into vanilla.. I also verified my results by asking the rt devs on IRC (not that this constitutes proof), and a couple of them concurred that this would indeed be good practice. I'm sorry if it came across as a personal reproach, it was in no way intended as such! It was more of a general statement about linux audio and the associated lore floating around on the nets, much of it outdated or even untrue nowdays. What I wanted to make clear is that I was not simply repeating some advice found on the internet somewhere, but rather based my comment on personal experience. --- Joakim

On 09/07/2012 02:40 AM, Jeremy Jongepier wrote: What I use with success is (and this is all done by rtirq and jackd if properly configured). All soft interrupts are left alone at their default value of 50 (anything running with SCHED_FIFO or SCHED_RR priority has priority over "normal" SCHED_OTHER scheduled processes - the number does not really matter and the default of 50 is fine[*]). The soundcard related software interrupts are raised so that sound processing takes priority over everything else. All jack SCHED_FIFO threads should run with a priority that is between 50 and the priority of the soundcard related software interrupts. There should be enough "irq priority space" around jack so that jack clients are not below 50 and not above the soundcard software interrupts. Some clients (jconvolver is one) would benefit from additional headroom as they run extra threads right below the priority of the client thread and you probably don't want that to go below 50 (if you keep the default). This assumes you run jackd with -R and the os is set up to allow a normal user to do that and also lock memory down. I have never had to tweak the hardware interrupts in the BIOS or elsewhere, software interrupts have always been enough. You might want to make sure that, say, the HDMI sound interface does not have the priority raised if you are not using it. -- Fernando [*] some stuff, for example pd, runs some of its extra threads with SCHED_FIFO with low priorities (1 or 2, I think).

I've been trying to reduce my xrun troubles. I'm down from > 10 xruns per second to something more like 10 xruns per minute. Still not good, but better. I used the realTimeConfigQuickScan.pl script to diagnose things. https://code.google.com/p/realtimeconfigquickscan/ I'm down to three things reported as "not good" now. 1. Checking checking sysctl inotify max_user_watches... < 524288 - not good increase max_user_watches by adding 'fs.inotify.max_user_watches = 524288' to /etc/sysctl.conf and rebooting For more information, see http://wiki.linuxmusicians.com/doku.php?id=system_configuration#sysctl.conf Looking at the link there's a comment, "...it remains very unclear ... if adjusting this value actually does anything at all." So, I haven't altered this. Does anyone have experience saying that this helped them? 2. chrt: failed to set pid 0's policy: Operation not permitted Checking the ability to prioritize processes with chrt... no - not good Could not assign a 80 rtprio value. Set up limits.conf. For more information, see http://wiki.linuxmusicians.com/doku.php?id=system_configuration#limits.conf I did make the changes outlined at the above link. I still get the above report. I'm going to guess that I need some real-time support from the kernel to make this work. Which brings me to 3. Kernel with Real-Time Preemption... not found - not good Kernel without real-time capabilities found For more information, see http://wiki.linuxmusicians.com/doku.php?id=system_configuration#installing_… First I looked at this link: http://wiki.linuxmusicians.com/doku.php?id=system_configuration#the_kernel Specifically, I looked at the threadirqs kernel option. grep -e CONFIG_IRQ_FORCED_THREADING=y -e CONFIG_PREEMPT=y /boot/config-`uname -r` produces "CONFIG_IRQ_FORCED_THREADING=y" and I think that's good. I altered my /boot/grub2/grub.cfg file to include "threadirqs" on the stanza for my kernel, like so, but without all the line breaks. linux /boot/vmlinuz-3.5.5-2.fc17.x86_64 root=UUID=77edf07a-a49b-48dd-82c8-2f9e5c8691b7 ro nomodeset rd.md=0 rd.lvm=0 rd.dm=0 SYSFONT=True KEYTABLE=us rd.luks=0 LANG=en_US.UTF-8 rhgb quiet threadirqs nouveau.modeset=0 rd.driver.blacklist=nouveau "uname -r" reports "3.5.5-2.fc17.x86_64" but I don't have threaded IRQs. Any ideas on how to improve my IRQs? They are not alterable in the BIOS. Thanks.... -- Kevin

On 11 October 2012 at 9:07, Jeremy Jongepier &lt;jeremy(a)autostatic.com&gt; wrote: Nice to know. A comment at the above link says, "If [the grep command] returns CONFIG_IRQ_FORCED_THREADING=y and CONFIG_PREEMPT=y then your kernel is using IRQ threading and you don't have to proceed with the following steps. If it only returns CONFIG_IRQ_FORCED_THREADING=y you can add the threadirqs boot option as described..." My grep was in the 2nd case, with only CONFIG_IRQ_FORCED_THREADING set to "y", so I proceeded with the rest of the "threadirqs" instructions related to grub. That didn't seem to work. I left all of that in there from Fedora's installation of the kernel. # CONFIG_PREEMPT_RCU is not set CONFIG_PREEMPT_NOTIFIERS=y # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set CCRMA has kernel-rt-3.4.11-1.rt19.2.fc17.ccrma.x86_64 but it doesn't play nicely with my nVidia card and X config. I changed the X config to use the nouveau driver, which got it to boot to level 5 at least. But the geometry is not good and that driver ignores my 2nd display. I found A LOT of potentially useful information with a websearch for enabling an nVidia driver with a CCRMA kernel. Sorting that out is a possibility. Thanks.... -- Kevin

On 11 October 2012 at 10:55, Jeremy Jongepier &lt;jeremy(a)autostatic.com&gt; wrote: The driver "works", I just can't set my resolution as high as I'd like, and I haven't figured out to use both displays. I really like two displays with ardour, one hosting the main window and one containing the mixer window. Cheerio... -- Kevin

On 11 October 2012 at 19:58, Jeremy Jongepier &lt;jeremy(a)autostatic.com&gt; wrote: Very interesting. I'd not heard of that. At first glance it looks like an Open replacement for at least some part of TwinView. Thanks! -- Kevin

1. Checking checking sysctl inotify max_user_watches... < 524288 - not good as jeremy mentioned, i have no idea what this is supposed to help. it has nothing fundamentally to do with realtime at all. 2. chrt: failed to set pid 0's policy: Operation not permitted > Checking the ability to prioritize processes with chrt... no - not good > Could not assign a 80 rtprio value. Set up limits.conf. > For more information, see > http://wiki.linuxmusicians.com/doku.php?id=system_configuration#limits.conf > I did make the changes outlined at the above link. I still > get the above report. I'm going to guess that I need some > real-time support from the kernel to make this work. Which > brings me to this is not true. http://jackaudio.org/realtime_vs_realtime_kernel you *must* get these permissions correct BUT at the same time, i have no idea why this script is trying to set the RT priority of PID 0, which is typically init(1), the program that starts a Unix system running. > 3. Kernel with Real-Time Preemption... not found - not good not necessarily relevant. required in cases where the kernel and h/w are cooperating (badly) to prevent low latency operation, but many people have systems where this is not required.

init is pid 1. There is no pid 0.

On 11 October 2012 at 6:55, Paul Davis &lt;paul(a)linuxaudiosystems.com&gt; wrote: OK. That's a pleasant answer. :-) I added this: :::::::::::::: /etc/security/limits.d/93-audio_limits.conf :::::::::::::: # Increase priority of audio applications # maximum realtime priority @audio - rtprio 90 # maximum locked-in-memory address space (KB) @audio - memlock 2000000 Fedora's jack-audio-connection-kit-1.9.8-9.fc17.x86_64 package added this: :::::::::::::: /etc/security/limits.d/95-jack.conf :::::::::::::: # Default limits for users of jack-audio-connection-kit @jackuser - rtprio 70 @jackuser - memlock 4194304 @pulse-rt - rtprio 20 @pulse-rt - nice -20 By permissions, are you meaning crw-rw---- 1 root audio 10, 228 Oct 10 22:47 /dev/hpet crw-rw---- 1 root audio 254, 0 Oct 10 22:47 /dev/rtc0 [kevinc #28] groups kevinc root adm disk wheel cdrom man floppy games audio users jackuser I'm having IRQ crowding issues, and I was headed at trying to get rtirq going in order to help this. I believe rtirq *does* require an RT kernel. http://wiki.linuxmusicians.com/doku.php?id=system_configuration#rtirq Thanks.... -- Kevin

On 10/11/2012 06:17 PM, Kevin Cosgrove wrote: No it doesn't. Reminds I have to update that section :) Best, Jeremy

On 10/11/2012 06:17 PM, Kevin Cosgrove wrote: Hi Kevin the default values provided by jack in limits.d have been chosen to work with the defaults in Fedora's rtirq package. You should only need to add threadirqs to the kernel command line regards, Brendan

On 10/12/2012 06:07 PM, Kevin Cosgrove wrote: the RT kernel test reported that no RT kernel was found. We've ported it into Fedora proper (currently in F17 updates-testing , F18 and rawhide). I worked with both the Jack maintainer and Fernando from CCRMA to get consensus on the default priorities. Brendan

On 5 September 2012 at 10:02, Ralf Mardorf &lt;ralf.mardorf(a)alice-dsl.net&gt; wrote: This http://www.thinkwiki.org/wiki/How_to_make_use_of_Dynamic_Frequency_Scaling looks like what you're talking about. I haven't ever altered that. I'll experiment. Thanks! -- Kevin

On 5 September 2012 at 7:43, Kevin Cosgrove &lt;kevinc(a)cosgroves.us&gt; wrote: In another reply to this thread I just now mentioned that all my procs on the system with xruns are set to 'ondemand'. Thanks.... -- Kevin

On 6 September 2012 at 9:50, "S. Massy" &lt;lists(a)wolfdream.ca&gt; wrote: Not during the time of xruns. The KDE desktop taskbar area has a wifi network icon on it, which says that there's no connection. But, I don't have a wifi capability in this computer. That's confusing to me, like maybe a driver got loaded but can't find any hardware to access. nVidia, for the ASUS GeForce GT 520 card. I'll see if I can figure out what the wifi kernel module, for the card I don't have, might be, and see if blacklisting it helps. Thanks! -- Kevin