|
|
|
|
|
|
by iheartmemcache
3288 days ago
|
|
|
At least on Linux, you can easily be barraged by tons of IRQs from your FireWire device. Every time some data comes in from your device (let's say some music production platform) it's going to DMA that data right on over via a PCI lane or 4 then fire off an interrupt to inform your OS "hey hey got some new information for ya!". Now imagine the platform was poorly designed so it fires off that IRQ once for each track. You're re-tracking the drums since the drummer you're recording couldn't work with a click track. Let's say conservatively, you've got 2 overhead condensers, some ambient mic, and an SM57 at the kick. He's working against the guitarist and bass tracks along with some scratch vox. Depending on how you're patching and tracks are configured, you could easily have 12 tracks all firing a "hey I've got data for you! CONSUME IT!". Each one of those interrupts is expensive, mind you. I mean not so much now, where we can shield processes on 16-core HT Xeons and basically dedicate a whole core to solely dealing with the interrupts. But imagine the early 2000s where you had P3 single-core's running at 600 MHzs. Each IRQ will context switch, which means whatever active process that was scheduled now gets bumped. The first IRQ is serviced and that process gets back to work and maybe it doesn't even have time to restore it's execution context before ANOTHER dang IRQ comes in. Like I say, not really a problem these days, but not so long ago.... |
|
|
57 resonant peak is at 200 Hz with steep rolloff below. It will sound like a bedroom recording no matter what you do with IRQs and DMAs.