| micahg | len-dt: umm, it depends on how it's installed | 02:29 |
|---|---|---|
| Len-nb | micahg, I did a fresh precise install, then tried to remove -graphics and -video. | 02:48 |
| Len-nb | The two meta files were removed but none of the deps | 03:03 |
| micahg | yeah, on install it won't work as the depends are not marked as auto installed | 03:04 |
| Len-nb | Don't know what happened to our user then. | 03:05 |
| Len-nb | I do need to move a font out of fonts on to desktop though. | 03:05 |
| micahg | Len-nb: you could just add it to desktop if the fonts metapackage is useful by itself without desktop | 03:07 |
| Len-nb | micahg, OK, I will do that. | 03:08 |
| Len-nb | Still waiting for release on -settings. I don't know if it matters, but what I have done so far fixes some things in precise, What I have next is all quantal | 03:10 |
| micahg | ah, crud, right, that should get in for alpha3 | 03:10 |
| micahg | Len-nb: not so sure I like adding more stuff to /etc/skel | 03:14 |
| Len-nb | I am not worried about the -look package so much, thought I did want to test it on install. It works fine on an allready installed system | 03:14 |
| Len-nb | micahg, where would I put it? | 03:15 |
| micahg | TBH, it sounds like a maintenance burden...I'm not sure the best way to do that | 03:15 |
| micahg | Len-nb: mind if I revert that for alpha3? | 03:15 |
| Len-nb | OK | 03:15 |
| micahg | Len-nb: was Exec=Exec=exo-open a typo? | 03:16 |
| Len-nb | It was one of the blueprint things. | 03:16 |
| micahg | Len-nb: I'm referring to Exec being there twice | 03:17 |
| Len-nb | where is the exec thing? I'll look | 03:17 |
| micahg | Len-nb: commit 127 in -settings | 03:17 |
| micahg | otherwise, I think it's fine | 03:18 |
| Len-nb | Thats strange... it works that way too. | 03:21 |
| Len-nb | Ok I will change that. | 03:21 |
| micahg | also, why in -look did you add a ubuntu-text.plymouth.in file? | 03:21 |
| micahg | (commit 138) | 03:22 |
| Len-nb | I was copying the way they did the vanilla ubuntu theme | 03:22 |
| Len-nb | I don't know why they have it either | 03:22 |
| micahg | right, but you should only need the Ubuntu Studio one, not the Ubuntu one | 03:22 |
| Len-nb | OK micahg settings typo fixed. | 03:26 |
| micahg | Len-nb: I assume it should still work that way... | 03:27 |
| Len-nb | I'll remove the extra file in the other branch | 03:27 |
| micahg | wfm | 03:28 |
| micahg | ok, I'll revert the xchat thing then so I can get this uploaded and get to sleep | 03:28 |
| Len-nb | I'll check., ya it works | 03:31 |
| micahg | ok, test building and uploading, is there anything else that should be uploaded aside from a new -meta? | 03:34 |
| micahg | Len-nb: you also need a depends on exo-utils to use exo-open in the package | 03:36 |
| * micahg is adding | 03:37 | |
| micahg | Len-nb: ok, unless there's anything else, I'll upload -settings now | 03:43 |
| Len-nb | Thanks. settings is done and I have done the font in desktop too | 03:44 |
| micahg | Len-nb: did you make any changes after the Exec fix? | 03:44 |
| Len-nb | in settings no | 03:44 |
| micahg | ok, thanks, will upload then | 03:45 |
| Len-nb | Thankyou micahg I will test tomorrows ISO? | 03:46 |
| micahg | there should be one at some point (no more dailies until after alpha3) | 03:46 |
| Len-nb | I didn't know we were at alpha 3 | 03:47 |
| micahg | Len-nb: where is the theme shipped? | 03:48 |
| Len-nb | It has been very quiet in here | 03:48 |
| Len-nb | It is a depends in settings I think | 03:48 |
| Len-nb | murrin is the package | 03:48 |
| micahg | ah, so, murrine-themes needs a font? | 03:49 |
| micahg | is this a studio specific thing? | 03:49 |
| Len-nb | Nope it is not setting. You would have to ask Scott | 03:50 |
| micahg | ok, I'll include it like that for now, but you might want to consider moving it to -look if appropriate | 03:51 |
| Len-nb | gtk2-engines-murrine, murrine-themes is dep in the -look branch | 03:51 |
| Len-nb | Ya both deps should be in the same place. | 03:52 |
| micahg | hrm, that seems like a redundent dep to begin with unless -look uses something specific from gtk2-engines-murrine | 03:53 |
| Len-nb | There is a lot of that so people can install studio on top of vanilla of kubuntu or whatever. | 03:55 |
| Len-nb | I don't know if it is the best either | 03:55 |
| Len-nb | I don't want to make huge changes though | 03:55 |
| micahg | sure, but murrine-themes depends on gtk2-engines-murrine, so, unless you're relying on something specific in there, it's an implementation detail of murrine-themes | 03:55 |
| Len-nb | I didn't know that... bet Scott didn't either :) | 03:56 |
| micahg | -meta uploaded as well | 04:00 |
| Len-nb | Thanks, Is look going? | 04:00 |
| micahg | yeah, I think so | 04:00 |
| micahg | your image size might balloon a little :) | 04:01 |
| micahg | but you're on a DVD already, so you've got room | 04:01 |
| Len-nb | Ya, we know. | 04:01 |
| micahg | sorry, I haven't had time to follow most of the threads on the ML | 04:02 |
| Len-nb | Thats why I'm working on post install package deal | 04:02 |
| Len-nb | If we try to include everything it will be a 5 DVD set | 04:03 |
| Len-nb | No worrys about the ML. I can be verbose. | 04:05 |
| ailo | len-dt: Seems like most tweaks can be done during runtime | 09:45 |
| ailo | But, I'd like to find out if some perhaps should not be done during runtime, for whatever reason | 09:45 |
| ailo | But as a starting point, I'll try make each tweak configurable during runtime, using a gui | 09:46 |
| len-dt | ailo, ok | 13:03 |
| len-dt | That would be good for testing anyway. | 13:03 |
| len-dt | ailo, adding stuff to /etc/skel seems to be a problem. My tweak to get xchat to open #ubuntustudio is taken out. Not sure how else to do this. | 13:08 |
| len-dt | I guess we could add our own *.desktop file and put it on the command line. | 13:13 |
| ailo | len-dt: I think better fix whatever is not working with /etc/skel | 13:15 |
| len-dt | Skel works, it was a policy thing, hard to maintain? | 13:15 |
| len-dt | Read the irc log from last night... err this morning. | 13:16 |
| ailo | len-dt: Where do applications usually keep their default configs? | 13:17 |
| ailo | There is also /etc/default | 13:17 |
| ailo | Er, but that won't help, I think | 13:17 |
| ailo | len-dt: How does Ubuntu add the default config for Firefox? The bookmarks, etc? | 13:18 |
| ailo | Should be done the same way? | 13:18 |
| len-dt | I have been looking... can't find it. But there is a package they add I think. | 13:19 |
| len-dt | I should look at that. | 13:19 |
| len-dt | xul-ext-ubufox | 13:21 |
| len-dt | It does a loy more than set bookmarks though | 13:23 |
| len-dt | xchat puts an xpm in icons and a png in pixmaps... seems backwards :) | 13:25 |
| ailo | I really don't like bash scripting syntax :( | 13:39 |
| len-dt | It's something to get used to... | 13:49 |
| ailo | len-dt: I've made a script that implements the hardware timers tweak. As I'm looking at it, the only thing that seems to be interesting to tweak is really just the value. Would you agree? | 13:54 |
| ailo | Seems like that is a tweak that should be enabled by default, during install | 13:54 |
| ailo | And the value should be set to 3072, but make it possible for the user to change it between the ranges of 1024 and 8192 | 13:55 |
| len-dt | permissions too. But the permissions should be set all the time. | 13:57 |
| len-dt | I don't know if I would go so high as 8k though. That is higher than the midi standard it self. | 13:58 |
| len-dt | 3072 is an odd number, but it is about the midi port speed. | 13:59 |
| len-dt | I also suspect that the higher the number the more trouble it would be for a slower machine to keep up with. | 14:00 |
| len-dt | ailo, in the end, the hard part looks to be finding a way of testing. | 14:01 |
| len-dt | back in a minute | 14:08 |
| len-dt | Hmm, ailo, addingthe url on the commandline for xchat doesn't seem to work... | 14:13 |
| ailo | len-dt: I was just talking about gui implementation. It seems the general opinion is to have a range between 1024 and 8192 | 14:15 |
| ailo | And 3072 more or less as default | 14:16 |
| len-dt | Ya, I saw that. I want to test the nigh numbers with audio running | 14:16 |
| ailo | But, that we should find out by testing, as you said | 14:16 |
| len-dt | I am thinking that on some machines the midi will be fine but audio may suffer. | 14:17 |
| * len-dt is thinking there may be more xruns | 14:17 | |
| ailo | len-dt: I'm actually starting by making bash scripts of everything. Even for kernel building | 14:17 |
| ailo | Best way to do testing | 14:18 |
| len-dt | Speaking of kernel building, the one thing we don't have in there (aside from pre-empt) is tickless timers | 14:18 |
| ailo | That is why we should try different configs | 14:18 |
| ailo | I'd rather have uploaded kernels to PPA, but I can't bother putting time on finding out how | 14:19 |
| ailo | The scripts have functions that the gui would | 14:22 |
| ailo | So, if something is to be a variable, the scripts accepts argument(s) | 14:22 |
| ailo | Withouth arguments, the script just uses default values | 14:22 |
| len-dt | makes sense | 14:23 |
| ailo | These scripts are only for making the tweaks. Then, we need scripts for the actual testing too. One that collects all relevant info of the system, and creates a log of the test results | 14:24 |
| len-dt | You've done the easy part. | 14:25 |
| ailo | Question is, what do we do to test the system, exactly? | 14:25 |
| len-dt | Ya :) | 14:26 |
| len-dt | My thought is get the system to behave a bad as possible first. | 14:26 |
| len-dt | Then look for a way of measuring that badness | 14:27 |
| len-dt | Then we can see improvements that are finer than we can hear | 14:27 |
| ailo | counting xruns is a given parameter. | 14:30 |
| len-dt | Yes | 14:30 |
| ailo | The midi timing issue is a bit harder to automate | 14:30 |
| ailo | For that you need some way of measuring the timing diff | 14:31 |
| len-dt | Ya, It would be nice to be able to playback and record with the same app. | 14:32 |
| len-dt | qtracktor doesn't seem to do that well. | 14:32 |
| len-dt | I ended up using two instances, one to play and the other to record. | 14:33 |
| len-dt | I need to try the whole mess over again with my netbook though as that is where I heard problems. | 14:35 |
| len-dt | My desktop has been very solid, even with the USB midi port. | 14:36 |
| ailo | len-dt: This look promising https://github.com/koppi/alsa-midi-latency-test/ | 14:37 |
| ailo | But that's only for inside the OS, I would think | 14:38 |
| ailo | Nothing related to HW | 14:39 |
| ailo | len-dt: Actually, seems it will test whatever it is connected to | 14:41 |
| len-dt | It looks to be testing latency. Midi latency, so long as it is consistent, is not a problem | 14:42 |
| len-dt | It can be corrected. | 14:43 |
| len-dt | general timing errors can't | 14:43 |
| ailo | len-dt: You get the diff in the form of best and wors | 14:44 |
| ailo | So, it does test jitter as well | 14:44 |
| ailo | What you do is you loop connect the HW. midi out to midi in | 14:44 |
| ailo | I'm going to try my roland, using usb | 14:44 |
| len-dt | Ya, that was what I did. | 14:44 |
| len-dt | Some applications do not use the sessions idea of default browser. | 14:49 |
| len-dt | non-mixer is one of these. I have default browser set to chromium, but non-mixer opens its help in firefox. wonder what it does if FF isn;t installed? | 14:51 |
| ailo | len-dt: Maybe it's hardcoded? | 14:53 |
| * micahg isn't sure what non-mixer is, but you want to check that stuff is using xdg-open generally | 14:53 | |
| len-dt | non-mixer is part of the non-daw set of applications. Much like jack-mixer but with more stuff built in. | 14:57 |
| len-dt | I don't think it is in ubuntu repos ;-) maintainer is falkTX | 15:02 |
| * len-dt is working on special instances of software center that only show SW related to the menu they reside in. | 15:05 | |
| ailo | len-dt: Had to connect two different midi HW to get the loop going :). So, for you and me, we should be able to automate midi testing | 15:06 |
| len-dt | I have to use a MIDI through to connect output to input. | 15:07 |
| ailo | len-dt: I don't have a midi cable right now. At least both are usb, so it's easy to test on multiple machines | 15:08 |
| ailo | Couldn't get the roland to loop only using the usb connection | 15:09 |
| ailo | I also have a midisport 1x1 device | 15:09 |
| len-dt | My roland does looping to external devices but not to the USB port. | 15:09 |
| === kubotu_ is now known as kubotu | ||
| ailo | len-dt: I'm putting stuff here, while I'm sketching https://gitorious.org/ubuntustudio-testing/pages/Home | 15:14 |
| ailo | I'm just trying to get a full picture of what we are doing | 15:15 |
| ailo | What we should test | 15:15 |
| ailo | len-dt: Anything missing there? | 15:16 |
| len-dt | ailo, I would drop PCI latency. Using the sugested script made my machine unstable and more xruns as a result. Any newer system will have PCIe slots anyway. | 15:17 |
| ailo | One thing that I think we should not do, is disabling things that don't do any harm anyway | 15:17 |
| len-dt | blutooth? | 15:17 |
| ailo | len-dt: The idea is we do tests, gather results, and then figure out what to do | 15:18 |
| len-dt | swappiness? | 15:18 |
| ailo | It's there | 15:18 |
| ailo | Under Filesystem | 15:19 |
| len-dt | ok I see it now. My browser is set to a small font for that. | 15:19 |
| len-dt | Both of my machines gave problems with jackd when ulatency was used | 15:20 |
| len-dt | Jackd crashing | 15:21 |
| len-dt | I think that is because jack does some of the same things using different system tools or the stock ulatencyd setup conflicts. | 15:21 |
| ailo | len-dt: Perhaps rmlimits is preferred in that situation | 15:22 |
| ailo | Seems to be all about cgroups | 15:22 |
| ailo | rlimits, instead of PAM | 15:23 |
| len-dt | might be. | 15:23 |
| ailo | Using rlimits instead of PAM would be kind of a big change. | 15:24 |
| ailo | But interesting to see how that works | 15:24 |
| len-dt | The idea behind using ulatencyd in the first place was to set what apps should be forced to stay in ram and not get swapped out. This is turned off by default | 15:24 |
| len-dt | ailo, to test swappiness... run a sequence and pump it into enough sound modules to use more than 40% memory... now try to use qjackctl. | 15:27 |
| len-dt | I think I actually was using closer to 60% memory | 15:28 |
| ailo | len-dt: You mean fill up 60% of RAM with something, and then try using qjackctl? | 15:28 |
| ailo | Or does it have to be jack applications? | 15:28 |
| ailo | Why qjacktl, in particular? | 15:29 |
| len-dt | Probably has to be jack or at least those with memlock | 15:29 |
| ailo | Ok | 15:29 |
| len-dt | That was where I noticed the problem | 15:29 |
| len-dt | It was like qjackctl had froze | 15:30 |
| ailo | len-dt: You start qjackctl first. Then a bunch of apps. Then go back to qjackctl, right? | 15:30 |
| len-dt | Ya. | 15:30 |
| len-dt | It seemed to ok to get the connections made but then after running things for a while and going back to change routing, qjackctl was pretty much not usable for a bit. | 15:31 |
| ailo | len-dt: And this happened when swappiness was high? | 15:31 |
| len-dt | swappiness was at stock setting 60 | 15:32 |
| len-dt | This means when ram get 4o% the OS starts swaping things out | 15:32 |
| len-dt | Not hard swaps but if they have sat around for a bit. | 15:32 |
| len-dt | swappiness at 10 I can go for days with no swap at all, and if I use a lot of cache it may put some stuff there, but after that use it is stable again. | 15:34 |
| ailo | len-dt: And did you ever see a situation where it would be good to have more swap on Ubuntu Studio? | 15:34 |
| len-dt | I found no real difference from swappiness at 10 or at 0. | 15:34 |
| ailo | I mean, more swappiness | 15:34 |
| len-dt | even with swappiness at 0 the OS will swap stuff out if it has to | 15:35 |
| ailo | Has someone said anything about that, what graphics are concerned, etc | 15:35 |
| len-dt | 10 gives it a bit of time to start swapping things out before it has to just to run. | 15:35 |
| len-dt | I have had comments that swappiness at a low value is good for graphics as well. | 15:36 |
| len-dt | Also cpu frequency on full not ondemand. | 15:37 |
| len-dt | at least one other person has had problems with xruns at speed change with ondemand. | 15:37 |
| ailo | High swappiness is perhaps only suitable for servers? | 15:39 |
| ailo | I've never measured how the cpu freq changes | 15:40 |
| ailo | And how fast | 15:40 |
| len-dt | high swappiness is good for high disk use applications | 15:44 |
| len-dt | redhat now defaults to 40 | 15:44 |
| len-dt | even in their servers I think | 15:45 |
| len-dt | There is a cpu throttling for jack, but from reading about it... all it does is set speed full while jack is running. | 15:47 |
| ailo | len-dt: Where is the cpu throttling for jack, link? | 15:49 |
| len-dt | http://rg42.org/oss/jackfreqd/start | 15:50 |
| len-dt | I found the discussion at the bottom interesting. | 15:53 |
| len-dt | It seems the same thing can be achieved by using ondemand and switching to performance when jack starts | 15:54 |
| len-dt | Note this person also seems to have had xruns when the speed switches | 15:55 |
| len-dt | That would make three, that I have heard of... the person he was talking to makes 4 | 15:56 |
| len-dt | There has been a suggestion, that running at a lower speed but solid with no changes would be fine too. | 15:57 |
| len-dt | I think mine has 1/2, 4/6, 5/6 and full. Running at 5/6 may give less fan noise and heat but still run fine. | 15:58 |
| * len-dt thinks he could do a lot at half speed | 15:59 | |
| ailo | Well, that's enough for one day. We have two things we know we can test automated: 1. xruns 2. midi latency(jitter). | 16:17 |
| ailo | Need to see about memlock and freezing apps tomorrow then | 16:17 |
| len-dt | good. | 16:18 |
| len-dt | I am going to work on install icons today. | 16:18 |
| ailo | len-dt: I was just doing some testing with the alsa-midi-latency-test | 18:14 |
| ailo | I adjusted max_user_freq between ranges 64 and 3072 | 18:15 |
| ailo | No change | 18:15 |
| ailo | Don't know if this test app uses audio group | 18:16 |
| ailo | Don't know how that works, concerning the HW timers | 18:16 |
| ailo | Whatever I did, enabling, or disabling, had no effect | 18:17 |
| ailo | Latency was mostly 4ms, with only a few stray misses, between 7-9ms | 18:17 |
| ailo | But, then I tried with rtirq script | 18:18 |
| ailo | And then, nothing abobe 5 ms | 18:18 |
| ailo | Still, not really big jitter in either case, which is not my experience from before. So, I'll do some manual testing too, using ears and wave files | 18:20 |
| ailo | I guess perhaps jitter doesn't come through on this test after all. Remains to be seen | 18:21 |
| len-dt | ailo, That was what I found frustrating. I had heard timing all over the place, but when I tried to measure it... the problem vanished :P | 19:48 |
| ailo | len-dt: Did you reboot in between changes? | 19:49 |
| ailo | We really need to make sure to put down all possible data for automated tests to catch diffs | 19:49 |
| ailo | I mean, collect all possible data | 19:50 |
| len-dt | worse, two different machines :-) I have to do some retesting | 19:51 |
| ailo | len-dt: Actually, after redoing the test with the rtirq script running, I suddenly get the same result as without, pretty much | 19:53 |
| ailo | Anyway, I should just create a test, and collect data to the mail list | 19:54 |
| ailo | It'll speak for itself after all | 19:54 |
| len-dt | fun fun. | 19:57 |
| len-dt | ailo, I tried something different, but it still looks good... Hmm, I should check I may have the timers group audio on that machine. | 21:43 |
| len-dt | Ran an external synth in with just a drum beat. Recorded a track. Then ran that out the port and in and recorded on the same instance of qtractor. | 21:45 |
| len-dt | They line up really well. I will try it with out the timers accessible by group audio. | 21:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!