On Fri, May 18, 2012 6:11 am, Eero Tamminen wrote: > Hi, > > I'm not subscribed to ubuntu-studio-devel list, but I thought > to comment couple of your recent mails there.
No problem, I have left all of your text in and cross posted this there. > swappiness setting: > > It's a compromise. If you know that you won't run out > of memory, things work better with low value (e.g. zero). > > If you do run out of memory, larger swappiness value does > swapping pre-emptively so that you aren't hit so hard when > you really do run out of memory. > > -> Use low swappiness and buy more RAM if it works > worse than higher swappiness value. Or don't keep > so many apps open. > > If it works better, but not good enough, make sure > swap is on a physically separate, faster media which > isn't used by applications you use normally. > > If there's still a problem with swapping, buy a new > computer which supports more RAM. With audio, any swap is probably bad. As I have found out, the first thing to do is get more ram. The audio trials I have performed seem to show that I run out of ram long before I run out of CPU cycles. Buying a new computer is not always an option (the cost of a new audio card alone would double the price at least and newer MB don't seem to have many or any PCI slots), maxing out ram more likely is an option. Swappiness is a compromise yes, but... in audio, swap only keeps the computer from freezing or crashing. Once swap hits the take is lost or the stage sound garbled or the synth notes stay on forever. Compromise doesn't help The memory for the required apps must be there. I think the audio user has to be aware of what memory they are using and what is left... and make sure to leave headroom. > zram: > > Sure, compressed cache space is taken from your RAM. > > What you need to do, is to check what kind of compression > rates you get on average. If the memory compresses to > half, you "should" be better off with it, as its swaps extra > disk accesses that typically kill the performance. > > Note however that zram behaves *very* differently from swap > (CPU load instead of disk IO), so Linux memory management > isn't necessarily well geared towards its use when you have > completely differently behaving "swap devices" (also normal > swap). > > -> This is something to try *after* you cannot anymore > add more RAM to your machine and swap behaves > badly despite of fixing above issues. > > I would set zram size to half of /proc/meminfo > (free + cached + buffers) value you have after > you've disabled normal swap and have computer > in your normal working state (apps you normally > use at the same time are open etc). My experience with zram is that it is like very fast swap. CPU load is not a problem that I have found because memory seems to be the limit. Example is my netbook with 1Gig of ram and a 1.6ghz CPU. I start hitting the memory wall using CPU intensive synths (swappiness 0) yet the CPU load is only 33% and looking at what "ondemand" is doing the CPU is only running half speed (.8Ghz) anyway. So zram is not a problem from that view. However, it is still swap and still slow enough the anything in the audio chain that gets swapped out (maybe just a sample file that has not been used for a bit) can stop all the audio till it swaps in again (from my own experience yes). So zram is not useful for audio as it is still not fast enough. Well designed audio apps should try to use memlock, but as I found out, some don't and it only takes one to put jackd on hold waiting for that sample. A missing word in audio is hard to hear and on stage may make no difference, but even a one second delay (with no sound at all BTW) is very noticeable and may even put that instrument out of sync with the rest of the band. For the normal desktop experience xram is fantastic. The swapped out app just seems slow, not dead like with disk swap. So get more memory first then use zram. These are my experiences as I have tried to test these tweaks on both of my (admittedly marginal) machines. I would love to hear other peoples experiences with audio applications. > Pulseaudio CPU usage: > > I think there's a tool with which you can request what are > the current pulseaudio clients. Some clients might be > redundantly making pulseaudio to do extra work. Either > they shouldn't be connected to pulseaudio at all, or they > e.g. cause unnecessary audio conversions etc. > > Profiling system with sysprof or oprofile is also always good. > They would immediately tell which pulseaudio plugin/codec is > to blame as they have different level of performance / > optimizations and one might be able to use anothe plugin > or file a bug on upstream about the performance... Pulse is generally not a problem. Pulse does use a lot of cpu when it is bridged to jackd at lower latencies. However, in my tests, memory limits were a problem before pulse could become a problem. Should pulse become a problem, unloading the pulse-jack module is a quick and easy fix. Stopping pulse is not needed. If the pulse-jackd bridge is needed for the recording project, then using a higher latency (try one step at a time) will probably be the other solution. > > > - Eero > Anyway, very good points, thank you for posting. Len -- 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
