[00:04] <ScottL> i'm burning the 64bit iso's now
[14:18] <ScottL> test and report and now i see new images this morning :P
[14:24] <astraljava> That's why I am only now about to send the message to the lists, it's usually like this; new re-spins are made for the first few days.
[14:56] <ScottL> astraljava, hehe, i misread your statement at first and had a completely different reply :P  but of course, you are completely correct :)
[14:56] <ScottL> astraljava, do you mean at all milestones?  or just for RC?
[14:58] <astraljava> It happens every time. :)
[15:10] <len> Second day in a row my desktop has been locked/hung/crashed when I woke up.
[15:15] <len> Monitor was still on so there was still Hsync on the video card.
[15:31] <len> Time to try another iso.
[15:31] <len> For those interesting in CPU cycles, I did some playing with pulse last night.
[15:32] <len> It seems to big pig on cpu cycles as far as pulse is concerned is the jacksink.
[15:34] <len> When I unload module-jackdbus-detect from pulse, pulse audio vanishes off the bottom of top's display.
[15:35] <len> cpu load drops by half (with jack and pulse at idle) or more.
[15:36]  * len is less happy with network manager
[15:42] <ScottL> len, sounds like a "record mode" sans pulse still might be a good thing
[15:44] <len> ScottL it looks trivial to do and restore.
[15:45] <len> I would leave pulse running... it makes respawn a non-issue, but unload the jack module as that locks pulse to jack's latency.
[15:45] <len>  Then just a pulse-audio --kill restores pulse to normal.
[15:48] <len> Basically the output of "pactl list short modules" has to be scanned to find the index of module-jackdbus-detect and then "pactl unload-module index" to go into record.
[15:48] <len> This can all be done in user space.
[15:51] <len> ScottL, at higher latency (p1024 for example) pulse cpu cycles are a non-issue. As latency goes down PA uses more cpu cycles till p128 where it uses about the same as jackd and at p64 it seems to use 125% or so what jack uses.
[15:54] <len> ScottL, to be honest, I am still just feeling my way through all this. Certainly for live work latency needs to be as low as the hardware will handle. I assume for recording it would be somewhat higher though.
[15:55] <len> Also, I am sure my hardware is not set optimally nor my system settings.
[16:06]  * len is thinking my system hang(s) may have been from leaving jackd running 
[16:07] <len> reboot
[17:42] <ailo> It's getting chaotic the way apps are being made dependant on either jackd1 or jackd2
[17:43] <ailo> Can't even start jackd1 with qjackctl as it seems
[17:55] <len-dt> ailo, even if an app is dependant on J1, all that means is it has to install jack1. Jack2 or jackdbus is still there and a jack1 app should still work with jackd 2 as the calls are the same... at least that is what the jackd web page seems to be saying.
[18:08] <ailo> len-dt: Nope. jackd1 conflicts with jackd2
[18:08] <ailo> This is not a jack1/jack2 problem though. It's a packaging problem
[18:08] <ailo> It seems people are moving towards using jack2 as default, but some things still depend on jack1
[18:09] <ailo> It is true that starting jack1 is done the same way as starting jack2
[18:09] <ailo> Except for the dbus thing
[18:09] <ailo> Which is jack2 only
[18:10] <len-dt> ailo, would having a replaces in jack2 work?
[18:11] <ailo> replaces?
[18:11] <len-dt> we need dbus for PA-jack bridging
[18:11] <len-dt> It seems to me a package can be set up to say it replaces something else.
[18:11] <ailo> As things are now, everything is set up for jack2, so the whole audio part of the system more or less gets broken without jack2
[18:12] <ailo> I was installing a package which depended on jack1, which it isn't supposed to be doing
[18:12] <ailo> Not in official repo though
[18:12] <len-dt> jack3 should be fun
[18:12] <ailo> But, there are some packages in the official repo that depend on jack1 dev libs
[18:13] <len-dt> Those ones should be bugged. 
[18:13] <ailo> And to install those, you also need to install jack1 and remove jack2
[18:14] <len-dt> removing jack2 would also uninstall everything that depends on it, no?
[18:15] <ailo> It happened to me before, but not this time
[18:15] <ailo> But I got tons of warning messages
[18:16] <ailo> It's not pretty
[18:16] <len-dt> It seems to me depends can be "a or b", so all jack depends should be "jack1 or jack2"
[18:17] <len-dt> I have heard there are some systems where jack1 is still more stable.
[18:18] <ailo> It depends on the client
[18:18] <ailo> puredata did not work well with jack2 before
[18:19] <ailo> Could be jack2 has more problems starting and stopping too
[18:19] <len-dt> Thats one app I have only tested enough to see it loads/runs but not done anything with it.
[18:19] <ailo> There doesn't seem to be any problems now
[18:20] <ailo> I haven't tested puredata as much though. I use pd-extended, which is yet not in the official repo
[18:20] <len-dt> Jack 2 starts and stops ok, but the communication through dbus sometimes times out.
[18:20] <len-dt> So the sender of the start/stop request doesn't know that things worked ok.
[18:22] <len-dt> This happens with both qjackctl and jack_control
[18:22] <ailo> len-dt: Here's the bug I reported on that behaviour. Seems like David H has been working on fixing it https://bugs.launchpad.net/ubuntu/+source/jackd2/+bug/956438
[18:23] <ailo> I was thinking about earlier behaviour though, when it came to jack2 being less reliable
[18:23] <ailo> Doesn't seem like those problems exist anymore
[18:23] <ailo> As of Precise
[18:24] <ScottL> ailo, did you see that david h. has posted on this and on the jack-dev mailing list
[18:25] <ailo> ScottL: Yes. Seems like he's working on it
[18:28] <len-dt> Good. ScottL, ailo, I have read that seq midi in jack is static. That is it only bridges midi ports that are available when jackd starts. Any syth started after jack doesn't get bridged. Is this true?
[18:31] <len-dt> Nope, I just tested it. Starting vert/key and hexter show up bridged
[18:32] <len-dt> Can't tell what they are though as they are not named anything useful.
[18:40] <ailo> I have some gig files I'd like to use with a sampler, so I tried installing linux-sampler as a deb. Compiling now
[18:40] <ailo> It needs jack1 dev libs
[18:45] <ailo> One good thing about OSS was that with puredata you could use multiple sound devices of different sorts at the same time
[18:45] <ailo> There was syncing errors of course
[18:45] <ailo> Easily solved with spdif syncing on cards that support it
[18:48] <len-dt> ailo, specimen doesn't work for you?
[18:48]  * len-dt hasn't done sampling.
[18:50] <ailo> len-dt: Haven't tried it, but does it load gig files?
[18:52] <len-dt> I don't know. .. I don't know what a gig file is TBH. I am assuming it has a sample and whatever info needed to make that sample work (loop points, adrs, etc)
[18:53] <ailo> Yeah, except a gig file can be a few gigabytes large
[18:53] <len-dt> ailo, makes sense if the patch has more than one sample.
[18:53] <ailo> linux-sampler is the only good tool for gig files that I know of
[18:54] <len-dt> is there a problem with adding it to 12.10?
[18:54] <ailo> license issues
[18:54] <len-dt> I thought I remembered something like that.
[18:55] <ailo> It's GPL, with an added extra restriction to make it impossible to add it to hardware, like hardware samplers and such
[18:55] <len-dt> specimen seems to be pretty simple.. looks like single sample stuff.
[18:56] <ailo> It has a frontend called qsampler, and all of it's dependencies do exist in the main repo, so you only need to build linux-sampler, which is a server
[18:57] <len-dt> ailo, if I add that to my computer and use it for performance my computer becomes a hardware sampler...
[18:57] <ailo> Yeah, but you know, like when you sell it to someone
[18:58] <ailo> The restriction makes it non-free so none of the major distros are able to have it in their repos
[18:59] <ailo> You'll find it in some of the lesser audio orientated distros
[18:59] <ailo> Like KXStudio
[19:00] <ailo> Damn, it doesn't compile
[19:02] <len-dt> ailo, so it can't be included free on a cd/dvd if that cd/dvd is charged for even if the charge is just for copying.
[19:03] <ailo> len-dt: I haven't read the license, just read about it
[19:03] <ailo> len-dt: "LinuxSampler is licensed under the GNU GPL with the exception that USAGE of the source code, libraries and applications FOR COMMERCIAL HARDWARE OR SOFTWARE PRODUCTS IS NOT ALLOWED without prior written permission by the LinuxSampler authors. If you have questions on the subject, that are not yet covered by the FAQ, please contact us. "
[19:04] <len-dt> I can see why it isn't in ubuntu
[19:05] <ailo> It's been around for a long time
[19:11] <len-dt> ailo, the problem with that kind of lic. is that once you put it on any new versions (derivatives) have to have the the same lic. so the author can't change it.
[19:12] <len-dt> though I guess they could give themselves written permission.
[19:13] <ailo> Ok, got it. The svn was not the same as the tarball they keep for download
[19:13] <ailo> I don't know much about svn, but it must have been a dev version I tried compiling just now
[19:16] <len-dt> ailo ... another topic, it looks like ubuntu loads any kernel modules that may be needed. My netbook has modules for par port  and serial ports which it doesn't have. The desktop has those turned of in bios and they are still loaded too. Yet many other modules only get loaded if needed.
[19:17] <len-dt> s/of/off/
[19:17] <ailo> Never looked into that, but whenever something should be plug/play at least then you'd like to have that
[19:18] <ailo> Would be interesting to see if it has any performance diffs at all
[19:19] <len-dt> Only on low mem machines, which seems to be anything under 2G any more.
[19:19]  * astraljava installs CentOS.
[19:22] <len-dt> astraljava... on the CentOS page what do they mean by x86_64? does that mean an AMD64 would not work?
[19:23] <astraljava> Nah, that's the same, I believe. Just different terminology.
[19:24] <len-dt> thks, I'll remember.
[19:25] <len-dt> RH based then?
[19:26] <ailo> It should be a clone of RH more or less, no?
[19:26] <astraljava> Yeah. This is purely work-related, not interested otherwise at all. :)
[19:26] <ailo> I was using it for a while a couple of years ago
[19:27] <ailo> If comparing that to Fedora, it does feel like comparing Debian to Ubuntu a bit. Even though Fedora isn't as polished as Ubuntu
[19:27] <len-dt> Their repos are on a RH system, but they try really hard never to say red hat.
[19:27] <astraljava> Well there's a distinct difference there.
[19:28] <astraljava> Fedora is sort of a test bed for Red Hat in some features.
[19:29] <ailo> It is
[19:29] <ailo> And Ubuntu is a company
[19:29] <astraljava> No.
[19:29] <astraljava> Canonical is the company.
[19:30] <astraljava> Ubuntu is the OS.
[19:30] <ailo> You know what I mean
[19:30] <astraljava> Heheh. :)
[19:31] <astraljava> Yeah but it's very different here, Ubuntu relies heavily on Debian, which _isn't_ a company, as where Fedora needs Red Hat, which _is_ the company.
[19:31] <astraljava> Very different scenery.
[19:32] <ailo> I did say "a bit"
[19:32] <len-dt> I haven't really tried any of the RH stuff for a long time, back when I was using Slackware I tried it but found it less friendly.
[19:32] <ailo> And the bit is in the experience
[19:32] <astraljava> Yep, agreed.
[19:33] <astraljava> Somehow I've never felt comfortable with the RH-based distros.
[19:33] <astraljava> Can't really put my finger on it, but just don't like them that much.
[19:33] <ailo> I found yum to be slow
[19:34] <len-dt> I switched from SW to ubuntu mainly for audio because audioslack (I think it was) died.
[19:35] <ailo> qsampler crashes
[19:35] <len-dt> astraljava tyhe irc topic could be changed as we are no longer beta 2
[19:36] <len-dt> ailo any idea why?
[19:38] <ailo> It worked from the terminal
[19:38]  * len-dt changes to focus follows mouse
[19:38] <len-dt> So crash on start?
[19:39] <ailo> I don't think qsampler itself crashes, but in conjunction with starting linux-sampler
[19:39] <astraljava> I should write that mail to the lists now.
[19:40] <len-dt> astraljava respin seems to have settled down a bit.... could wait a day though
[19:43] <ailo> 3/4 starts crash
[19:43] <ailo> Aren't computers supposed to do the same thing the same way each time? :P
[19:44] <len-dt> ailo, I have had my soundcards switch back and forth too many times...
[19:44] <ailo> You mean the order you get during boot?
[19:45] <len-dt> Ja, I have to add a command to force it.
[19:45] <ailo> You can also start the card using the name instead of hw:n
[19:46] <len-dt> I found that if my ensoniq starts first the envy24 gets more xruns.
[19:46]  * len-dt thinks a usb midi port is in his future...
[20:00] <len-dt> What the? how come snd_ice1712 needs snd_mpu401_uart? My d66 has no midi ports.
[20:10] <ailo> len-dt: Have you tried it? jackd -d alsa -d hw:M66
[20:10] <ailo> I had forgotten how to do that
[20:11] <ailo> You can also add that to qjackctl: hw:M66
[20:12] <ailo> It works fine until you need to use two cards as one
[20:12] <ailo> Two cards with the same name
[20:12] <ailo> Even just booting them in order
[20:12] <ailo> Haven't put any more time into that, but I believe one would need a script that checks by pci slot
[20:13] <ailo> Not a problem for most people, but becomes a slight nuiscance when you need 8+ channels
[20:14]  * astraljava awaits for the complaining to commence...
[20:19] <len-dt> Using the right card is not a problem. I just found that if I load the ice1712 drivers first, I get less xruns... a lot less. I was aware I could use names, but I can also tell ens1370 to load last which seems to work better. I think I may try swapping slots too, to see what (if anything) that does. I only use the ens1712 for the midi port.
[20:23] <ailo> len-dt: Have you checked irq's?
[20:24] <ailo> For some reason making my cards boot in order does not work very well, at least not the last time I tried
[20:24] <ailo> Had tons of usb devices attached
[20:25] <ailo> Things like my synth module, xv-5050, which is midi only, gets recognized as an audio device
[20:25] <ailo> So, it appears in the list of audio devices
[20:25] <ailo> Well, a lot of usb midi devices do that
[20:25] <ailo> Maybe all of them in fact
[20:27] <ailo> Whenever the boot order did not work, some devices were not loaded at all instead
[20:28] <ailo> Have to look into that later on
[20:42] <len-dt> ailo, irqs is why I want to try dfferent slots, the ensoniq seems to be one higher which I think means it gets serviced first by default.
[20:42] <len-dt> USB changes everything.
[20:43] <len-dt> I don't have any though.
[21:33] <len-dt> ailo, I guess the parallel port stuff is needed. Jack gets upset when I remove it. Reboot
[22:26] <len-dt> ailo, astraljava do either of you know if a usb port uses it's irq if nothing is plugged in?