[02:43] len-dt: But which of those things made the operation stable? Was it only removing ath9k, or all of them combined [02:44] We'll need test systematically, and document everything on the wiki later. Put up numbers, and maybe write some notes. [02:44] And to increase resolution, we should probably adjust frames/buffer as well [02:44] Between 2 and 3 [02:45] So far it seems like you're getting a personal experience from these tunings, that only applies to one or two machines. We need more machines, and the same testing procedure on all of them [02:46] Even though, that experience of course is valuable when forming the tests [02:47] Time for another morning lap.. [03:55] Every time I go the US user channel, there's been someone asking a question and then waited patiently for 3 min before leaving [03:59] len-dt: This might be handy for something http://www.ubuntu-mini-remix.org/ [04:09] astraljava: At some point I think it would be good to document some of the things that ubuntu devs do. It's kind of hard to form a picture about the whole procedure, since there's really no documentation about it right now [04:11] It would especially be helpful for new people wanting to join the dev team [04:11] ailo, running test 2, swappiness turned down to 0. 6 hours so far no xruns. [04:15] len-dt: Could you reproduce the xruns you think you might have cause by stopping the screen saver? [04:16] Also, I don't know if I am correct in assuming that -lowlatency is not 100% realtime, and there may be random xruns at any point, without any apparent cause [04:27] astraljava: I'd like to go ahead and clean up the other wiki too. A lot of it is outdated, and those pages should either be removed or updated. One thing that is not clear to me is what roles people have in the team. I think it would be nice to update this page with relevant info http://wiki.ubuntu.com/UbuntuStudio/TeamStructure [04:36] len-dt: What do you do when testing, other than keeping jack on? [04:36] Usually, jack itself is much more reliable than when you start using a program with it [04:37] Ardour is probably one of the best performing jack apps [04:38] If you are to test swap, wouldn't you need to challenge it somehow, by using the system for music production, but something that would normally involve swap? [04:38] I'm just thinking out loud [04:39] One simple thing that may cause xruns is just opening and closing windows, having the graphics work a bit [04:44] ailo, this morning I got a pile of xruns with just jack running. Twice. I want to figure out what that was first. I have to have a baseline. [04:44] len-dt: Maybe try stuff with a minimal system, running only from the terminal? [04:54] ailo: I would appreciate it very much. :) Could you write on the -devel list and ask people to update their commitments and responsible areas? [05:04] Bad internet. Bad, bad internet.. [05:13] ailo, I have tried stressing the system and found that I can run audio stuff till I run out of memory. CPU cycles is not a problem. [05:14] Jackd is ,even at rest, putting out 44100 16 or 24 bit words to each channel even if they are all zeros. [05:17] If something can muck up that even at idle, I need to know. My thought is something swapped... probably back in would be the worst. with swappiness at 0 that shouldn't happen. I'll know tomorrow :-) [05:17] len-dt: That is my conclusion too. Even when having both cores at 100% for lengthy periods, it won't bother jack, unless there is a realtime process competing with jack. And most processes are not doing that [05:18] Once I have this problem solved I will turn things back on one at a time [05:18] starting with PA-jack bridge. [05:20] cron may take some time to test. I will have to test it with eth0 connected because wlan is a known problem for me (and If what I hear is correct a significant number of other people) [05:21] ailo, Some things are less worrisome than others. Those things that cause problems right away as soon as they are turned on are easy to fix. [05:31] It is rather the things that don't cause problems most of the time, like cron and friends, but could start something in the middle of things. [05:31] ailo, You may have missed some [05:39] len-dt: Yeah, my connection sucks today. Need to wait almost 3 months to replace this crappy service [05:40] Yuck. [05:41] ailo, now that your back... I'm off to bed. I'll see where my xruns are in the morning. [05:41] len-dt: Ok. Good Night [06:37] Seems like I won't be doing much work online today. Might as well do other things [06:37] I'm logging out until this connection gets better === saidinesh is now known as saidinesh5 [11:54] hi [13:28] scott-work, Sent you what I could for a bluprint. to your gmail [13:43] len-dt: i got it, thanks :) [13:43] scott-work, great. [13:44] i've had a slightly disappointing weekend where i dealt with some unexpected issues and didn't get many things done that i had intended [13:44] :( [13:44] blueprints being one of those [13:44] i hope to get them resolved in the next few days [13:45] scott-work, I figured. NP I have been going ahead with testing. some things. Read the irc logs if you are interested/have time. [13:46] i will read them, it may be in a couple of days however [13:46] scott-work, I figured having the BP was more important. [13:49] this is a holiday in Canada so I am home till the family figures out where we are going. [14:21] we have a holiday next monday, it's possible kate stewart (the release manager) might yell at me before but if i don't get the blueprints done soon i will have a three day weekend to complete them ;) [14:27] scott-work, it seems may 31 is the deadline? [14:35] is it? do you have a link? [14:38] scott-work, https://wiki.ubuntu.com/QuantalQuetzal/ReleaseSchedule [14:38] may 31 is FeatureDefinitionFreeze [14:40] i think that's more for "features" in applications, so this gives time to work out bugs in new features [14:40] https://wiki.ubuntu.com/FeatureDefinitionFreeze talks about "landing in main" [14:40] "main" being the main repository for applications [14:42] scott-work, the whole idea of bluprints and all these dates for this and that are still kind of confusing for me. Starting to make sense, but mostly someone says this has to be done by this date, I just go "OK" [14:44] Thats what you are there for :-) [14:46] hehe [14:47] unfortunatly i don't think the blueprints are really documentated to the point where they due date is published [14:47] this is a good place for much information about blueprints: http://status.ubuntu.com/ubuntu-quantal/about.html [14:47] i am remiss to not have pointed it out before [14:47] and this is different than the one i gave before [14:48] this is more techincal knowledge about how blueprints are made and used [14:57] For some of us it is too much information anyways. [14:58] scott-work, anyway. I have a working mode change setup now and am using it to test tweaks. [15:14] eh, len-dt, i realize they changes some of that status.ubuntu.com blueprint information [15:15] https://wiki.ubuntu.com/WorkItemsHowto has other information about how to stage work items, this is actually more handy [15:15] granted it is still a lot of information but it shows you how it will be used [15:31] just learning about how the kernel does swapping... it seems if the kernel swaps in something even not to do with audio. The swap itself can affect the audio performance. [15:43] scott-work, so generating bugs seems to be the preferred way of adding things. [15:54] The whole idea being to automate progress tracking. [16:00] len-dt: i wouldn't say "bug" that bugs are to be used for feature requests or improvements, but i agree that the intent is to automate progress tracking [16:00] errr [16:01] "i wouldn't say that bugs are to be used..." [16:01] things like unity or multiple-monitor improvements probably didn't have many bugs when they started the process (although i'm sure bugs now exist for them) :P [16:04] scott-work, what I was saying I guess, is that the progress reports prefer to point to a url such as a bugreport/feature request rather than have textual changes in it's own document. [16:05] And reading again, there will be some things that are put in text when the document is created, but bugs are what is expected for changes after that. [16:07] Anyway, I am probably focusing on tweaks and apps for setting tweaks this cycle. Fixing the menu and adding something like qasmixer would be nice too [16:07] i would say that blueprints serve various functions, not all of which are used everytime [16:08] sometimes they are used for brainstorming and then developing into actionable "work items" and finally used to track progress [16:08] sometimes the brainstorming is quite an extensive time [16:08] others the brainstorming isn't really needed because both the problem and solution are clearly defined (which is usually the case with us for most times) [16:09] your blueprint might include more of the brainstorming because we are still exploring what might and what might not be a solution [16:09] although by the time the blueprint is actually written, you might have already worked through that issue :P [16:10] but mainly i think blueprints were conceived of a way to define (overall) what improvements (whether new features or fixing things) are to be done during a cycle and then tracking that progress [16:10] scott-work, I am finding out why I am not in management... :P To me this is all about saying the same thing in different ways, something I am not too good at or perhaps not too patient with [16:11] I can see the need for standardising the way things are laid out though. [16:11] sometimes the differing semantics are important, but probably not in most of these cases [16:15] I'm best with tinkering I think. I'm learning to be careful not to assume too much and try to make sure the results I am getting really say what I think they do.