[00:06] <zequence> Len-nb: I need to do more testing, but from what it seems, nouveau does in deed seem lousy for low latency
[00:07] <zequence> The difference I got from cyclictest was around 10x more latency when stressing on nouveau
[00:08] <Len-nb> Could be. It depends on what someone is doing. moving a solitaire card across the screen takes a lot of system use.
[00:09] <Len-nb> zequence, lowlatency should be tested with audio SW (or video editing).
[00:09] <Len-nb> testing with games or other desktop sw does not make sense,
[00:12] <zequence> Len-nb: What you do is you run jack, and see if you make it have audio dropouts.
[00:13] <zequence> With a jack application, of course
[00:13] <zequence> Funny. Now I'm suddenly having the same sort of performance as I did on Natty almost
[00:13] <zequence> Not a single xrun on 64 f/p. 
[00:14] <zequence> As long as you're not using other realtime processes, it doesn't really matter what it is. It shouldn't budge the audio process
[00:14] <Len-nb> Ya my testing was with 32 and audio apps setting cpu to 60% or so, no drop outs for over an hour.
[00:15] <Len-nb> firefox was on and  did go from workspace to workspace
[00:16] <Len-nb> I haven't had problems at 64 even with hyperthreads on.
[00:16] <zequence> Len-nb: What kind of graphics do you have on that machine?
[00:17] <Len-nb> older nvidia
[00:17] <Len-nb> open driver
[00:18] <zequence> There are some variables at play here. For me, nouveau was total crap. This is a farily modern card. 
[00:18] <Len-nb> Gotta run... the family wants to go bowling
[04:03] <Len-nb> zequence, I think that is the divider, I have an old card. The driver has gotten better for me in that it handles more things, but I have not seen any speed increase.
[04:04] <Len-nb> With the newer card the driver tries to do more and prolly needs more work.
[04:42] <len-1304> zequence, have you looked at http://wiki.linuxcnc.org at all? http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Latency-Test has a list of better and worse MB for low latency work.
[04:44] <len-1304> There is a trouble shooting link from that page that when talking video says "Avoid anything nvidia"  :)
[10:08] <zequence> len-1304: Well, nvidia may be a problem, but considering nouveau are open, those can be made efficient. 
[10:09] <zequence> And they've probably not been working on getting their drivers to work well in realtime enivronments
[10:10] <zequence> len-1304: I saw rt-tests has a tool for measuring HW latency. Need to look more on that
[10:12] <smartboyhw> Hey zequence 
[10:12] <zequence> smartboyhw: hi
[10:13] <smartboyhw> zequence, working on a Ubuntu Studio release checklist as said earlier
[10:14] <zequence> smartboyhw: good. on the wiki?
[10:14] <smartboyhw> zequence, not yet. I don't like editing on the wiki for the draft... I will push it to the wiki soon, possibly in 4-5 hours
[10:15] <zequence> I'm much too unprofessional to do it properly myself. I tend to edit the wikis directly
[10:15] <smartboyhw> oh
[10:16] <zequence> len-1304: you should try using a realtime kernel, just to see the difference. debian wheezy has one which at least on my machine performs better than with -lowlatency
[10:58] <zequence> len-1304: you should probably be able to run ice1712 at 16 f/p, but it'll creash easily, if you start any kind of jack program with it
[13:00] <smartboyhw> zequence, https://wiki.ubuntu.com/UbuntuStudio/ReleaseProcedure
[13:00] <smartboyhw> First draft
[13:02] <zequence> smartboyhw: Nice work. Just one note. We should try to keep the release specific work as much contained within the group that handles the relase
[13:02] <smartboyhw> zequence, i.e. which step?:P
[13:07] <zequence> smartboyhw: I don't think the doc team should handle release notes. The doc team is more of a User Guide writing team
[13:07] <smartboyhw> zequence, sorry
[13:07]  * smartboyhw edits it
[13:08] <zequence> Better either a release team does that, or the core team. I might prefer the release team in this case
[13:08] <smartboyhw> zequence, ok..... If scott-work wants to use the -core team I will edit it
[13:09] <smartboyhw> zequence, edited the doc-team -> release team part
[13:11] <zequence> smartboyhw: Seems like that was the only thing actually. One thing I would like to do though, is to condense the text. This is purely form a practical point of view. Each point should be as short as possible, and only contain words and links you absolutely need in order to understand what the point is about
[13:12] <zequence> For example, point one, I would write: Dev Team ensures all milestone targetted bugs are fixed for this release.
[13:12] <smartboyhw> zequence, yep. We need to simplify. But then I like technical things:P
[13:13] <zequence> Or, for "the release"
[13:14] <zequence> smartboyhw: It's just a detail, but one I think is important. It makes it so much easier for other people to follow what the plan is
[13:14] <smartboyhw> zequence, :)
[13:16] <zequence> This is something I try to think about all the time, when I write docs. If you can formulate information in a way which is time efficient to read, and also easy to understand, chances are people will be more efficient with their work, as the clues to what they need to do are so easy to follow
[13:16] <smartboyhw> zequence, OK
[13:17] <zequence> Assume everyone is a lazy moron
[13:17] <smartboyhw> zequence, lol
[13:17]  * smartboyhw is one
[13:17] <zequence> I wouldn't suggest for you to do it this way, if you were writing docs for IBM
[13:18] <smartboyhw> zequence, LOL LOL LOL LOL LOL LOL LOL
[14:39] <smartboyhw> zequence, do you remember the rt ticket we submitted? When will it be done?
[14:41] <smartboyhw> Clearly the Canonical IS isn;t listening
[15:20] <len-1304> zequence, Re, RT stuff in general. I would be interested in the video editors POV.
[15:21] <len-1304> I don't know how important latency is for that.
[15:21] <len-1304> For the graphics person, raw throughput is probably more important.
[15:26] <smartboyhw> zequence, someone in #ubuntu+1 said
 interesting, we've been changed to the -lowlatency kernel build
[15:26] <smartboyhw> !?
[15:29] <smartboyhw> zequence, as it turns out: that guy actually manually used our kernel cause it's good