[01:16] <micahg> falktx: I'm not understanding the issue, why won't dssi-vst work?
[01:17] <falktx> micahg: because it's only available as 32bit
[01:17] <falktx> 32bit plugins don't work on 64bit hosts
[01:19] <micahg> if that's true, the solution for 12.04 was done wrong, the 32 bit app running on the 64 bit host can use the plugins though
[01:19]  * micahg is missing info
[01:20] <falktx> a 32bit app running on a 64bit _system_ can load 32bit plugins
[01:22] <micahg> falktx: where do these other plugins come from?
[01:22] <falktx> others?
[01:22] <len-dt> micahg, The iso failed to build because the plugins were not available to the 64bit ISO.
[01:23] <len-dt> or were not in the 64bit repo.
[01:23]  * micahg is very confused ATM
[01:23] <falktx> dssi-vst doesnt build on 64bit anymore, so it's only available as 32bit now
[01:23] <falktx> if a package depends on it, it will fail to install
[01:23] <micahg> right, with multiarch enabled, people thought this would be fine
[01:23] <micahg> no
[01:24] <falktx> not at all
[01:24] <micahg> apt-get install dssi-vst on a 64 bit system works fine
[01:24] <falktx> does 'sudo apt-get install qtractor:i386' works too?
[01:25] <micahg> nope
[01:25] <falktx> :(
[01:25] <micahg> librubberband2 isn't multiarch enabled
[01:25] <falktx> well, I wanted to fork dssi-vst anyway...
[01:26] <micahg> we'd probably take an SRU for that
[01:26] <falktx> maybe later I'll give this a fix on a new fork-code
[01:26] <micahg> falktx: please don't we can fix most issues :)
[01:26] <falktx> micahg: there is some missing funcionality I want to add there, but I know the author will not be 100% happy with it
[01:26] <micahg> oh, hrm
[01:27] <falktx> project is almost dead now anyway
[01:27] <micahg> maybe work with the upstream author to a decent compromise?
[01:27] <falktx> I'll see it in a few weeks
[01:28] <micahg> ok
[01:28] <micahg> as for the qtractor multiarch install, rubberband needs to be multiarched in Debian first
[01:29] <micahg> as does libfftw3-3
[01:29] <falktx> btw, I found out that most debian packages come with debug enabled
[01:29] <falktx> that is just awful
[01:30] <micahg> yes, but the symbols are stripped and stored in a separate package
[01:30] <falktx> lol, like it matters much
[01:30] <falktx> it shrinks in size a bit, but slowness will be there
[01:31] <falktx> qtractor is *imensily* affected by this
[01:31] <falktx> it just prints debug messages all the time...
[01:32] <micahg> that's a bug I think :)
[01:32] <falktx> no
[01:32] <falktx> if an app is configured to run in debug mode, then it will do debug-related stuff
[01:33] <micahg> right, we don't want debug mode in the build, just the debugging symbols
[01:33] <falktx> hm, why do we even want that?
[01:33] <falktx> it compromises speed
[01:33] <falktx> (and cpu)
[01:33] <micahg> well, in Ubuntu it's helpful to be able to retrace stufff
[01:34]  * micahg doesn't know all the background on it
[01:34] <falktx> I don't really think it's any good. users will complain about random xruns
[01:34] <falktx> if an app prints stuff during process callbacks, of course it will cause xruns
[01:35]  * falktx is losing hope in debian
[02:43] <len-dt> micahg, on thinking a bit, it seems to me the loss of the dssi-vst happened at the time of our change from alt to live DVD. We could include the package in the alt, but the live would not build with it. We were more interested in getting the live DVD working than trying to fix what was wrong with dssi-vst
[02:46] <len-dt> getting look and feel right after 11.10 (looked like xfce with some audio apps thrown at it) seemed more important.
[02:46] <micahg> right, you could only include it on the i386 image
[02:46] <len-dt> Ya
[02:47] <len-dt> We have never relooked at the problem since
[02:47] <len-dt> So, if we go to where we wanted, with a more minimal install and add workflows later it would probably work again.
[02:51] <len-dt> micahg, not having Scott around to bounce things off of has slowed us down a bit.
[02:51] <len-dt> That should change soon 
[07:27] <ailo_> len-dt: I can't seem to get PA to rise above 3.5 MB in memory use. Can you reproduce?
[07:27] <ailo_> Sorry, 3.2 MB
[13:25] <knome> hey scott-work :)
[13:25] <scott-work> hi knome, how are you today?
[13:25] <knome> fine!
[13:25] <knome> setting up the xubuntu community meetings
[13:26] <scott-work> i'm tired
[13:26] <knome> me too
[13:26] <knome> i took 14h "naps"
[13:26] <scott-work> my mother-in-law fell and broke her shoulder this weekend and we spent quite a bit of time at the hospital and her house over the past two days
[13:27] <knome> ouch
[13:27] <scott-work> yeah, it wasn't unexpected however
[13:27] <knome> yup, old people
[13:34] <scott-work> she's not _that_ old, however she has had chemo due to cancer, she's overweight, and not in shape (at all!)
[13:34] <knome> aha
[13:34] <scott-work> "fragile" comes to mind
[13:34] <knome> right, well that too
[13:35] <astraljava> Oh dear
[13:35] <knome> hope she gets well soon
[13:35] <astraljava> "No, no deer, they run too fast."
[13:35] <knome> astraljava, milove!
[13:46] <scott-work> thanks knome 
[13:46] <scott-work> hi astraljava 
[19:57] <len-dt> ailo, (to answer your question from before) PA normally takes about 6M of ram
[19:58] <len-dt> when jack runs (and the pa-jack bridge loads) that goes up to about 108M
[20:00] <len-dt> a2j uses 105M btw.
[20:13] <ailo> That's weird
[20:13] <ailo> I noticed qjackctl had been updated for Wheezy, so I expect it has been for Quantal as well
[20:14] <len-dt> I think it is something to do with the jacklibs
[20:14] <ailo> I also noticed the new config option "Stop JACK audio server on application exit"
[20:15] <ailo> So, I assume it just makes sure to kill jackdbus if active
[20:15] <ailo> Which is good
[20:15] <len-dt> jack-dssi-host uses 105M
[20:15] <ailo> With what?
[20:15] <len-dt> hexter inside uses only 12m
[20:16] <len-dt> They show up separately
[20:16] <ailo> Yeah
[20:16] <len-dt> It seems the lib that allows connecting to jack grabs a chunk of memory (the libs themselves are not that big)
[20:18] <falktx__> len-dt: you're confusing app-memory vs shared memory
[20:18] <len-dt> So even on a 2G system, pulsebridge and a2j together are already using 10% of the ram. That is ok if you are using them but not if you don't need them.
[20:18] <len-dt> could be.
[20:18] <falktx__> when an app uses a shared library (jack, gtk, qt, etc), it shares resources with such lib
[20:18] <falktx__> I bet any jack app will show up to use ~100Mb
[20:19] <len-dt> I'm looking at top I see a line like:  7951 len       20   0  131m 105m 104m S    3 10.5   0:06.59 jack-dssi-host   
[20:19] <len-dt> the 104 is shared.
[20:19] <len-dt> the 105 is "res"
[20:20] <len-dt> the res value matches the app use pretty good. 
[20:21] <len-dt> falktx__, so how do I read the output from top then to make the most sense?
[20:23] <ailo> len-dt: I don't know top very well, but I assume there's a way to add more categories somehow
[20:23] <ailo> I just use the system monitor
[20:24] <ailo> Only use top when I need to kill stuff basically
[20:24] <len-dt> res means "resident size"
[20:25] <len-dt> shared memory means "memory that could be potentially shared with other processes"
[20:26] <len-dt> the man page doesn't say if shared mem is included in resident size or not.
[20:28] <len-dt> I don't think so as virt includes "all code, data and shared libraries  plus  pages  that
[20:28] <len-dt>           have  been  swapped out and pages that have been mapped but not
[20:28] <len-dt>           used"
[20:30] <len-dt> On the other hand if vrt is 131m and res is 105M and shr is 104... that is confusing...
[20:31] <len-dt> ailo, do you mean like "task manager"?
[20:32] <ailo> len-dt: No. I use the gnome System Monitor
[20:32] <len-dt> task manager shows the same numbers.
[20:32] <len-dt> We don't ship that.
[20:33] <ailo> len-dt: Got curious, and found a way to display and sort commands according to % memory use
[20:33] <ailo> len-dt: ps -eo %mem,comm --sort %mem
[20:33] <ailo> The % memory is accurate, so it's not shared memory
[20:34] <len-dt> same numbers as before.
[20:34] <ailo> You're right
[20:34] <ailo> Damn :P
[20:35] <ailo> But the gnome System Monitor is showing the right values under "Memory" anyway
[20:36] <ailo> I would assume the XFCE task manager can be set to show more categories
[20:36] <len-dt> "right" meaning?
[20:36] <len-dt> BTW I am using the kxstudio jack and qjackctl.
[20:38] <len-dt> The task manager config says I am looking at "private bytes"
[20:39] <len-dt> That sounds "unshared"... but who knows I don't always know what I am talking about, so the writer of the app may be confused.
[20:40] <ailo> len-dt: The amount of memory that this app is using alone
[20:40] <ailo> I guess "right" is not the right term
[20:41] <len-dt> So the 100M all the jack apps are using is not shared?
[20:42] <ailo> Right now, Firefox is using 324,6MB of memory, 33.5MB shared memory
[20:43] <ailo> jackdbus 7.5 memory, 82.5 shared memory
[20:45] <len-dt> ailo, is your system 32bit or 64?
[20:45] <ailo> 64 bit
[20:46] <len-dt> would that be why yours is using less memory?
[20:46] <ailo> 64bit usually uses more memory
[20:46]  * len-dt has 32 bit systems
[20:46] <ailo> If you have 32 bit and need 2 GB, for 64bit you'll need 3GB
[20:47] <len-dt> for code, for storage of audio as well?
[20:47] <len-dt> I guess a gb is a gb even if you use two words for everything.
[20:48] <micahg> scott-work: BTW, any plans to release alpha1?
[20:49] <ailo> len-dt: Also, I'm on Wheezy, so there may be some differences. But, generally, it should not be that big of a difference
[20:49] <ailo> At least not what the audio apps are concerned
[20:50] <ailo> len-dt: I have no idea what format "memory" really is in System Manager. I can't seem to find the same format using ps
[20:50] <len-dt> ailo it is 10% to 15%, not that big. I will try on the stock US machine too.
[20:52] <ailo> As for Firefox memory, it of course depends on what you are using it for. Usually, it grows with time. I often get over 1GB of memory
[20:53] <ailo> Thunderbird uses up a lot too
[20:54] <len-dt> my FF is 559 virt, but only 99 resident size and 28mshared
[20:54] <micahg>  4231 micah     20   0 2447m 1.5g  40m R  100  6.2 602:17.86 firefox-trunk 
[20:54] <micahg> that's with ~700 tabs
[20:55] <micahg> Firefox 13+ will have lower memory usage in restored sessions
[21:00] <ailo> micahg: Doesn't it get really slow for you?
[21:00] <micahg> nope
[21:01] <ailo> I find that some pages make scrolling pages really slow
[21:01] <micahg> then again, I don't run on a "normal" machine
[21:02] <micahg> ailo: those would either be bugs or configuration issues
[21:02] <micahg> if it's reproducible, feel free to report a bug with ubuntu-bug firefox (you might want to try firefox-trunk first to see if it's been fixed already)
[21:02] <SergeLion> zramswap increases the effective amount of RAM roughly by 50%, it saved me back when Firefox 4 leaked gigabytes
[21:03] <ailo> micahg: Could be a driver bug
[21:03] <SergeLion> nowadays lastest stable Firefox uses twice less memory than Chromium for opening Gmail
[21:08] <ailo> I had an update today that fixed a problem I was having with flash (some videos were overly blue), and it does seem like behaviour has changed for firefox as well. I use auto-scrolling a lot, and usually the scrolling get's stuck periodically. And did so for other pages too, when I had heavy java or flash (one or both of them) loaded. Seems to be gone now. Only those pages are twitchy now
[21:09] <ailo> Only those pages are twitchy that are "heavy"
[21:14] <Len-nb> ailo, interesting, on my netbook the same apps are using 82-85M
[21:22] <ailo> Len-nb: I'm reading up on Linux memory management. Shared memory is things that are shared between multiple applications, such as bash. I don't know the extent of it. I guess it would be correct to say an application is using all of that memory, but if you close the application, much of that is still used by other applications, or perhaps by the OS itself
[21:23] <ailo> Also, virtual memory is not actual hardware memory
[21:23] <Len-nb> ailo, ya, I figured that much.
[21:24] <ailo> If you make a sum of all the virtual memory allocated, it's far larger than the RAM you have installed
[21:24] <Len-nb> virtual includes swapped mem
[21:24] <ailo> Or, could be far larger, but it's how it is for me right now anyway
[21:25] <ailo> Firefox does not seem to share a lot with the system
[21:25] <ailo> While jackdbus and other apps seem to share quite a lot
[21:25] <micahg> nope, firefox uses bundled libraries for most things
[21:27] <Len-nb> virt should be... swapped+res or swapped+private+shared?
[21:28] <Len-nb> nope. my swap is showing 0.
[21:30] <ailo> Len-nb: I'm reading this old page http://tldp.org/LDP/tlk/mm/memory.html
[21:40] <Len-nb> It appears that if stuff is read off the disk that is read only, it is not swapped out, but rather just over written and reloaded from the same file if needed again.
[21:40] <Len-nb> I wonder how swappiness affects that?
[21:41] <Len-nb> Anyway, I'm off...
[21:46] <ailo> len-dt: Virtual memory is simply specific to the application. Doesn't really matter if it's swapped or not
[21:50] <ailo> len-dt: Something I conclude from watching the different categories in System Monitor. Resident Memory is roughly the sum of shared memory + writable memory. Writable memory is roughly the size of "memory". 
[21:52] <ailo> It seems uncommon that any shared memory is writable by the application. 
[21:53] <ailo> Or perhaps doesn't happen at all. I don't know
[21:53] <ailo> The trick here is to know what the shared memory consists of. What libraries, etc
[21:58] <ailo> If I start jackd, and have no other audio applications running, total hardware memory usage increases by about 8 MB
[21:59] <ailo> Still, writable memory is about 30MB, and shared is about 82
[22:03] <ailo> The same from a new login. So..
[22:04] <ailo> At least I can conclude that starting jackd does not load very much into RAM
[22:08] <ailo> Starting Hexter will make the sum rise with about 4MB, which is what the two processes have as a sum in writable memory
[22:08] <ailo> So, jack + hexter (+ jack-dssi-host) makes the sum of my RAM usage grow with less than 20MB
[22:31] <ailo> len-dt: This seems like an ok wiki http://linux-mm.org/
[22:32] <astraljava> Hey scott-work, How ya doin'?</Joey>