On Wed, Jun 17, 2009 at 11:14 AM, Duncan<1i5t5.dun...@cox.net> wrote: > Paul Hartman <paul.hartman+gen...@gmail.com> posted > 58965d8a0906170914l4ebca650uba703a2a6b450...@mail.gmail.com, excerpted > below, on Wed, 17 Jun 2009 11:14:50 -0500: > >> Well, if you want something different then KDE4 is definitely >> different... for better or for worse :) > > Agreed, but if he wants low latency, he'll probably want to be sure to > turn off all the fancy 3D window effects, transparency and the like, and > with that goes much of the reason for using KDE4. =:^( > > If he has a fast graphics card and a relatively low resolution screen, he > may be able to get away with very limited effects, but if I'm right, even > that might be a bit too unpredictable in terms of latency. > > Meanwhile, Mark, you do have the kernel set for a 1000 Hz clock rate, > right? And you have preemptive desktop turned on, and high resolution > timers, right? (These are under Processor type and features.)
I'm using rt-sources which allows another preemption model, intendeded for real-time, called 'Complete Preemption (real-time)'. My timer frequency is 1KHz and I do enable high resolution timer support. Note that running this way I am able to have audio come into my machine, be recorded and also go back out of the machine to be sent to other external audio hardware in less than 3mS. (actually 1.2mS * 2 ) It's fast - much faster than Windows/Avid-ProTools on the same hardware which might need to run around 10mS. Considering that somewhere around 10mS is where humans might begin to sense an echo I need fast. I like fast. I pay for fast. This is one area where I have no doubt I beat M$ by using Linux. > > You may also wish to experiment with Group CPU Scheduler (under General > setup), if you regularly run background tasks as other users and you want > to be sure your audio user gets his share of CPU. With that on you can > then tweak the /sys/kernel/uids/<idnum>/cpu_share numbers, keeping in > mind that the default is 1024 while the root default is 2048, and that > the <idnum> dirs will come and go as users do. I don't do your sort of > audio, and run the more moderate voluntary preemption and 300 Hz clock > (with tickless also on), but combined with setting PORTAGE_NICENESS=19 in > make.conf, I can run all sorts of emerge jobs, CPU loads in the hundreds > if I want as long as don't run too far into swap, and still keep a > relatively responsive desktop, and if I had full preemption and 1000 Hz, > I think I could almost do your style of recording even while running > emerges! (Oh, I also have PORTAGE_TMPDIR pointed at a tmpfs, thus > keeping unnecessary I/O to a minimum. That makes a difference to > responsiveness while merging too, as does having the memory to keep it > out of swap while doing so.) All of this probably make sense, and I'll do a little study on the matter, but when running Ardour recording a band playing a live gig it's a one-shot, you gotta get it right sort of event. There is only one performance. During tracking (the process of recording the artist's live sound to individual tracks) I generally run nothing but Ardour with the Jack server to manage application audio routing and timing, and then possibly one or two other audio apps. I may not see my desktop for hours. There are no browsers, generally I even disconnect network connections at the switch if in my home studio - probably not necessary but 8 years ago it was very necessary in Linux as even a packet arriving could cause delays. Typically I'm sitting in the mixing console area with the live sound guys grabbing a feed from the stage (for rock) or I'm mic'ing the stage myself for smaller venues. (Jazz combos, big band, etc.) Now, my hardware/kernel are really optimized for live recording, but when I bring the machines home I still have to work on them. They are used as standard desktop machines most of the time but serve as mixing platforms after tracking. During these times real-time operation is still important, but if I have a glitch in the audio the worst I have to do is do the job a second time. It doesn't happen often, but it does happen with Gnome once in awhile. In the old days it NEVER happened with fluxbox, and probably still doesn't. As I say, my migration away from fluxbox was really a management issue and not a negative about the technology. fluxbox is great for my audio needs, just wasn't so great for day-to-day life. However I'm really bored with Gnome and hence why I started this thread. > > Of course, it may be that you simply don't run enough background tasks as > other users to make any difference with the group scheduling stuff, and > that was only added in 2.6.27 or some such, so if you're running an old > kernel you won't have the group scheduling at all. IOW, YMMV, but it's > worth looking at. Currently running 2.6.29.2-rt11, and is probably clear, when it's important I don't run any background tasks as a user. Only system things are allowed to take place, and even those are controlled as much as I can. Thanks and cheers, Mark > > -- > Duncan - List replies preferred. No HTML msgs. > "Every nonfree program has a lord, a master -- > and if you use the program, he is your master." Richard Stallman > > >
