[00:49] <len-dt> ailo, should you see this... the  rtirq script sets the priority of everything, but audio highest.
[01:28] <len-dt> I'm thinking that may be a problem with my setup. Both of my sound cards are the same priority.
[09:39] <ailo> len-dt: Except right now, it's not doing what it's supposed to be doing
[12:17] <ScottL> ailo, len-dt if you are using the rtirq script you can talk to rui about it, he probably can be found #qtractor (if there is one) and he idles in #opensourcemusicians
[13:19] <len-dt> ailo, http://wiki.linuxmusicians.com/doku.php?id=system_configuration talks about the rtirq script and says the kernel option to use it is threadirqs.
[13:20] <len-dt> Has that been changed to IRQ_FORCED_THREADING?
[17:47] <ailo> There's an option called CONFIG_RT_GROUP_SCHED, which is enabled for Ubuntu but not for Debian (which I am on now), so I'm compiling a kernel with that enabled to see what happens
[17:48] <ailo> len-dt: Nice link btw. I really lack a lot of knowledge on this, but not for long..
[17:50] <ailo> Would be nice to have a supercomputer when trying different kernel configs. Or, just put several builds on que before going to sleep :P
[18:14] <scott-work> hehe, i ran into this last night.  someone reviewed various linux distros and chose ubuntu studio as the best multimedia distro:  https://www.linux.com/learn/tutorials/571815-the-2012-top-7-best-linux-distributions-for-you
[19:22] <ailo> So far I can't find any documentation that tells the whole story about rtprio and IRQ
[19:22] <ailo> CONFIG_RT_GROUP_SCHED used to be hazzle in the early days of CGROUP usage
[22:43] <len-dt> ailo, my irq priority looks about right. It seems to follow the script.
[22:45] <len-dt> rtc0 is 90, my soundcards are 85, usb2 is 80, usb1 is 79, the i8042s are 75 and 74 and the rest 50.
[22:47] <len-dt> ailo, I was looking at the "blurbs" for some MBs. They all seem to stress the speed of access the video controller has. This seems less than optimal for audio work.
[22:49] <ailo> len-dt: There seem to be some problems anyhow, and the rtirq script is not able to solve all of them. But, right now, rtprio is being managed by something else as well. If you disable the script, there are still raised prio for stuff
[22:49] <len-dt> I am wondering if I should list my sound cards separately so that my d66 gets a higher priority than the ensoniq. The ensoniq is only used for midi.
[22:50] <ailo> len-dt: It seems you can edit the rtirq conf file and have your own custom config
[22:50] <ailo> in /etc/default/rtirq
[22:51] <ailo> Also, there's the question whether the whole IRQ should get raised prio, or not. It would seem it is perfectly possible to raise prio for just the device, not the whole IRQ
[22:51] <len-dt> Ya I was looking at that, they use snd. I would put snd_ice1 and snd_ens1
[22:51] <len-dt> If the irq is not shared does it matter?
[22:51] <ailo> Nope
[22:52] <ailo> But, it would be very helpful if this problem could be solved
[22:52] <ailo> People with laptops and IRQ problems have little options
[22:52] <len-dt> ailo, I am not quite sure what the problem is.
[22:53] <ailo> Shared IRQ mainly
[22:53] <ailo> rtprio does nothing for me. Never has. 
[22:53] <ailo> So, I have no first hand experience in what it does
[22:54] <len-dt> I don't know if it does for me either. Where I put the cards does though.
[22:54] <ailo> I will try to create problems for myself later on. Setting up multiple machines for testing through the network
[22:54] <len-dt> It even seems to matter what order the modules are loaded.
[22:54] <ailo> I only know that people who do have IRQ sharing have had their problem solved with the rt kernel + the rtirq script
[22:58] <ailo> len-dt: You mean hw:1, hw:2 - the order for audio devices?
[22:59] <len-dt> ailo, I have five pci slots. The bottom most slots get a higher irq... 23 and down to the top slot.
[22:59] <ailo> len-dt: How do you know it is the order that matters?
[23:00] <len-dt> I had eth0 in the bottom slot which is shared with usb2
[23:00] <ailo> For me it has no effect at all
[23:00] <len-dt> and then the ensoniq and then the d66
[23:00] <ailo> len-dt: What driver do you have for the eth0? What chip is it?
[23:00] <len-dt> When I had -p 64 set and was downloading software I had xruns.
[23:01] <len-dt> when I changed them around the xruns went away
[23:02] <ailo> I tried to duplicate this, but I was not having any problems due to a network device. It would help if I knew what driver it is. I might have a network card here with the same chip
[23:02] <len-dt> the eth0 module is 8139too
[23:03] <len-dt> I think though it may also be my old MB (7-8years old)
[23:05] <ailo> Don't think I have that one
[23:05] <len-dt> I was reading about changing the length of time allotted to each pci card and it seemed to say there are two versions of pci slot (aside from pcie)
[23:05] <ailo> latency for pci?
[23:05] <len-dt> The MB may have something to do with how the cards are serviced.
[23:06] <len-dt> Not really latency. the amount of time a card can steal the bus before it has to give it up.
[23:06] <ailo> Still, having the network device interrupt the audio device is not acceptable
[23:06] <len-dt> It doesn't any more. :-)
[23:07] <len-dt> I can work quite acceptably at -p32 for  live stuff like guitar effects.
[23:07] <len-dt> Some xruns, but nothing I can hear.
[23:07] <len-dt> For recording, I want no xruns.
[23:08] <len-dt> ailo, for recording, I would probably work at -p1024 and use HW monitoring.
[23:10] <ailo> I've been working with kernel configs for the Debian kernel, and getting low latency is very easy. Just a matter of a couple of configs, but I have no rtprio, at least nothing that can be read with the ps command
[23:10] <len-dt> The PCIe cards don't have a problem because they are star connected. 
[23:10] <ailo> For me, all I need are those couple of configs, and I'm good to go with all of my devices, pci, firewire, builtin..
[23:11] <ailo> I haven't been working a lot with midi though, and alsa midi is not reliable at all when it comes to controlling external devices
[23:11] <ailo> The link you gave had some settings for hpet and stuff that is important for midi
[23:12] <len-dt> ailo, yes and we don't have them.
[23:12] <ailo> Would be good to test those and see how they change performance
[23:12] <len-dt> I am not a key player. So it is really hard for me to test that.
[23:12] <ailo> All I know for sure is that controlling an external midi synth using alsa midi gives very poor results
[23:13] <ailo> If you can't hear the difference, it doesn't matter much
[23:13] <len-dt> If someone sends me a .mid file (or whatever they use these days) I could test it.
[23:13] <len-dt> I have about 4 external midi boxes.
[23:14] <len-dt> I suspect just playing one synth from the keyboard will not put enough stress on things to show anything up.
[23:15] <len-dt> Some of these "House" guys do _everything_ with a synth.
[23:15] <ailo> When you play live it's not as easy to tell, unless you are a kb player. The best is to make one bar of music with any sequencer, and just copy it. Then record it
[23:16] <ailo> If you don't trust your ears you can always check the audio file for inconsistency
[23:16] <ailo> There is a huge timing error with alsa midi normally
[23:16] <ailo> Not internally, when only using software
[23:16] <ailo> But, when you send midi out to an external device
[23:16] <len-dt> ailo, So jack would have the same problem then?
[23:17] <ailo> jack midi should be reliable
[23:17] <ailo> though, a2j is not going to help
[23:17] <len-dt> Seems to me jack uses asla?
[23:18] <len-dt> a2j doesn't bridge external ports, I use jack set to "raw"
[23:19] <ailo> I have three types of midi I can try. usb, pci and firewire. Only the last one is jack midi capable
[23:21] <ailo> I think. Anyway, I still need to set up these machines for testing. Better get the image server working..
[23:22] <len-dt> ailo, a2j would help because it takes internal alsa midi and bridges to jack where the  external midi is.
[23:23] <ailo> len-dt: If the external midi is jack, yes
[23:23] <len-dt> What does the "midi raw" setting in jack mean?
[23:29] <ailo> len-dt: Not sure, but both raw and seq are jack midi
[23:29] <len-dt> ailo, I'm just reading up on it now.
[23:32] <len-dt> ailo, it says that the -raw option bypasses the alsa sequencer.
[23:32] <len-dt> It does still use the alsa hardware interface.
[23:42] <len-dt> ailo, It is not very informative ... http://murks.lima-city.de/serendipity/index.php?/archives/7-ALSA-and-JACK-MIDI-explained-by-a-dummy-for-dummies.html
[23:43] <len-dt> It doesn't say what the difference from raw to seq is, but does seem to think seq is better timing wise.
[23:43] <len-dt> I think it means that seq bridges after the alsa seq.
[23:45] <ailo> docs are sketchy everywhere :P
[23:46] <ailo> rebooting
[23:52] <len-dt> ailo, looking at this page: http://wiki.linuxaudio.org/faq/start under :Q: What is the difference between Jack-Midi and Alsa-Midi?
[23:53] <len-dt> There seems to be a better explanation.
[23:53] <ailo> len-dt: Yeah, so there is a difference in timing
[23:54] <len-dt> It looks like setting midi=raw and using a2j to bridge softsynths to jack would be the best.
[23:55] <len-dt> ailo, in Jack for audio, the latency is a known amount and a recorder can compensate.
[23:55] <ailo> Why is that?
[23:55] <ailo> latency is not the problem, while timing is
[23:55] <ailo> It's like having a drum player who sometimes is too early, sometimes too late
[23:56] <len-dt> So midi jitters?
[23:56] <ailo> Not a constant diff, but a one that varies in either direction
[23:56] <ailo> I guess
[23:56] <len-dt> :P
[23:56] <len-dt> If it was constant that would be ok.
[23:56] <ailo> Every single midi message has a random +/- timning issue
[23:57] <ailo> Specifically for external devices. That is at least my personal experience
[23:57] <ailo> I haven't tried all my gear either
[23:57] <len-dt> That makes sense that it would only be external.
[23:59] <ailo> Shit, it worked
[23:59] <ailo> booting from the network