IRQ conflicts causing BTD problems?

[gtrguy4]

I have a laptop, 1.7 Intel Centrino 855GM chipset, 1g ram. I know this computer has PLENTY of horsepower to run PT 6.1 and Digi002. BUT I can't seem to bounce an avg session to save my life. I have tried all of the tweaks and even had Digi tech help for 1.5 hours. Still couldn't fix.

I get the -6085 error..."Audio buffer underflowed, try lowering the buffer size..." and the "System held off interrupts too long.." error.

The machine is ONLY running PT...all unneeded stuff is shut off.

I am trying to bounce it to the internal 60Gb 5400rpm drive. It is a very small session (8-10 tracks with 1-2 plugs per track. Only comps+EQ's. This system SHOULD be able to do this.

Could the interupt error be from an IRQ conflict? My Firewire controller and SMbus controller share IRQ 10, and The graphics controller and all USB controllers share IRQ 11. These are the IRQ conflicts on this system.

The PCI bus and DMA access controller share an I/O resource.

The PCI bus and Graphics controller share the same memory address (OxAOOOO-OxBFFFF)

Any ideas? this is getting rather annoying. Digi can't even fix it.

BTW, this system will do 32+17 on the "DaveC" test to an external drive, and record for over 2 minutes. But I can't BTD 8 tracks???!!

Help!

[tele_player]

Lots of people have had trouble with BTD, on the same systems which had no trouble using 5.3.x

Did you try bouncing to the external drive? Any different?

[gtrguy4]

Well, no...it won't bounce to an external drive either. But, I can bounce the same exact session on my desktop machine's internal drive that is completely "UN-Protools" ready...it is a 2.2ghz P4 512 Ram, tons of other things running, network cards, HS internet, modems, etc... This Laptop performs better than it AND my 3ghz P4 1g RAM that I use at work according to Sisoft Sandra software, but PT 6.1 just won't play nice.

Theoretically it should be SMOKING with PT, but there is some little quirk holding it back.

Does anyone else have problems with shared video memory setups? This thing's main weakness is the graphics, but I didn't think PT would be affected by that.

[rogerhavoc]

Welcombe to the CLUB .

[nikki-k]

Hi!
Sorry to hear you have problems with an obviously great machine.

There are a few things to try, few things to look at.
First, specs for session? (44.1? 24bit? H?W Buffer? DAE? etc.)
Second, with that low number of plug-ins, the cpu isnt being hit much at all Interupts being held off (in my experience ) usually means something else is interferring, or results from "tabbing out" of PT and back again, and then hitting play. If you have PT as only active app, and has OS "focus" the whole time, usually it is something else "grabbing" the system's "attention."

That said, with that system and session as described, it should work fine even at H/W 256 setting, DAE Level 2, 44.1 or 48k, 16 or 24 bit. An IRQ list might help. Are you running Standard PC or ACPI?

Could you try this?
First, create a stereo audio track, set the input to an unused stereo bus, and then set the output of ALL the tracks you want to bounce to that same stereo bus. Set the output of the Audio track you will be recording to to Main Out (so you can hear what you are doing). This will allow you to do a bounce to that audio track rather than use BTD, a now infamous workaround for BTD probs.
If that works, then try...
New session, create stereo Master, add the typical plugs you would to the master. Add 2-3 Aux tracks with plugs you would typically use as send/group fx. Then, import audio to track, throw the plugs (EQ and cmp you mentioned). Start importing one wav or audio file, then try BTD with it set to "convert after bounce." (CAB takes such little time that converting during bounce and having it fail is an option I dont even bother with. YMMV). If this works fine, import audio to track (again), add fx, attempt BTD. Repeat until it fails.

The disk you are using and bouncing to may be part of it, as it is only a 5400rpm.

Hopefully one of those options will either solve or help diagnose the problem(s). If it doesn't, maybe Rail will see this and provide further insight

[gtrguy4]

Thank you for the very good suggestions..I will try them tonight if I get some time and see what happens.

Also, could you laptop users look and see if your SMBUS controller and IEEE 1394 controller (firewire) share the same IRQ? Mine does and I can't help but think that's not a good thing!

The 1394 controller is what the Digi002 uses and the SMBUS is the system resource bus! Could this also contribute to the interrupts errors? Am I barking up the wrong tree here?

I'm gonna figure this out dangit!

[Cliffy_Boy]

firewire should have its own IRQ or else Interrupt reuests can interupt the continuous firewire signal and lose communication.

[gtrguy4]

So how the heck can the IRQ be changed on a laptop with XP??? XP isn't supposed to have IRQ problems!

I'm curious what makes you think this is a problem Cliffy. I have my own ideas and I'm curious if others have more "solid" reasons.

Nikki-K - I am running the PC in ACPI mode.