[00:05] <ailo_> Len-nb: Most of those settings I guess are only valuable for certain tasks
[00:05] <ailo_> There's one for midi (timer), one for multi track recording (disk)
[00:05] <ailo_> rtirq is good for solving the type of headache that you have, all though it does not seem to solve it for you
[00:06] <ailo_> We should put together a list of things to test
[00:06] <ailo_> Multitrack recording, live audio processing. I guess a bit workflow based
[00:07] <ailo_> Didn't do much today for the wiki today. Haven't had the time. 
[00:07] <ailo_> Another day tomorroq
[00:08] <ailo_> We could automate the test with a script
[00:08] <ailo_> Get some measurement data from what is measurable
[00:09] <ailo_> Anyway, gn
[13:11] <len-dt> ailo_, ondemand/performance (cpu throttling) gets reset to ondemand on my netbook. Maybe by powerd or something. I need to look more.
[13:13] <len-dt> network-manager starts some things that it does not stop. Rebooting with NM disabled is wonderful, stopping NM (and wireless BTW) is worse.
[13:16] <len-dt> Cron, anacron and atd can be stopped by changing runlevel. This is probably more important than we might guess as it is much more random, having apt update it self in the middle of a session could be a pain.
[13:18] <len-dt> Hydrogen uses very little resources compared to (other) sound generators
[13:23] <len-dt> I was able to run 5 synths at the same time (cpu60%) with no problem. (-p 128 as low as I can start Jack)
[13:23] <ailo_> Hudrogen mostly plays samples, but I'm sure you can make it use more cpu if you add some fx to it
[13:24] <ailo_> Hydrogen*
[13:24] <len-dt> The reason I could only run that many is because I ran out of memory and swap.
[13:25] <ailo_> len-dt: The cpu throttling gets reset during your login?
[13:25] <len-dt> I mean swap became a problem
[13:25] <len-dt> I am not sure when cpu throttling get s set
[13:26] <len-dt> Just that it did not seem to end up where I left it.
[13:26] <ailo_> Aught to be a default config for it to be set somewhere. I haven't dabbled much with it
[13:27] <ailo_> So, what other implicactions are there in changning runlevel?
[13:29] <len-dt> Run levels 2345 are all the same right now. So changing the config for cron like stuff just affects them.
[13:29] <len-dt> I used *.override files so the original files are untouched.
[13:30] <len-dt> That is installing a config change can be unistalled.
[13:31] <len-dt> Because of my memory limitations, the PA-jack bridge wasn't really a problem.
[13:34] <len-dt> ailo_, I think though that memory is cheap enough that upgrading to at least 2G ram could be a strongly suggested first improvement.
[13:35] <len-dt> I was using virt/keyboard to stress test, so a max of 4 notes polyphony was the best I could do.
[13:37] <len-dt> I will try tracking when I get the USB audio IF. Down the road... I am deciding if I should get a usb midi if or a USB KB. I have a lot of little midi KB around already though.
[13:38] <len-dt> ailo_, I'm off to work today... bye now.
[13:42] <ailo_> 2GB seems like a minimum for a typical linux based OS right now
[13:43] <ailo_> Perhaps not for everything audio related, but just for the usual programs, like firefox and chrome
[13:43] <ailo_> A P3 will often have a maximum 512MB limit, or maybe 1GB, so they are barely usable anymore
[13:44] <ailo_> Also, finding graphic cards for them that you can use to just browse the web is hardly worth the trouble
[13:46] <ailo_> netbooks may have less processing power then your usual PC, but the other components are up to date, and you can usually install at least 2GB RAM
[13:46] <ailo_> So, I agree. 2GB is a good lowest limit to recommend at this time
[13:47] <ailo_> For people who like to work with large sample libraries, you need at least 4GB, or more
[13:55] <len-dt> ailo_, what does memlock do?
[13:56] <len-dt> I guess what I am asking ... is there a way for an app to say don't swap this out?
[13:58] <len-dt> I wonder what the max memory a netbook can take is...
[14:02] <holstein> i have 2gb's in one of mine
[14:02] <holstein> the one that i use only for field recording has 1gb
[15:21] <ailo_> len-dt: Don't know exactly what memlock does. I just know you can use it to lock down memory for @audio applications. If you want anything other than unlimited, you need to specify it manually
[15:25] <ailo_> I think you specify with KB, not MB. Don't remember. The Ubuntustudio-controls application does this correctly, only it edits the wrong file
[15:26] <ailo_> I've just spent days programming something that more or less already existed right in front of me :(
[15:26] <ailo_> Sometimes, not always, it can be good to take the long way around
[18:42] <len-dt> holstein, 1 Gig for recording would be fine. I am trying to find out what the limits of the device are and found that with midi softsynths, memory ran out before cpu power.
[18:44] <len-dt> holstein, I'm just testing more as a documentation project than anything. I can at least recognize the difference between not enough memory and not enough cpu, some users can't.
[18:44] <len-dt> holstein, I think for my use, two tracks of recording will be about as much as I ever do.
[18:54] <len-dt> ailo_, according to what I can find on some of the mysql pages, memlock locks the memory used by a process in memory and prevents it from being swapped out.
[18:55] <len-dt> The downside of using memlock, is that on running out of memory, the kernel starts killing processes :-)
[18:57] <len-dt> ailo_, none the less, it would make sense to me that any audio software that is well made, would use memlock for at least the thread that does the audio work.
[18:57] <len-dt> ailo_, That being so, the swappiness value may have less effect than it would seem.
[18:58] <astraljava> Set it to 0?
[18:58] <len-dt> ailo_, also, the user should be aware of how close to swap they are when using their machine for realtime uses anyway... or at least that there is such a problem.
[19:00] <len-dt> ailo_, we, through the jack install, set memlock to unlimited for audio devices/applications that know how to use it, but each application sets what it wants as well.
[19:31] <ailo_> len-dt: Then I the issue must be that without /etc/security/limits.d/audio.conf the user cannot  start a process which will use memlock
[19:31] <ailo_> The same as with rtprio
[19:32] <ailo_> I've been asking around for another way to grant those privileges to processes, but it seems pam is what many prefer
[19:33] <len-dt> astraljava, The standard swappiness is 60, suggested for audio is 10... that is start swapping when 10% memory is left. But well written audio apps should lock their memory anyway...
[19:33] <astraljava> len-dt: Yep.
[19:34] <ailo_> There are some people that prefer not using memlock unlimited, since that may cause a system freeze, when using up all resources
[19:34] <len-dt> ailo_, There is that too, but we set it. And the page a got the swappiness from setts it too.
[19:34] <ailo_> But to set it at any other level we need a startup script that measures memory, and sets something like 95% instead
[19:35] <ailo_> Or less
[19:35] <len-dt> ailo_, hyrdogen uses enough lock that it needs to be very close to unlimmited on "my" !Gig machine.
[19:36] <len-dt> ailo_, it seems a sliding scale would work... 95% for a 1Gig machine, 75% for a 2Gig and 50% for higher.
[19:36] <ailo_> In that case, maybe 95% would cover all of them
[19:37] <ailo_> Since 5% is quite a big chunk on larger memory sizes
[19:38] <len-dt> ailo_, Ok, I just thought that the sizes we would likely see are 1, 2 and 4G so 950m, 1.5G and 2G for anything else would work...
[19:39] <ailo_> People who use big sample libraries will use more than 2GB easily
[19:39] <ailo_> Don't know about video processing
[19:39] <len-dt> ailo_, point.
[19:40] <ailo_> I wold think unlimited is just fine, unless it didn't cause any danger, as it seems to do
[19:41] <ailo_> las thinks unlimited is preferred, and ardour will object if you don't have that (or something close to it)
[19:41] <ailo_> But they may have changed that
[19:41] <len-dt> ailo_, I have pushed it as hard as I could, but I think some of my audio apps do not use memlock.
[19:42] <len-dt> an application does not look for unlimited, but a certain amount I think. Still, it may look at what there is and ask for all of it.
[19:43] <ailo_> ardour pops up a warning message, or used to at least. Haven't tested for a while
[19:43] <ailo_> So, it's a lookup think during ardour startup, to tell the user what settings it prefers
[19:47] <len-dt> ailo_, something like that should be settable. but it seems that while an app may say it needs x amount of memlock, it doesn't take it till it needs it. So hydrogen asks for 900M or so, but runs with a lot less and is ok with other apps using/locking what it is not using.
[19:49] <len-dt> Looking at some of the cpu shield stuff for multi-core machines was quite interesting and could be of use to audio stuff.
[19:50] <len-dt> basically, they move all the system procs to one cpu and use the other cpu(s) for one user's processes with RT.
[19:51] <len-dt> ailo_, that way there is always one cpu running system stuff that can control things like shutdowns and kills.
[19:53] <len-dt> ailo_, anyway, all those little changes did seem to help with the stability of all my softsynths running at the same time.
[19:54] <len-dt> However, I think they should be mostly "if you need them" kinds of things not default.
[19:58] <ailo_> len-dt: Interesting. I was trying to find out how to set memlock. Not on Ubuntu now. If you'd like to see quickly, install ubuntustudio-controls. Use it to set your memlock to something small, like 50% or less. The change will appear in /etc/security/limits.conf. Take the values form that file, delete the @audio entries and add the memlock amount to /etc/security/limits.d/audio.conf instead
[19:59] <ailo_> If you like, you can quickly edit the python file for that program, so it will edit the right file
[20:00] <ailo_> len-dt: It's a line in the pythonfile called ubuntustudio-controls. I don't remember where it ends up, but the file is this:
[20:00] <ailo_>  memlock = ChangeSettings("/etc/security/limits.conf", "@audio\s-\smemlock (\d*)", "")
[20:00] <ailo_> The line, I mean
[20:00] <ailo_> Er...
[20:00] <len-dt> ailo_, search of the file name in other words..
[20:03] <ailo_> It's either /usr/share/ubuntustudio/ubuntustudio or a python folder
[20:04] <ailo_> I guess for just tweaking memlock, it might be useful to use that app for now
[20:05] <ailo_> I did a whole new ubuntustudio-controls a bit over a year ago, but it was a bit hacky, even if it worked. So, I had a chance to do some python coding with gtk
[20:07] <ailo_> len-dt: Anyway, if you just replace the "/etc/security/limits.conf" with "/etc/security/limits.d/audio.conf" you'll be happier using ubuntustudio-controls for tweaking memory
[20:07] <ailo_> The other controls you don't need to touch
[20:07] <len-dt> ailo_, For me... manual is almost easier ;-)  I think we want it do some more things before it gets used in release though.
[20:07] <ailo_> ubuntustudio-controls is in the repo
[20:07] <ailo_> At least the last time I checked
[20:08] <len-dt> I know, but not this release... I think.
[20:08] <ailo_> I saw it the last time I looked
[20:08] <len-dt> Yup, still there.
[20:09] <ailo_> So use it. At least it's good for something :)
[20:10] <len-dt> Ok, so why am I changing memlock from unlimited again?  :-)
[20:10] <ailo_> len-dt: You could see what happens when you start ardour for example.
[20:11] <len-dt> Ja, yust yolking..
[20:11] <ailo_> Also, it will let you know the right way to edit memlock
[20:13] <len-dt> what does "enable raw1394 access do? Or is that now in group audio?
[20:13] <ailo_> len-dt: It's the old way to enable firewire
[20:13] <len-dt> ailo_, I don't have firewire stuff anyway
[20:13] <ailo_> Was still needed for 10.04
[20:13] <ailo_> The old firewire stack
[20:14] <len-dt> OK, and nice doesn't really do anything seeing as our audio apps aren't nice anyway ;-)
[20:14] <ailo_> Since then, there's a udev rules file that identifies all known devices and gives them access through @audio group. ffado is talking about adding that to their source now
[20:15] <ailo_> Yeah, I don't know if nice was ever needed. Hasn't been used for a while
[20:15] <len-dt> ailo_, is ffado stuff being added to alsa as well?
[20:15] <ailo_> len-dt: That's what I've heard.
[20:18] <len-dt> ailo_, what direction is US going? Or is tha on hold till after web page release?
[20:18] <ailo_> len-dt: What do you mean with direction?
[20:19] <len-dt> What are we trying to accomplish this cycle. I sort of have some ideas... but there seems to be no real roadmap.
[20:20] <ailo_> For my own sake, I'm in this mostly to make sure Ubuntu and all its derivatives are more easily made audio capable. To me, that is a responsibility US has, since it's in the main repo. I recognize that US is it's own distro, with it's own goals, but for me, I have already enough to think about with the former to be able to contribute to both for a long time
[20:21] <ailo_> len-dt: I'm sure ScottL will start making one shortly.
[20:21] <ailo_> A roadmap, I mean. He was asking for ideas a few weeks ago
[20:21] <len-dt> ailo_, Ok. That would explain why you are most vocal just now :-)
[20:21] <ailo_> Like you, I'm getting some ideas recentlyu
[20:22] <len-dt> Ja he was and writing things down in a list... but I guess we are waiting for it to be somewhere I can see it.
[20:22] <ailo_> I think ScottL is just occupied with the Ubuntu get together right now
[20:22] <len-dt> And the web page... which to be fair all of us want to see ASAP.
[20:24] <len-dt> I should probably sit and fix up the menu some more. So that when audio/video/graphic/photo apps we don't ship get added the menu listing ends up in the right place.
[20:26] <len-dt> ailo_, I am thinking we may want an audio utilities submenu as well. Depends what everyone else thinks though. I will just fix what we have now for now.
[20:26] <ailo_> len-dt: btw, I just read something where the maintainer who takes care of ardour, and a bunch of other packages claims that Ubuntu does some subtle changes to those
[20:27] <len-dt> ailo_, That is why I think we should make it as easy as possible to run both versions
[20:28] <ailo_> I meant the maintainer of the Debian packages
[20:28] <ailo_> So, they are not unchanged, according to him
[20:28] <len-dt> What kind of changes?
[20:29] <len-dt> I expect to make it use whatever libs we have. So we don't have to run two...
[20:31] <ailo_> len-dt: I was thinking about just doing a simple diff between packages to see what sort of differences there are
[20:31] <ailo_> Downloading now
[20:32] <len-dt> The ardour realease is static. Our libs change almost with the weather, but are (hopefully) more secure
[20:43] <len-dt> ailo_, ubuntustudio-controls does not work well with our stock audio.conf file: 
[20:43] <len-dt> len@music:/etc/security/limits.d$ cat audio.conf 
[20:43] <len-dt> # Provided by the jackd package.
[20:43] <len-dt> #
[20:43] <len-dt> # Changes to this file will be preserved.
[20:43] <len-dt> #
[20:43] <len-dt> # If you want to enable/disable realtime permissions, run
[20:43] <len-dt> #
[20:43] <len-dt> #    dpkg-reconfigure -p high jackd
[20:43] <len-dt> @audio   -  rtprio     95
[20:43] <len-dt> @audio   -  memlock    unlimited
[20:43] <len-dt> @audio - memlock 975007
[20:43] <len-dt> #@audio   -  nice      -19
[20:45] <len-dt> ailo_, you can see that it does not remove the old (sorry original) value.
[20:45] <ailo_> len-dt: I guess cause it's not identical with the spacing
[20:46] <len-dt> ailo_, is there a difference between 100% and unlimited as far as apps are concerned?
[20:46] <ailo_> len-dt: Just remove the unlimited line all together, and it should work
[20:46] <ailo_> len-dt: I don't think so, except that ardour let's the user know that it would prefer something else
[20:46] <ailo_> If it still does that
[20:47] <len-dt> ailo_, I will test...
[20:47] <ailo_> len-dt: I just looked at the ubuntu version of ardour-i686. It does say that the maintainers are from Ubuntu
[20:48] <ailo_> len-dt: I suppose you'll need to log out and log in again for changes to take effect too
[20:48] <len-dt> Ja, but one of the better places to get help is at ardour.
[20:48] <ailo_> orignal maintainers are Debian. There were quite a few diffs
[20:48] <ailo_> len-dt: I'm not arguing that. I'm just trying to find out what the deal is with the Ubuntu version
[20:50] <ailo_> If one would decide that ardour in Debian or Ubuntu repo is not up to par, I'd rather fix the one we have than ask users to download manually
[20:50] <ailo_> Another option would be not to include it all, which would be strange
[20:51] <len-dt> ailo_, my personal feeling is that US should ship what is on our repo, but freely encourage people to use ardours if they want to.... and please tell us if there is something that work in the ardour one that doesn't in ours.
[20:52] <ailo_> Yeah. But what about the desktop file btw? Doesn't it work as it is?
[20:52] <len-dt> Ours should be the same from any use point of view. But use less memory.
[20:53] <len-dt> I am not sure, it works with ardour3b3, I don't know about ardour2rel though.
[20:54] <len-dt> ailo_, I will have to download it and see.
[20:56] <len-dt> I made a copy of our ardour.desktop just in case.
[21:03] <len-dt> The real reason there is no support for ubuntu/debian users is that they don't have to navigate through tons of beg screens. Even downloading from the ardour site they say there is no support for linux users who pay $0 dollars.
[21:07] <len-dt> ailo_, Oh, and by the way, the "free" version "The free version of Ardour 2.8.12 for OS X Intel does not support saving AudioUnit plugin settings, or using presets for AudioUnit plugins. If you prefer a version without this limitation, please return to the previous page and choose to make a financial contribution to the project."
[21:08] <ailo_> len-dt: Though you can always build it yourself of course. 
[21:08] <len-dt> Ah, wrong download
[21:10] <len-dt> That was the OS X version. I was wondering what a dmg file was... 
[21:10] <len-dt> ailo_, The linux version is complete.
[21:12] <len-dt> I could build it... but I would still have no support. They only want to talk to people who have downloaded their static build and paid something.
[21:14] <astraljava> Non-free support is one thing, and totally acceptable. But ridding features from free releases... meh.
[21:15] <len-dt> Ja, I notice _not_ from the linux releases, but from the OS x releases.
[21:15] <len-dt> I guess MAC owners are used to it...
[21:16] <len-dt> And $5 is a lot less than what they normally pay for anything.
[21:16] <astraljava> Perhaps. I do not intend to pay for any, though.
[21:17] <astraljava> I'd rather fight with the compiling etc.
[21:17] <knome> hey astraljava :)
[21:17] <astraljava> o/
[21:17] <len-dt> As long we are willing to give freely of our own stuff, why would I pay?
[21:19] <astraljava> Exactly.
[21:19] <len-dt> ailo_, I don't know where they put their *.desktop files... still it doesn't seem to interfere with ours.
[21:19] <ailo_> len-dt: I'd be more concerned with the /bin file, but maybe that doesn't conflict either
[21:20] <ailo_> I've forgotten what their version of ardour2 is like
[21:20] <ailo_> /usr/bin/*, I mean, if it has one
[21:20] <len-dt> bin file is in /opt/ardourwhatever/bin
[21:20] <ailo_> ok
[21:21] <ailo_> las offers quite a lot of support, and I would think a lot of it is free too
[21:22] <len-dt> So US should be saying we will help as we can, but if you need more help you will need to pay for it at ardour and install that version. It should work just like ours... please let us know otherwise.
[21:22] <len-dt> Actually pay for it can be $1
[21:22] <ailo_> There's other means of support too, like the floss manual
[21:23] <ailo_> http://www.flossmanuals.net/ardour/
[21:23] <len-dt> I would have to send a cheque... no pay pal no way...
[21:23] <ailo_> It would be good to look around for more of such manuals and save their links
[21:23] <ailo_> There's a lot of docs out there, but a lot of users don't know about it
[21:24] <len-dt> Anyway. I'm out for a bit.
[21:24] <len-dt> Its pick kids up time.
[21:24] <ailo_> Why not dollar bills, lol
[21:45] <len-dt> ailo_, we don't have any dollar bills any more... or deuces either..., but yes I get the point.
[21:45] <knome> "just my two cents for the development"
[21:46] <len-dt> GA
[21:47] <knome> i wonder which expression you was referring to? http://www.urbandictionary.com/define.php?term=ga
[21:47] <knome> ;)
[21:47] <len-dt> Go Ahead...
[21:47] <knome> heh no, that was just a pun
[21:48] <knome> i mean, supporting ardour with "two cents" for the development
[21:48] <knome> as in literal $.02 ;)
[21:48] <ailo_> I never knew there was an opposite to BA
[21:49] <knome> yeah. AB.
[21:49] <len-dt> I think the stamp is $.80 or so...
[21:49] <knome> what if you pay via paypal?
[21:49] <knome> they'd actually lose money if you sent less than like $2
[21:51] <len-dt> I prefer to ignore them... also for them to have none of my personal info.
[21:51] <len-dt> I'd like to be rich enough for a credit rating of zero too, but life is the way it is.
[21:52] <knome> mmh
[23:11] <len-dt> It is somewhat difficult to find much information on cpu throttling... a cpu throttle meter would be nice...
[23:18] <len-dt> It doesn't appear that this machine scales.
[23:19] <len-dt> It is older after all.