On Sat, 18 Sep 2010 15:24:18 -0400 jordan <triplesquarednine@xxxxxxxxx> wrote: > > Being a release or two behind the bleeding edge is no bad thing for that > > type of user either - if (for instance) 2.6.31-rt works fine in a > > production audio system, there's no big hurry to change it and > > potentially break stuff. For that sort of user, high availability is > > much more important than squeezing every last drop of performance out of > > the hardware. > > true enough. 2.6.32 and 2.6.33 are much nicer though... I'll second this sentiment. We were going to to release a new realtime kernel with the .31 series, but testing showed that it had some significant regressions in terms of event response time and in overall throughput, so we held off. The .33 series is much better in those regards and that's what we'll be going out with in our next release. > > > In audio recording, we're potentially capturing once-in-a-lifetime or > > one-time-ever events, particularly since the industry focus has shifted > > from the studio to the live stage - whether TV, stadium or festival, > > that's where the artists are making their living these days. Even > > festivals run to tight schedules, with only 15 minutes allowed to switch > > between acts, including moving all the gear and repatching it. You can't > > ask the band to go and get a beer while you recompile your kernel :-) > > Ideally, no one would ever be compiling the kernel at a show, lol. I > know I never would! lol....that's hilarious. > You do that stuff on your own time! Artists have always made their > money live, and through merchandise. Record sales go into the Label's > pockets for the most part. > Heh. I haven't actually compiled a kernel on stage, but a friend of mine reworked a play's audio track 20 minutes before curtain when the Windows box ate it's disk; he booted up his Linux laptop and ran the sound sequencer program in a QEMU instance. I think I'd rather rebuild a kernel under the gun :).
Attachment:
signature.asc
Description: PGP signature
