Hi,
Just wondering if anyone else had error messages about reaching the DSP limit even when they still have spare DSP power left?
I'm running both a Pulsar II and a Scope SRB card (=total 21 DSP) but when I try to load a new device into an existing (quite large project) I'm getting various DSP error messages telling me I've run out of DSP, although I'm only using about 75% of what's available.
What's really weird is that it seems like DSPs 10 and 12 are stuck to only about 7% usage, and all the others show variable usage between 25-85%. I've sure I've heard something about how you can allocate some devices to specific DSPs - if this can be done, can anyone tell me how?
Machine info : I'm running a P4 1.8ghz, Asus P4B266 mobo, 512mb RAM with Win98Lite and Pulsar 3.01 (not SFP) software.
Weird DSP allocation - anyone know how it works?
Thanks Gary, I'll try that if I get that error message but I would love to know more about what's causing this or if others have had the problem.
If nothing else, it's very frustrating to have paid good money for the power of 21 Sharcs and to be hitting a limit at around 15 - the difference I'm missing could be an entire Pulsar card.
If nothing else, it's very frustrating to have paid good money for the power of 21 Sharcs and to be hitting a limit at around 15 - the difference I'm missing could be an entire Pulsar card.
Sounds like you have a problem in your system maybe? I can load my 22 DSPs full without seeing this message; my friend is loaning me his PowerPulsar while he's here so I'll also test with 30 DSPs shortly.
In past versions of the software, renaming DSP.IDX to something else, and having it rebuilt on the next startup of the Pulsar software, would cure the problem. Did you add your second card after you already had the software working on the first?
In past versions of the software, renaming DSP.IDX to something else, and having it rebuilt on the next startup of the Pulsar software, would cure the problem. Did you add your second card after you already had the software working on the first?
No, no, no! Please don't say that. I was dreading someone suggesting a rebuild. 
It took me a week of builds and rebuilds to get it stable and it's only been up a couple of months.
Anyway, thanks - I tried the DSP.IDX rename thing with fingers crossed, but no dice. Shame, sounded like a great tip too
I can't honestly remember in the end which way round I did it - I'd guess I put the Pulsar in first and then once stable, I added the SRB. Either way round, if the DSP meter isn't lying, the two 'sticking' Sharcs are actually both on the same card - they show as 1/10 & 1/12. From memory I think I remember reading something in the Creamware documentation that said that when you install the SRB it will 'reaassign' itself to be the primary card so this makes sense.
Do you think it's normal that one of the DSPs runs at 100%? I just noticed that it's staying constant and I would have thought that some kind of load balancing should be spreading that out..?
It took me a week of builds and rebuilds to get it stable and it's only been up a couple of months. Anyway, thanks - I tried the DSP.IDX rename thing with fingers crossed, but no dice. Shame, sounded like a great tip too
I can't honestly remember in the end which way round I did it - I'd guess I put the Pulsar in first and then once stable, I added the SRB. Either way round, if the DSP meter isn't lying, the two 'sticking' Sharcs are actually both on the same card - they show as 1/10 & 1/12. From memory I think I remember reading something in the Creamware documentation that said that when you install the SRB it will 'reaassign' itself to be the primary card so this makes sense.
Do you think it's normal that one of the DSPs runs at 100%? I just noticed that it's staying constant and I would have thought that some kind of load balancing should be spreading that out..?
Cheers SubH/GaryB for the suggestions.
I thought I'd post an update on this problem just in case anyone else comes across it.
I actually didn't get as far as checking the STDM connections because it seemed to go away all on its own. All I did was removed a few devices and added different ones, then when I switched everything on on the next morning Pulsar started using those slots properly.
I did also speak to my local retailer, who told me that he had heard from the distributor that this problem does occur very rarely with (only some) Scope SRB cards using Pulsar v3 software. Apparently ungrading to SFP will fix it (or you can do what I did and randomly remove a few devices).
I'm going to give some thought to upgrading to SFP but I need to know a bit more about creating ghost images first so I can revert back to Pulsar v3 if it doesn't work out.
I thought I'd post an update on this problem just in case anyone else comes across it.
I actually didn't get as far as checking the STDM connections because it seemed to go away all on its own. All I did was removed a few devices and added different ones, then when I switched everything on on the next morning Pulsar started using those slots properly.
I did also speak to my local retailer, who told me that he had heard from the distributor that this problem does occur very rarely with (only some) Scope SRB cards using Pulsar v3 software. Apparently ungrading to SFP will fix it (or you can do what I did and randomly remove a few devices).
I'm going to give some thought to upgrading to SFP but I need to know a bit more about creating ghost images first so I can revert back to Pulsar v3 if it doesn't work out.
I have had certain devices, which incidently used their own .dsp files, give me this exact message. Perhaps you can obtain newer versions of the devices which were causing the problem in your projects? It seems CW attempted to maintain backward compatibility with all devices in 3.x, but small tweaks from the developer may be necessary on some devices, particularly custom ones...