On Tue, May 22, 2012 12:31 am, óÅÒÇÅÊ äÁ×ÙÄÏ× wrote: >> Yikes!! ulatencyd takes effect as soon as installed. Start qjackctl ok, >> hit the start button on qjackctl... takes a long time do anything, lots ... > Whoa, sounds like a bug. Please report at > https://github.com/poelzi/ulatencyd/issues
I'll get there. I tried ulatency on another machine (newer) and it is ok. Once I figure out if it will help in this situation... and how to set it up, I'll go back to the original machine and try again. > Also, Debian package has memory and swap management disabled by > default, it's done via Debian-specific patch. Try enabling that and > see if it works. Also, I don't think it has any rules for qjackctl > OOTB, so you probably won't notice any difference. Yes, they say "memory specific" :-) I realize I will have to set up rules, They have three defaults there, none of which are what we need for audio. In the mean time... I have been experimenting with both swappiness set to zero and swapoff. It has been a good experience: Rule 1) never run unnecessary software. My test setup had swappiness 0 and jackd running silence to outputs with qjackctl to monitor for xruns etc. I left it this way overnight (8 to 10 hours) and things seemed ok. at the 8 hour mark there were a pile of xruns and at the 9hour or so. I found that swap was about 50% full or so. So I thought I would try the same thing with swap off. I ran it over night too, but it did not make it even to 7 hours. I found it at the logon screen and assumed it had rebooted itself. So I logged in and noticed I had no wireless. I checked the runlevel and found it at RL3. I have RL3 set up to stop cron and friends as well as unload the wireless driver (ath9k) which causes an xrun per minute while loaded (or much worse) So it was obvious that it had only logged out not booted (boots to RL2). After some thought it occurred to me, that what I had was a memory leak such that the cpu was killing my session with an OOM. So I watched the memory over time and saw no problems... so it had to be happening when I wasn't watching, my guess was the screen saver (I had set it to GLSchool), so I set things to "blank screen only" and tried the no swap test over again. Perfect. Even after 24 hours the memory use was very close to the same as when I started. So I repeated the test with swap on and swappiness to 0 again and am happy to report no swap use after 16 to 18 hours. In the mean time I have been reading as much as I can find about swap in Linux. (googling linux no swap gets lots) It is clear That for normal desktop use having swap available is a good practice. That there are many applications that ask for chunks of memory when they load that they use only for initializing, but then never give up. That unused memory gets paged out to swap leaving that space for other uses. My testing with swappiness 10 seemed to agree with this assessment. That brought me back to ulatencyd which would allow the user to decide what would be allowed to swap out. After some thought, I am seeing a problem with this though. I thought about what should be allowed to swap out in an audio situation. Obviously the audio programs themselves, but I have found that with even a quite simple recording project I run out of screen space very quickly so I use more than one workspace and switch between them... The screen pager just became an "audio" application... same for the panel and the desktop background. Very quickly I was starting to think that there are less things to allow to swap than not. The other thing I am wondering is how the kernel swaps memory back in? How high a priority is that? Can it be bit at a time or does each page get done in one uninterrupted time slice? And how long does that take? In other words would a swap in by even a low priority process cause an xrun in my audio? Still thinking... I am sure that the people who design swap are not thinking RT stuff... I could be wrong. -- Len Ovens www.OvenWerks.net -- Ubuntu-Studio-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
