[20:27] <ScottL> bug 726199
[20:27] <ScottL> holstein, ^^^ this is the bug for updating the menu, are you still interested?
[20:55] <holstein> ScottL: yeah, im in
[20:55] <holstein> i'll ping you tomorrow
[20:55] <holstein> things chill out for me for a few days
[20:59] <ScottL> cool :)
[20:59] <ScottL> i closed out a quite a few bugs today :)  i feel pretty good about that
[21:00] <ScottL> ailo, i have a stable computer for testing kernels at the moment (although i hope to start backporting soon), so if you have preferences on what you would like to see me do please let me know
[21:01] <ScottL> one thing i think i would like to try is to try to heavily load the computer with multiple tracks with multiple plugins and see how the -generic vs -lowlatency kernels perform
[21:01] <ScottL> after establishing a base line for both of them with extremely moderate loading
[21:01] <ailo> ScottL: Haven't been working on that much lately. The problem is not only using a routine for testing, like a test suite, but also gather data to see what is causing xruns. 
[21:02] <ailo> ScottL: My impression is that heavy load is not a primary cause for xruns
[21:03] <ailo> ScottL: My impression is that xruns will only happen if 1. the CPU load reaches absolute maximum with realtime processes 2. An app is not well programmed to deal with realtime at low latencies
[21:03] <ailo> Or 3. Something else, unrelated to the audio apps is doing it, like the Networking hardware
[21:06] <ailo> But, I don't have any way of putting that on paper. Would be good to learn more about gathering data from the system. From what abogani showed me about catching kernel messages, it doesn't seem that straight forward. I will have to learn more about that. 
[21:08] <ailo> The biggest problem I see is if there are other things, unrelated to audio that is interrupting the audio process, even though there's plenty of room for the audio process to exist. 
[21:10] <paultag> ailo: how goes?
[21:11] <ailo> As for evaluating performance on the -lowlatency kernel, I don't think there's anything more needed to be done for enhancing audio priority, since it's superfast in my opinion.. Rather to get rid of other disturbing processes, that interrupt the audio process, whatever they are.
[21:11] <ailo> Hey, paultag.
[21:11] <paultag> s'new?
[21:11] <ailo> Not much. I'm taking a break from US development, and doing some work of my own. 
[21:11] <paultag> sweet. What are you working on?
[21:13] <ailo> Puredata patches. Trying to create some sort of simple IDE. I find that after getting to a certain limit, I loose oversight of the whole thing. Need a task-manager and I use issue reporting too.
[21:14] <ailo> I have redmine installed on my server, so I use that to keep track of things.
[21:14] <paultag> sweet
[21:14] <ailo> Looking back at a lot of things, I don't even remember I was working on them. It's like the brain can only hold that much info.
[21:16] <ailo> Any skiing lately, paultag?
[21:17] <paultag> ailo: sadly no! I've been super stressed. Working on a quick two-minute hack to fix my shell, which should be nice :)
[21:17] <paultag> I hate that bash can't highlight regular lines that come out of programs
[21:17] <paultag> so, fuck it! Time to implement it :)
[21:18] <ailo> paultag: You want to catch certain messages more easily?
[21:18] <paultag> ailo: well, most debian / ubuntu tools use prefixes to lines, such as "I:" or "W:". I want to highlight those in a color :)
[21:20] <ailo> paultag: On the -controls. I want to replace the shell commands with Python code. I realized there's a big library that deals with apt. Only thing missing is to use that in superuser mode.
[21:20] <paultag> Oh shucks. I think I need to do homework
[21:20] <paultag> ailo: :)
[21:20] <paultag> ailo: great! Awesome work! :)
[21:21] <paultag> ailo: we already missed FF, so let's make sure we don't rush it. 28th ain't no deadline anymore
[21:21] <paultag> BRB
[21:25] <ailo> ScottL: It would perhaps be interesting to test the -generic kernel, if it perform as reliably with audio, even though we already know it won't give you anyway near acceptably low latency for live processing. By reliably, I mean, if it will work without causing xruns at say 512 frames/period (I think that's the lowest number that works for me).
[21:26] <ScottL> ailo, generally what i have done before is keep lowering the frame/period down until i started having xruns (not the kind when you start apps, but while recording)
[21:26] <ScottL> then back up one and call that "stable"
[21:27] <ScottL> i usually do this a few times (maybe three) to make sure it's really there
[21:27] <ailo> ScottL: From my experience with -lowlatency, I won't get xruns because of system load from audio processes, but I don't know if this is true for the -generic as well.
[21:27] <ScottL> last time i tried with this computer i got stupidly silly frame/period and latency with onboard sound!
[21:27] <ScottL> with the -lowlatency kernel
[21:28] <ailo> -lowlatency for me is working just as well as the -rt kernel did. The -generic is noway near the same latency.
[21:28] <ScottL> i don't remember exactly but i think with -generic i was around 512 or maybe 256 frames/perdio but with -lowlatency it was at 32 frame/peroid stable and 16 with a some xruns
[21:29] <ScottL> but that took the latency from 23msecs down to around 5 msecs
[21:29] <ScottL> i think that is very, very appreciable
[21:29] <ScottL> :)
[21:29] <ailo> Wow, I can't even start jack with 16. At 64 frames/period I get reliable performance with audio apps.
[21:29] <ailo> On the -lowlatency
[21:29] <ailo> About 2-3 ms
[21:31] <ailo> Or, did. Lately I get a few random xruns now and then, probably caused by networking.
[21:31] <ScottL> oh, with 16 frame/period i was getting 1.6msec latency with some xruns
[21:32] <ScottL> ailo, that's a good point too, networking, espeically now that we should be using network-manager, might have an appreciable impact on latency/xruns
[21:33] <ScottL> paultag, when you get back i would like to talk with you and ailo about the RC bug for -controls and making sure we get there from here :)
[21:33] <ailo> ScottL: After following aboganis instructions, we found that the kernel process for the wireless card was getting realtime priority. He said they were working on fixing that upstream. 
[21:34] <ScottL> ailo, oh WOW, um, that's a pretty important "oops", isn't it :P
[21:35] <ailo> I still know too little about , so I can't really say what is going on. Seems like something that suits a server more than an audio work station, anyway
[21:36] <ailo> The -controls are fully functional right now, though  need to be packaged and tested. Also, I need to improve some bits in it.
[21:40] <ailo> I also think we should try to get the -lowlatency uploaded. We can't make serious audio work without it :(
[21:53] <paultag> ScottL: sure
[21:53] <paultag> ScottL: I need to run out, I'll read backlog
[22:13] <ailo> ScottL: What do you want to know about the controls? If you want, you can test it to see the state of it.
[22:14] <ailo> Just do: git clone git://gitorious.org/ubuntustudio-controls/ubuntustudio-controls.git ubuntustudio-controls
[22:15] <ailo> And go to ubuntustudio-controls-0.5/ubuntustudio-controls-0.5/src. Make sure you have aboganis repo added
[22:16] <ailo> Then do ./ubuntustudio-controls to start the program. (only works in Natty, from what paultag said).
[22:16] <ailo> Don't know yet if there are any dependencies to watch out for.
[22:20] <ailo> ScottL: Should work without installing anything extra. Just realized I had it working on a fresh install of Natty.
[22:22] <ailo> The actual "apply" commands is a little buggy. That part I will replace.
[22:23] <ailo> It works, but you'll see what I mean
[22:56] <ScottL> ailo, paultag: there are a couple of issues i'm thinking about, 1) the -lowlatency kernel and 2) freeze exception/getting it finished
[22:56] <ScottL> 1) aboganni doesn't seem to want to provide a kernel currently so i wouldn't expect to get the -lowlatency kernel into the repos for natty
[22:57] <ScottL> that kinda makes it difficult currently, but sets us up nicely i think for natty+1
[22:57] <ailo> ScottL: If that is the case, we will have to decide if to add a PPA for it at least. If not, we just remove that function all together. Did you try the app yet?
[22:57] <ScottL> 2) if we can commit to getting it done and maybe setting a deadline then i'll work on the freeze exception
[22:58] <ailo> ScottL: If I can get some help with packaging, I might be able to finish the program a little quicker.
[22:58] <ScottL> ailo, i have not tried it yet, been doing stuff with family and about to go pick up takeout dinner
[22:58] <ScottL> ailo: maybe paultag can help you wrap it up :)
[22:59] <ScottL> ailo, are we not including the ability to install the -rt kernel as well?
[22:59] <ScottL> if so, then both can go into the PPA
[22:59] <ailo> ScottL: Don't know if paultag is much wiser about python packaging. Just reading about that. 
[23:00] <ailo> ScottL: Someone would need to build an -rt kernel first, no? If there is one, I will of course add that to the -controls.
[23:01] <ailo> There's supposed to be a realtime patch coming out for 2.6.37, but I hear a lot of the patch is already in the vanilla kernel. Don't know when we can expect it to be ready.
[23:02] <ScottL> ailo, there is an older -rt kernel, .33 perhaps?, that people are using, if we host it in ppa we don't need align with what desktop is using
[23:03] <ScottL> ailo, paultag: i was thinking that if we only get setting the user in audio group and fix setting rtprio, etc to the correct file for natty, that should be enough to justify the RC bug
[23:03] <ScottL> because currently -controls sets the rtprio in the wrong file and probably causes instability
[23:03] <ScottL> then we can shoot for -lowlatency and -rt kernels for natty+1 perhaps
[23:04] <ScottL> less pressure and we can work through the -kernel better perhaps
[23:04] <ailo> The current -controls is not doing anything right, which is why I think, if we do not backport the one we are working on now, we should at least remove the old one from the repos.
[23:05] <ailo> Don't know how far back the problem goes. At least Lucid, maybe Karmic as well
[23:05] <ailo> Firewire is set up right until Lucid, I think
[23:38] <ScottL> ailo, if we can get -controls working then i will see to it to get it backported, especially to the LTS version
[23:38] <ScottL> ailo, and are you speaking of setting the rtprio and memlock in the correct file?
[23:38] <ScottL> or is there another problem with -controls from maverick and lucid?
[23:39] <ailo> ScottL: Don't know when audio.conf replaced limits.conf, but I think since Karmic
[23:40] <ailo> Firewire is another story. I think the setup works in Lucid, because it's the old stack. Not on Maverick, because of the new stack, and on Natty we don't need it anymore.
[23:43] <ailo> ScottL: The controls I've been working on are functional, but need maybe a few days of work. In the worst case, I can finish up it in a couple of days and have it work nicely. Packaging still needs some attention.
[23:48] <ScottL> ailo, do you know why firewire doesn't work in maverick?  should i ask holstein since he has a firewire device?
[23:49] <ailo> ScottL: It's an easy fix.
[23:50] <ailo> ScottL: The name for firewire changed, so the file that gives @audio prio to firewire needs to use the new name
[23:50] <ailo> But, we'll cross that river when we get there. Each release needs a different backport.
[23:52] <ailo> ScottL: So, no -lowlatency option on the -controls at all?
[23:53] <ailo> In that case we are left with (for Natty) 1.giving user realtime privilege, 2.adjusting memlock, 3. installing restricted extras, all of which are functional right now.
[23:54] <ailo> For Maverick and Lucid we would just need to re-add the firewire enabling. But for each release, it would work differently.