PCI Overload issue - 12 DSP on Windows XP with UAD-1 cards

[pdistefano]

Hi there all
Have a little issue that I'm hoping someone here may know how to possibly resolve.
I have an (oldish) PC running windows XP (dual core AMD, Asus A8V Deluxe motherboard, 3GIG RAM) with 5 PCI slots loaded. 3 are taken with Scope cards (2x Scope Home, 1x Pulsar XTC (6DSP booster) - (Scope critical to/heart of my set-up as I run 32 channels audio out to console), the other 2 are UAD-1's. DAW is Cubase SL3 (I know, 10yrs old but all I need )
Anyway lately have been getting reasonably frequent "PCI Bus Overload" message. Starting to really impact productivity
UAD cards probably loaded nearly to 90%, but Scope system running only at max 70% if that.
I've checked out the IRQ assignments and I'm guessing I have an issue with (AGP) graphics card sharing the same with the UAD cards (??), but I don;t know how to change it. Scope cards have their own IRQ but the IRQ is 21 or some high number that I know is a "virtual" IRQ.
My instinct is that if I could get the system better set-up IRQ-wise I perhaps may not have the PCI bus Overload issue.
Any thoughts/suggestions/tips that I could try? I could try physically swapping cards around, but that's probably hit/miss. I've disabled all com ports etc not being used in the bios but hasn't really helped the IRQ issue.
I'm trying to avoid upgrading the PC (as that's another whole exercise/can of worms in itself) as for the most part it's doing fine and all I need and since I've invested in the DSP cards rather than native software I'd rather attempt to have a proper crack at troubleshooting this issue.
Thanks - any thoughts would be greatly appreciated.
Paul D

[garyb]

it's not an irq thing, everything has a limit.
the PCI bus has a limit. a newer motherboard won't change that limit much.

what uses the PCI resources?
mostly reverbs and delays which must communicate with ram through that pipeline and-
ASIO channels. the UAD cards use the bus for the same reasons. only so much traffic can inhabit the bus.

the UAD cards are less troubled by traffic, as they aren't involved in realtime audio. the Scope cards don't live in a land that tolerates latency, they don't exist as part of the sequencer. the DSP load has nothing to do with the PCI traffic or the message. you are getting the performance you should, most likely.

how many masterverbs can you put in an empty project before PCI overload? this is the test of PCI performance of any motherboard. some work better than others. without heavy tweaking, the most is about 13 or 14 and the least is 2 or 3. 7 or more would be normal.

[pdistefano]

Appreciate your comments Gary - thanks
I did the Masterverb test. Can get 8, the 9th brings up the overload message
So you're saying that this is reasonable, it is what it is and that's the limit of this particular set-up/machine?
So rather than consider upgrade or thinking that the machine requires better config, perhaps it's a matter of accepting the particular bus limit and being more clued into managing it and looking at alternatives by perhaps "outsourcing" some of the more bus-hungry stuff (reverbs,delays) in outboard options (which i have) or handling/distributing some of this load on my 2nd Scope machine (7DSP)??
My DAW consolidates the audio to approx 32 ASIO outputs, some of which I process again within Scope environment, before spitting out to the 32 channel console. So I appreciate if I've pretty much maxed out the UAD's in the DAW, running this many channels as well as doing quite a bit of audio processing in scope I'm obviously pushing/test the limit of the PCI bus

[garyb]

yep.

[dawman]

One thing that has always been inefficient in many ways are the ASIO limitations.
Imagine a Mac/PC using a DAW with it's own Operating System.
Hope to see it before I have Grandchildren, but it appears that would be a product to change the status quo, and give end users a product free from upgrades.........Fat Chance.

[YISH313z]

Im eyeing Windows embedded, and not understanding why there is not Daw only version of windows, with all of the bells and whistles stripped out.

Im trying not to count my greys

[dante]

Im eyeing Windows embedded, and not understanding why there is not Daw only version of windows, with all of the bells and whistles stripped out.

Why stop at the OS when theres complete Integrated Audio Appliance ? Of course it exists - its called RADAR
http://www.izcorp.com/products/radar/

Was on show @ NAMM last month.

[pdistefano]

Correct me if I'm wrong, but doesn't RADAR use Windows as the OS, with Harrison Mixbus DAW??
Wouldn't it be great if SC came up with a similar dedicated computer/interface/DAW set-up that's free of windows or whatever that only does what it needs to - optimised I/O and audio processing/recording. Can't be that hard or am I completely ignorant/naive as to what would be involved??
Interesting isn't it how many of us here are still playing around with good old fashioned PCI based hardware when the dominant companies are doing their best to make it increasingly difficult for us to move over to the new generation machines - hence my 10yr old PC -
Maybe we're just a niche market??

[dante]

I thought Harrison Mixbus only ran on Linux or Mac.

[garyb]

Correct me if I'm wrong, but doesn't RADAR use Windows as the OS, with Harrison Mixbus DAW??
Wouldn't it be great if SC came up with a similar dedicated computer/interface/DAW set-up that's free of windows or whatever that only does what it needs to - optimised I/O and audio processing/recording. Can't be that hard or am I completely ignorant/naive as to what would be involved??
Interesting isn't it how many of us here are still playing around with good old fashioned PCI based hardware when the dominant companies are doing their best to make it increasingly difficult for us to move over to the new generation machines - hence my 10yr old PC -
Maybe we're just a niche market??

yes, it's a much bigger job than you can imagine.

the current computers work pretty well with the old PCI cards...

[pdistefano]

Looks like Mixbus runs on Windows, Mac & Linux............... BTW is there anyone who's played with it / heard what it sounds like? I'm curious .......and it seems relatively cheap (!!)

But that's kind of off-topic so coming back to this PCI bus limit/issue (Gary) you say that the current computers go OK with the older PCI cards - fine - but is there any particular set-up that has given priority or particular optimisation to this area? I suppose question is, what would a machine upgrade achieve in regards to SCOPE's PCI performance?? Are you saying not much?? If the MV test is a guide to performance in this regard, I'm sitting on around 8 (average-ish???), is there a particular set of machine hardware spec's/set-up you'd consider to be high(er) performing/recommended in this regard??

Also, I've got a 4 DSP Pulsar card with the double ADAT outputs. I'm now utilising these (previously unused) connections to link the two machines (as per previous post). But it was only showing "ADAT A" connections and not "ADAT B", I thought something was wrong with the ADAT B connections, but then when I loaded in the ADAT A it came up as 16 channels, which when tested was in fact (& obviously) both the ADAT A & B combined , which is fine......... is this normal??

[dante]

My latest AsusZ87 mobo runs about 4 less (9) masterverbs than my previous Asus P5KE (13) - however, that has not in any way translated to me being able to do less overall with Scope.

[garyb]

Z87 or Z97 socket 1150 motherboards generally work great.

[pdistefano]

Thanks for your suggestions.

Now I have another issue (!!) - following on from this - as described in previous post I've now connected my two machines via ADAT. I have ADAT A out of main machine feed ADAT A in of 2nd. I'm not returning via ADAT, analogue out of the 2nd machine into outboard gear. Now one channel works fine (using to send audio to a reverb) Happy days. However then tried to send another couple of ADAT outs but have a weird stuttering crackle thing happening, no matter what channel I try . It's certainly coming from the ADAT outs? Or some sort of sync issue?? But it's strange that still one channel is working "clean".

Suppose this could be a number of things but would be grateful for any advice/suggestions?
Thanks

[garyb]

there can be only one audio digital clock.

clock travels along the ADAT output, if you sync clock to ADAT.
there can only be one system set to master, the other must be slave.
if you use both cables, then either system can be slave or master, just pick master for one and slave for the other.
if you only use one cable, then the source ADAT system(from OUT) MUST be master and the receiving system MUST be slave.

[pdistefano]

So you're saying it is likely a clock issue? I had accordingly set-up so main is Master, 2nd machine slave as suggested, but still same problem
A couple of other details though.
I'm also running (other) 2 sets of ADAT outs to A16Ultra, with one of these being set to be set the sync source. So how do I then achieve the additional ADAT outs to other separate destinations (2nd machine and another external ADAT device) and ensure they're receiving the sync sources from those ADAT outs too? I assume you can only specify one clock/sync source per SCOPE system?? Is this possible without utilising an external clock? Am I attempting the impossible here??
I could always try getting around this using analogue options but that would be 2nd preference (!!)
Thanks again...

[garyb]

well, for several devices, an external clock with multiple parallel outputs is best, but then you need bnc connectors on everything.

digital signals always work the same, regardless of the system. there must be a single master and everything else must be slave. clock does not work well in a serial chain. maybe simplifying your setup for the specific job would be best...some device work better as master or slave, some don't care. did you try to clean the ADAT ports out with compressed air and/or try a different cable?

[m.my91]

Z87 or Z97 socket 1150 motherboards generally work great.

z87 is not good:
Haswell (socket 1150) motherboards using the B85 or Q87 chipsets (PCH) will still support "native" PCI slots, if any, but don't support overclocking with a "K" processor.

Motherboards using the Z87 PCH (which supports overclocking with a "K" cpu) or the H87 PCH will only offer "bridged" PCI slots if any.
http://www.soundonsound.com/forum/showf ... in=1051238

[garyb]

well, users' good experiences tell otherwise. check the masterverb thread.

the problem is not the lack of native support of the PCI slot in the chipset, or the comtroller chip. it's the implementation.

[tlaskows]

Yep, z87 working here just fine... 10 MVs

-Tom