[11:50] <ScottL> abogani, I was running the -rt cyclictest last night, do I need to run it when I'm doing other things (i.e. recording, surfing the web, anything?)
[11:50] <ScottL> or just let the test be the load?
[11:50] <ScottL> should I do it several times?  once? thrice? more?
[11:52] <ScottL> I also did about fifteen minutes of recording hydrogen and guitar to test the -generic kernel
[11:53] <ScottL> was very surprise that I cold maintian 2.37ms or 2.9ms (don't remember) pretty darn consistanly with -generic kernel
[11:53] <ScottL> Hydrogen dropped the JACK connection once, but I couldn't determine if that was the fault of JACK, the kernel or hydrogen (since hydrogen is the new versionj)
[11:54] <ScottL> I will spend a few more days with the -generic kernel before I move on to a different kernel just to be thorough
[11:55] <ScottL> abogani, also, do you want this information documented?  if so, how?  is email okay?  should I make a wiki page for posterity?
[11:55] <ScottL> I think tonight I'll route some of my previously recorded audio through JAMin and see what increased CPU cycles do it as well
[11:56] <ScottL> persia, we were speaking of leads earlier, which lead should check for Ubuntu Studio releated bugs in launchpad?
[11:57] <ScottL> which lead should be considering the Ubuntu Studio vs Debian version number web page
[11:57] <persia> Everyone should be checking bugs.  That's not a lead thing.
[11:57] <ScottL> lastly, which lead should be keeping up with new upstream releases?
[11:57] <persia> I would expect both a project lead and a tech lead to nag folks if not enough people are helping with that.
[11:58] <persia> New upstreams, etc. is probably more of a tech thing, but other folks may also have opinions.  I don't believe we need to track that so closely, but should rather focus on having a well-integrated experience, even if it means we don7t have the latest of something.
[12:01] <ScottL> thank you for the answers persia
[12:01]  * ScottL forgot to set alarm and is now leaving a little late for work :(
[15:48] <ScottL_> abogani: did you read my previous messages?
[15:50] <abogani> ScottL_: There isn't a way to record "performance". Real-time change a bit with hardware, software and with type of use you do of your computer.
[15:51] <abogani> ScottL_: So the only one thing that a person can do is test it for himself.
[15:52] <abogani> ScottL_: You can compare -generic, -lowlatency or the kernel that you whant but results are valid only for you and for your systems (computers).
[15:53] <abogani> ScottL_: Please use what fill your needs but follow this rule: -generic, -preempt, -lowlatency, -rt, -realtime
[15:54] <abogani> ScottL: If -generic is enough for you stick on it! In this case you are lucky no need to fight with the beast (beast == kernel linux) :-)
[15:56] <abogani> ScottL_: The developers use some type of hardware to obtain comparable results ( for instance parallel port attachable devices or IO external cards)
[15:58] <abogani> ScottL_: Some UStudio developers try to evaluate kernel counting how many x-runs occurs. But again this isn't universal valid test case.
[15:59] <abogani> ScottL_: Sorry if my answer let your disappointed.
[17:43] <ScottL_> persia: you mentioned earlier that I probably should download the source code via apt-get when using bzr, your comment was that it would possibly prevent many common errors or something similar
[17:45] <ScottL_> can you elaborate which types of errors this might prevent?  Also, it seems that I should 'bzr branch' first, then download the source code; is this correct?
[22:30] <crimsun> I'd go even further [than what abogani said] and mention that xruns are not a particularly useful metric at all
[22:40] <ScottL> crimsum, it is possible to perform any test then that can be quantized and compared between users though?
[22:47] <crimsun> ScottL: sure, latency as measured by the driver -> jackd
[22:49] <ScottL> okay, then given a standardized setting in jack (i.e. realtime, frames/period, etc) we could build useful data again -generic, -lowlatency and -rt, no?
[23:36] <crimsun> ScottL: per-hardware and configuration, yes
[23:36] <crimsun> ScottL: abogani's point stands that you can't measure based on raw numbers alone
[23:37] <crimsun> ScottL: but xruns themselves just don't offer anything even when given across hardware and config
[23:40] <ScottL> yes, i agree.  I was hoping we could develop a codified test (or standard) to give people for two reasons:
[23:41] <ScottL> 1. this way the data is useful and comparable and hopefuly correlations are found
[23:42] <ScottL> 2. I think (and feel very strongly) that most people would be more involved if they were told exactly what to do, the casual user will invest little time to research how to do something for someone else even if it is ultimatly to their own benefit