[02:10] <ScottL> falktx_, did you need something earler?
[02:11] <falktx_> ScottL: i just asked about what CMS you guys prefer
[02:11] <falktx_> joomla, drupal or wordpress
[02:11] <ScottL> drupal for the website
[02:14] <ScottL> troy_s, your comments the other night about dvd authoring being dead got me thinking about what an audio distribution could offer a musician
[02:14] <troy_s> ScottL: LOL. Your mind works in strange ways.
[02:14] <ScottL> troy_s, brainstorming a few ideas and will send an email to the mailing list later to see if anyone is interesting or wants to contribute
[02:15] <ScottL> troy_s, i enjoy thinking outside the mainstream box, most people scare me with the way they think
[02:15] <ScottL> troy_s, of course most of my "thinking" is really just ADHD
[02:16] <ScottL> troy_s, but your comments/questions months and months ago about "what is ubuntu studio and who is it for" has stuck with me and i think about it often
[02:17] <troy_s> ScottL: Don't blame the lunatic.
[02:17] <troy_s> ScottL: We are utterly fearful of outwardly rejecting audiences (inner geek / nerd perhaps?) that we utterly fail to deliver to anyone in any great capacity. 
[02:17] <ScottL> troy_s, no, no, it's a good question and it's one that probably should be asked periodically
[02:18] <troy_s> ScottL: Just track the progress and you will see what I mean. In fact, track back far. I'll wager that the tendrils run deep.
[02:18] <ScottL> in some ways it might be like peeling away the layers of an onion, once you eliminate what it isn't you are left with what it is
[02:21] <troy_s> ScottL: The core of all is audience as Jim Krause says - "Audience governs all." and in that you can sum up about all of Don Norman's work and plenty of other famous folks.
[02:22] <ScottL> troy_s, i haven't really found a good way to articulate my thought yet, but i would like to explore how ubuntu studio can facilitate today's musician with exposing their music/video to others
[02:22] <troy_s> ScottL: Audience gives context and helps to define needs. Saying 'everyone' is a complete lack of respect for design. It cannot be done. It makes horrible assumptions about cultural values, about age demographics, about prior knowledge, about societal norms, etc.
[02:23] <troy_s> ScottL: Erm... that wouldn't be Ubuntu Studio would it? Unless you had some sort of single click to publish thing with Jamendo or Magnatune. And even then, that doesn't work.
[02:23] <troy_s> ScottL: That whole rubbish of unfettered such is just anarchy... it doesn't work worth a rat's ass. Look at Android's market for example.
[02:24] <troy_s> ScottL: So realistically, there is no magic bullet for a musician there either. Can you create work with it? I have no clue. I do know that if the audio works are as gimped as... uh it shall remain nameless, then the answer is no and it is hopeless to aim even as high as intermediate.
[02:25] <ScottL> troy_s,  i was thinking about tools that would help convert to formats for vimeo or youtube and then a mechanism to automate posting their work to the same along with soundcloud, bandcamp, et al
[02:25] <ScottL> troy_s, and maybe even including a tag line to send via identica
[02:26] <ScottL> "listen to my new song at..."
[02:26] <ScottL> but this is just a single thought line from a single person
[02:26] <ScottL> maybe i spark someone else's imagination and they think of something completely perpendicular but utterly brilliant
[02:26] <troy_s> ScottL: Sounds interesting. No idea if that appeals to a given audience type. 
[02:29] <ailo> ScottL: I think documentation for standard workflows is a good start.
[02:31] <ailo> ScottL: If we think unix-like maybe such things like ladish will let us join all our little programs together. A lot seems to have to do with software design.
[02:32] <ailo> Still haven't tried that myself, though :)
[02:35] <ailo> Adding ways to publish on the web, aught to be providing info and links
[03:10] <ScottL> TheMuso, i have added a patch to the gnome-classic default xsession bug 702712
[15:39] <ScottL> hi rlameiro 
[15:39] <rlameiro> Hey ScottL :D how are you?
[15:42] <ScottL> rlameiro, doing well, fixed many things lately, lots of people working on good stuff for the future :)
[15:42] <ScottL> today is also by daughters birthday party, i'm not really looking forward to having a crapload of pre-teen girls in the house today and "sleeping" over tonight
[15:42] <rlameiro> Nice... when is alpha 2 going out?
[15:42] <ScottL> i say "sleeping" because they really don't seem do any of it
[15:42] <rlameiro> ooops...
[15:43] <ScottL> we did this last year as well
[15:43] <ScottL> !schedule
[15:43] <ScottL> hmm, that's not it
[15:43] <ScottL> !alpha2
[15:43] <ScottL> february 3rd is alpha2 according to
[15:43] <ScottL> https://wiki.ubuntu.com/NattyReleaseSchedule
[15:44] <rlameiro> hummm almost there
[15:44] <ScottL> hopefully we get the gnome-classic default xsession patched and included before then :/
[15:44] <rlameiro> ScottL: what do you thing that are the most important testing procedures for US?
[15:44] <rlameiro> I was thinking in making at least 3 audio tests....
[15:44] <ScottL> i still have to see about fixing the tasksel as well, but i'm not worried about getting it necessarily for A2
[15:44] <rlameiro> 1 - Onboard /souncard test
[15:45] <rlameiro> 2 - USB interface test
[15:45] <rlameiro> 3 - Firewire test
[15:45] <ScottL> all good tests
[15:45] <rlameiro> I think making to much test can be bad
[15:46] <ScottL> ailo has been giving thought to testing as well, and documenting some of his and holstein's findings
[15:46] <rlameiro> humm ok
[15:46] <ScottL> they really starting digging into what it takes to make a firewire interface work
[15:46] <rlameiro> I need to talk to them
[15:46] <ailo> Yeah, it would be good to make some documentation for testers. 
[15:46] <rlameiro> ailo: yeap...
[15:46] <ScottL> rlameiro, i think you and ailo might work together to cover more ground and faster, maybe divide the work
[15:46] <rlameiro> that was suposedely my job.... but i am slacking a lot....
[15:46] <rlameiro> shame on me
[15:47] <ailo> I've been looking into how to test lowlatency
[15:47] <ScottL> lol, it's all voluntary and other things get in the way
[15:47] <rlameiro> ScottL: tru... like lilypond
[15:48] <ScottL> ailo, i'm thinking of taking some time this weekend and testing the new -generic kernel (2.6.38) and then the -lowlatency and see how it compares then
[15:48] <rlameiro> ailo: what firewire interface do you have?
[15:48] <ailo> rlameiro: I guess it should be pretty straight forward, just collect a list of things that need to be confirmed
[15:48] <ailo> I don't have firewire, but I worked with holstein and a guy named tanders to do some tests
[15:48] <rlameiro> humm
[15:49] <ailo> Already did some initial tests on -generic
[15:49] <ailo> But we would need to have some more variables than just testing jack and maybe jack + a program
[15:49] <rlameiro> I tought  myabe doing an Ardour session with lots of plugins and at least 4 output channels to test firewire...
[15:50] <ailo> rlameiro: You don't have any issue with firewire at all?
[15:50] <rlameiro> ailo: where are ou from /TimeZone?
[15:50] <ailo> +1, but maybe 0 just now
[15:50] <rlameiro> ailo: didnt tested yet in natty
[15:50] <ScottL> along with testing the three audio interfaces that rlameiro mentioned, we should have them verify that they are running with -rt privileges
[15:50] <rlameiro> ok I am on Zero..
[15:50] <rlameiro> I need to go now to a meeting with a composer
[15:51] <ailo> Then I'm on +1 :)
[15:51] <rlameiro> i wil come latter to see about it
[15:51] <ailo> rlameiro: I will be here. Just ping
[15:51] <rlameiro> ScottL: also maybe generic kernel test and abogani kernel test
[15:52] <ailo> rlameiro: Let's make a table of things. 
[15:52] <rlameiro> ScottL: is the Natty US ISO usable?
[15:52] <rlameiro> can i install it on disk?
[15:53] <ScottL> rlameiro, i believe it is, but when you begin to login you will need to select your xsession at the bottom
[15:53] <rlameiro> ok
[15:54] <ScottL> it will default to "Ubuntu Desktop" or something similar, you will need to select "Ubuntu Classic Gnome"
[15:54] <rlameiro> so i will install it tonight ant test it with my firewire and see what is happening
[15:54] <rlameiro> well
[15:54] <rlameiro> I need to go now
[15:54] <ScottL> this is the patch that i mentioned earlier, this will cause it to default to the gnome-classic xsession without having to pick anything
[15:54] <ScottL> bye rlameiro 
[15:54] <rlameiro> cya
[16:26] <ailo> ScottL: I did some testing on the new -generic and as earlier I can confirm realtime from the latest -generic
[16:27] <ailo> So, no reason to add that to the test now.
[16:27] <ailo> But it could be added to a full Documentation of testing a new distro, or a new release of a distro
[16:28] <ailo> I did just a simple testing table according to what rlameiro proposed now. http://paste.ubuntu.com/559948/
[16:43] <ailo> Maybe we can post the tests to the mail list, later to do some comparisons. That could be fun
[16:53] <ScottL> ailo, awesome ideas
[16:54] <ailo> ScottL: It think we should have a script for the test. Then post the results from the script to the mail list. Should be the easiest solution.
[16:55] <ailo> Just one test, to rule them all
[18:06] <ScottL> LOL, but an awesome idea too
[19:10] <ailo> rlameiro: I had some ideas before about testing
[19:10] <ailo> What about making a script, post it on the mail list and let users add their results the list
[19:10] <rlameiro> ailo: fire them up
[19:10] <rlameiro> what kind of script?
[19:11] <ailo> I don't know yet, but at least dealing with jackd
[19:12] <ailo> At first I went with your suggestion and did this http://paste.ubuntu.com/559948/
[19:12] <ailo> But, in order to be precise I think we need a script, that many can use and compare
[19:13] <ailo> We don't need so many testers, perhaps, but it could be fun to post it on the mail list anyway
[19:14] <rlameiro> yeap
[19:14] <rlameiro> well, it would be nice to make a sript that automated the test...
[19:14] <rlameiro> That would be awesome :D
[19:14] <ailo> If we do a script, we could start it  ./script -d alsa -d hw:1 
[19:14] <ailo> Like we would start jack
[19:15] <rlameiro> yea
[19:15] <ailo> Then collect info from the system, start some audio program and collect the results into a textfile
[19:17] <ailo> I don't know what programs or what kind of action to take. though
[19:17] <ailo> Have to eat. Be back later..
[19:21] <falktx> hey guys
[19:21] <falktx> hey rlameiro
[19:21] <rlameiro> falktx: :D
[19:21] <falktx> I have good news
[19:22] <falktx> I made my realtime-31 package based on abogani's one, and it's building
[19:22] <falktx> it it builds ok for lucid, then the same should happen for maverick too
[19:22] <falktx> we may have some realtime kernels soon...
[19:23] <rlameiro> nice
[19:24] <falktx> compiling the kernel takes so much time...
[19:54] <falktx> yay! the kernel compiled!
[19:56] <ailo> falktx: No graphic drivers with those, right?
[19:56] <falktx> ailo: not yet
[19:56] <falktx> ailo: this is still the 31 kernel, in a few days I'll upload 33
[19:57] <falktx> ailo: abogani's 33-rt kernel is outdated though...
[19:57] <ailo> falktx: 31 for multiple distros, and 33 too?
[19:57] <falktx> ailo: yes!
[19:57] <falktx> ailo: 31 is building on maverick now
[19:57] <falktx> (lucid was fine)
[19:58] <falktx> ailo: natty will start build soon
[19:58] <ailo> falktx: I'm sure some firewire users may have use for them. Did you check out the rtirq script yet?
[19:58] <falktx> ailo: oh, not yet
[19:58] <falktx> ailo: what do I need to do?
[19:59] <ailo> falktx: Don't ask me :). But I know you will need it. 
[19:59] <falktx> k
[20:00] <ailo> falktx: http://alsa.opensrc.org/Rtirq
[20:00] <falktx> ailo: I basically just need to update it, right?
[20:00] <ailo> The rtirq needs to be updated at least for the new firewire stack, so that it gives priority to firewire
[20:01] <ailo> firewire being the new name, don't remember the old name
[20:04] <falktx> ailo: latest release of rtirq is from 2009
[20:04] <falktx> lucid is already up-to-date
[20:06] <falktx> if anyone wants to try:
[20:06] <falktx> https://launchpad.net/~kxstudio-team/+archive/kernel/+sourcepub/1478697/+listing-archive-extra
[20:06] <falktx> install the *.all.deb and *.i386|amd64.deb (depend on your arch)
[20:07] <ailo> falktx: Here's how to install the rtirq http://my.opera.com/coreymwamba/blog/2009/01/03/automatically-realtime-priorities-using-rtirq
[20:08] <ailo> I'm not sure if that is the correct way to do it on Ubuntu though
[20:08] <falktx> ailo: there's a "simpler" way for ubuntu:
[20:09] <falktx> update-rc.d rtirq defaults 50 10
[20:11] <falktx> reboot time, testing realtime kernel
[20:14] <falktx> realtime 31 kernel working fine
[20:15] <falktx> things seems a little slower though
[20:15] <falktx> the desktop at least...
[20:17] <ailo> falktx: Did you try jack yet?
[20:17] <falktx> ailo: will do that now
[20:17] <ailo> Are you using the rtirq?
[20:17] <falktx> ailo: yes, installed by default in kxstudio
[20:18] <falktx> my realtime test always involves wine
[20:18] <falktx> in generic, everytime I start a wine app, I got 1-3 xruns
[20:18] <falktx> haha, now I got 0!
[20:18] <ailo> I usually get xruns no matter kernel when starting some apps
[20:19] <falktx> oh, 1 when adding new vst
[20:19] <falktx> haha, I should the news on the forums
[20:19] <falktx> *should post
[20:20] <ailo> How about latency compared to -lowlatency?
[20:20] <ailo> or -preempt in your case
[20:20] <falktx> ailo: i did not test lowlatency yet
[20:20] <rlameiro> ailo
[20:20] <falktx> ailo: i have to do tests later
[20:20] <rlameiro> http://testcases.qa.ubuntu.com/UbuntuStudio
[20:20] <falktx> wow, Maverick rt31 also compiled!
[20:20] <rlameiro> will try to add some procedures to this testcases page
[20:21] <rlameiro> going to make some food and eat
[20:36] <ailo> rlameiro: I guess I could help fill in some spaces there. I could start with the latency testing script. 
[20:40] <falktx> hm, guys, cya
[20:41] <falktx> rlameiro: eu n devo ir la, tenho mais k fazer....
[20:41] <falktx> xau
[20:55] <rlameiro> ailo 
[20:55] <rlameiro> well, i dont know
[20:55] <rlameiro> maybe we should do the script first
[20:55] <rlameiro> maybe define a clear testing procedure
[20:56] <ailo> rlameiro: What should the goal be?
[20:56] <rlameiro> after that inplement it on a script
[20:56] <ailo> I don't think it matters if we start from both ends at the same time
[20:59] <ailo> I'm not a great scripter, but I thought I could at least start with making jack start and stop in different frames/period and then catch xruns and log them
[20:59] <ailo> As a barebone
[20:59] <ailo> For audio testing
[21:01] <ailo> I'm thinking about what form the results should have, what the script should accomplish
[21:03] <ailo> Many things I think needs to be done manually anyway, so maybe the script can be left simple.
[21:03] <ailo> rlameiro: What do you think?
[21:04] <rlameiro> I am with you :D
[21:04] <rlameiro> ailo: in python?
[21:05] <ailo> rlameiro: Bash is hard enough for me :)
[21:05] <rlameiro> ok, i dont know mch of bash
[21:06] <rlameiro> but we can try to pull it off
[21:06] <rlameiro> but before that we need to know what to test for
[21:06] <rlameiro> for instance
[21:07] <rlameiro> firewire normally runs on 3 periods
[21:07] <ailo> rlameiro: Why is that, anyway?
[21:08] <rlameiro> I think it is related with the firewire bus
[21:08] <rlameiro> also usb card should be run like that at low latencies
[21:09] <ailo> 3 periods per buffer should work as default for all devices, right?
[21:09] <rlameiro> at leas for FW ones
[21:09] <rlameiro> *leasr
[21:09] <rlameiro> grrr
[21:09] <rlameiro> "least
[21:10] <ailo> I don't think there is any problem with pci, so if it works best for firewire, I think we might as well keep it at 3, to make things easier
[21:10] <rlameiro> well, but it is quite diferent setup for pci
[21:10] <rlameiro> you can achive lower latencies
[21:10] <rlameiro> for instance
[21:11] <rlameiro> 2 buffers at 256 has lower latencie than 2 buffers at 256
[21:11] <ailo> Of course, but maybe we don't need to make a very strict latency testing
[21:12] <rlameiro> well yeah
[21:12] <rlameiro> we could try to do 2 diferent types of test
[21:12] <ailo> If we do, we should plug in outputs to inputs and measure the real latency, but that becomes more work.
[21:12] <rlameiro> one for extreme values and another Standard
[21:12] <ailo> There is a script for latency, latentor
[21:13] <rlameiro> it could be used
[21:14] <ailo> I'm looking for it now
[21:14] <ailo> Here's some info on jack latency testing http://wiki.linuxaudio.org/wiki/jack_latency_tests
[21:18] <ailo> The latentor script was on that page http://rg42.org/gitweb/?p=latentor.git;a=snapshot;sf=tgz
[21:18] <ailo> But it will only work if you connect inputs to outputs
[21:22] <ailo> rlameiro: I also asked about testing kernels a couple months back. Here's the discussion http://lalists.stanford.edu/lau/2010/12/0400.html
[21:23] <ailo> To do very specific tests, that may take some more work, but just to get a general idea, we can still keep it very simple
[21:25] <rlameiro> ailo... we could try to make a pd patch very, very, very cpu intensive with fft etc and run it without gui :D
[21:25] <rlameiro> that would surely stress the ystem
[21:25] <ailo> rlameiro: Good idea
[21:27] <ailo> I haven't tested yet the difference, but I feel pd is slightly harder to get to work without xruns than Ardour. Using pd at least gives us total control of CPU intensivity.
[21:27] <ailo> But that test would show the relationship between stress and xruns, instead of latency and xruns
[21:29] <rlameiro> well, you cant do only one test for that
[21:30] <ailo> Maybe do a series, where jack starts first, and then after a while pd is started. Xruns will follow from starting pd, but those can be ignored
[21:30] <ailo> As well as shutting down pd
[21:31] <rlameiro> yes, we need to give it some time to open and strat the patch
[21:32] <rlameiro> after some time you only need to stop pd and then jack
[21:32] <rlameiro> after that a new test
[21:32] <ailo> Yes, that would work
[21:34] <ailo> pd should track cpu to scale the intensity so it adapts to the system it is tested on
[21:36] <rlameiro> yes we can look at the load and if it goes avobe 98 shutdown a module and if it goes lower than 97 connect other
[21:38] <ailo> That takes care of the audio testing, but there's all the other things to worry about, which seem like it should be presented as a list of manual tasks to go through, one by one.
[21:39] <ailo> Like boolean problems, does it work, or not
[21:41] <ailo> But we can't have that for every piece of software. I think the tests should be directed at checking hardware
[21:41] <ailo> Graphic cards, cd drives, things like that.
[21:45] <rlameiro> yeap
[21:45] <rlameiro> i think ubuntu already has some kind of test on that
[21:45] <rlameiro> ont the system menu or something
[21:45] <ailo> Yes, so we only need to do things that are Studio specific
[21:45] <rlameiro> yeap
[21:46] <rlameiro> altough we can direct them for that test for other stuff
[21:46] <rlameiro> but this is also fo ease of testing inside of US dev
[21:46] <rlameiro> not for every user
[21:46] <rlameiro> for instance when there is a new kernel build we need to test it and see if it works or not
[21:47] <rlameiro> only after that it would be available at ubuntustudio ppa
[21:49] <ailo> Would you want to do the pd patch and I do the script that starts it?
[21:51] <rlameiro> i can try
[21:51] <ailo> I can help with pd if needed
[21:52] <rlameiro> I could ask to the list the best way to stress DSP :D
[21:52] <ailo> I'm sure pd list people can too
[21:52] <rlameiro> they like that stuff :D
[21:52] <rlameiro> crash computers and stuff
[21:52] <ailo> hehe
[21:52] <rlameiro> me too by the way
[22:05] <ailo> good night rlameiro. I will work on the script tomorrow and make a quick version.
[22:05] <rlameiro> ok. I dont know if i have a patch for tomorrow
[22:05] <rlameiro> i can try
[22:06] <ailo> no matter if the patch is empty. At least we have the backbone working :)
[22:52] <ScottL> of course, all the testing is relative and would be hard to pinpoint exact comparisons between various user/hardware data
[22:53] <ScottL> but hopefully we can divine vast trends though, e.g. -lowlatency generally is able to perform at approximately X msecs less that -generic without xruns
[22:54] <ScottL> and comparing my data (with pci audio interface) with holstein's data (with firewire) might not have any direct correlation either unfortunately
[23:28] <persia> ailo, If you create a latency testing tool, please have it sample at various system loads.  Frequently a setup that provides the lowest possible latency at low loads can scale poorly, so someone who runs more effects, or someone with lower-power hardware needs a different arrangement.