OK...
Having some strange behavior here and I don't know what to make of it.
Getting the error "Unexpected DSP Overload" and asks me to cancel or 'retry'. No mention in the manual. I have a Pulsar II and an SRB card installed (21 DSP)
I have read the posts about heating issues and TDM connectors and card seating....
I checked and cleaned with alcohol all connections.
I re-installed both Windows XP and SFP 3.1c
There is a pattern to the error:
It only happens if I load a project that takes up more DSP than on my Pulsar II. If I load a project that uses less than 6 DSP's, it will load fine....
I can load up individual devices until the cards are full...no error.
I can save the project and exit....no error.
If I try to load the project back....error.
So anyone have any ideas? I don't think it's a heating issue or a TDM connect issue. What is my next move?
Thanks for your help.
"Unexpected DSP Overload".....help
you want to recover your project ?
STEP 1 : after the dsp overload message, you should be able to save a few presets of your devices. SO you can remove one of the big dev (a synth, a big effect) after you saved the preset for your song. Then, you delete this dev from your project, and save the project with another name. (Recover-A.pro)
That, way, the project will use less dsp when reloaded !
STEP 2 : Now, record some tracks of your project, save presets and remove the devices, and load the one you deleted in first step : load it preset, record to audio, save the project with another name (recover-B.pro)
Now you recorded many devices that took dsp, you can remove them and continue your project (save the project with deleted devices to be able to come back) (songname-phase2-01.pro )
i hope it helps.....
STEP 1 : after the dsp overload message, you should be able to save a few presets of your devices. SO you can remove one of the big dev (a synth, a big effect) after you saved the preset for your song. Then, you delete this dev from your project, and save the project with another name. (Recover-A.pro)
That, way, the project will use less dsp when reloaded !
STEP 2 : Now, record some tracks of your project, save presets and remove the devices, and load the one you deleted in first step : load it preset, record to audio, save the project with another name (recover-B.pro)
Now you recorded many devices that took dsp, you can remove them and continue your project (save the project with deleted devices to be able to come back) (songname-phase2-01.pro )
i hope it helps.....
grotools...
Thanks for the tip....however...this isn't a case of running OUT of DSP....
I have plenty of DSP left over on the boards...it is just a matter that I get an error message trying to load a project that uses ENOUGH DSP that both boards are active.
Does this make sense?
My meter might say 50%...but I still get this "unexpected DSP overload" and it is somehow tied to my sample rate because it asks me if I want to make changes to the project before re-setting the clock/ sample rate.
BTW I am clocking the system via AES / EBU from an Apogee Rosetta at 44.1khz. Never had it lose sync and I get the error even if I have the Pulsar set as master clock.
Thanks for the tip....however...this isn't a case of running OUT of DSP....
I have plenty of DSP left over on the boards...it is just a matter that I get an error message trying to load a project that uses ENOUGH DSP that both boards are active.
Does this make sense?
My meter might say 50%...but I still get this "unexpected DSP overload" and it is somehow tied to my sample rate because it asks me if I want to make changes to the project before re-setting the clock/ sample rate.
BTW I am clocking the system via AES / EBU from an Apogee Rosetta at 44.1khz. Never had it lose sync and I get the error even if I have the Pulsar set as master clock.
What did you do?
Ive been plagued with this problem for months!
I have some projets that requires only about 4 or 5 dsps and yet when I load it I get DSP overload continually and I have 33 dsp system. Scope SP (old board)/ Scope SRB (new board) and Luna II. The Scope SRB is first, the SP second and the Luna 3rd. If I remove the minimax from the project the overload messages go away!
I have some projects that require about 70% of my dsp that wont even load now. They give me pepscope.dll errors and SFP crashes.
Any ideas what could be causing this?
Ive recently cleaned the STDM connections and improved the cooling but it has no effect.
Ive been plagued with this problem for months!
I have some projets that requires only about 4 or 5 dsps and yet when I load it I get DSP overload continually and I have 33 dsp system. Scope SP (old board)/ Scope SRB (new board) and Luna II. The Scope SRB is first, the SP second and the Luna 3rd. If I remove the minimax from the project the overload messages go away!
I have some projects that require about 70% of my dsp that wont even load now. They give me pepscope.dll errors and SFP crashes.
Any ideas what could be causing this?
Ive recently cleaned the STDM connections and improved the cooling but it has no effect.
orbita,
As said above, it seems you need to experiment with both the PCI placement order of cards in your PC ...AND....the order in which SFP recognizes the cards.
Creamware recommends the cards be in the middle PCI slots if possible.
Then I went in and changed the cset.ini file to load the SRB first. (also if you are using older boards along with newer (2nd gen boards)...you have to add a line in the cset.ini file telling SFP how many boards you have)
I also went into the BIOS settings and tried to arrange IRQ's so that minimal sharing was going on. (some was unavoidable....but I tried to get heavy load and low load peripherals together).
So it's been working well so far. I used the system all day yesterday without the error. Hopefully I am in the clear now. **knocks on wood**
Best of luck to you....I KNOW how frustrating this can be. (I'm a MAC USER to boot....so this is TOTALLY alien to me)
<font size=-1>[ This Message was edited by: Kamurah on 2003-06-16 11:18 ]</font>
As said above, it seems you need to experiment with both the PCI placement order of cards in your PC ...AND....the order in which SFP recognizes the cards.
Creamware recommends the cards be in the middle PCI slots if possible.
Then I went in and changed the cset.ini file to load the SRB first. (also if you are using older boards along with newer (2nd gen boards)...you have to add a line in the cset.ini file telling SFP how many boards you have)
I also went into the BIOS settings and tried to arrange IRQ's so that minimal sharing was going on. (some was unavoidable....but I tried to get heavy load and low load peripherals together).
So it's been working well so far. I used the system all day yesterday without the error. Hopefully I am in the clear now. **knocks on wood**
Best of luck to you....I KNOW how frustrating this can be. (I'm a MAC USER to boot....so this is TOTALLY alien to me)
<font size=-1>[ This Message was edited by: Kamurah on 2003-06-16 11:18 ]</font>
Oddly I've experienced this using problem using only one 15 dsp board so the order couldn't have had any effect.
With the 3 cards, I have tried many variations. Its been impossible to get the cards all onto separate irqs using non acpi mode. Now Im using ACPI with my APIC board supporting 24 irqs and it gives them all separate IRQs but it has had little effect. I have my new 15DSP board as the first card in my machine, my Luna as the second card and my Old 15DSP board as the last card. However in my cset.ini file I have it setup so that the Luna is last becuase it has only 3dsps. This has been the most stable setup so far but I still get some problems. I wonder if it is some syncing incompatibility between the new and older boards. Which is why I recently tried with only the one 15 dsp board and was surprised to still get some of these errors.
With the 3 cards, I have tried many variations. Its been impossible to get the cards all onto separate irqs using non acpi mode. Now Im using ACPI with my APIC board supporting 24 irqs and it gives them all separate IRQs but it has had little effect. I have my new 15DSP board as the first card in my machine, my Luna as the second card and my Old 15DSP board as the last card. However in my cset.ini file I have it setup so that the Luna is last becuase it has only 3dsps. This has been the most stable setup so far but I still get some problems. I wonder if it is some syncing incompatibility between the new and older boards. Which is why I recently tried with only the one 15 dsp board and was surprised to still get some of these errors.
-
Herr Voigt
- Posts: 624
- Joined: Sun Jan 06, 2002 4:00 pm
- Location: germany, east
@ Herr,
Using Standard mode it was impossible to avoid 1 of my creamware cards sharing an IRQ with my Matrox Card. I could get the first 2 cards sharing an IRQ of their own but the 3rd card would Always share an IRQ with my graphics card no matter which slot it was in or what I set the bios to.
In ACPI mode, it assigns them all a separate IRQ so there is no sharing at all. But it functions identically to above.
@Garyb,
In some instances, the dsp overload errors would appear and everytime I clicked to reload dsps, it would reappear again and again. If I pressed cancel the system would lose sync and when I attempted to change sample rate to regain sync the dsp overload messages would come back. Making it impossible to use the project until I removed certain synths even though the total project was only using 3 or dsps out of the 33 that I have. In one example it seemed to be minimax that was causing the problem.
In other instances I would save a project only for SFP to crash after the next time I load it. I still have some projects that I cannot load again. It will load all the modules up, but just as it starts to display the windows SFP crashes with a pepscope.dll error.
If I delete the SFP registry file it is sometimes able to load the project. But even after removing certain modules and resaving it, it will still crash.
Thanks for you interest.
Getting support from creamware is appallingly slow although they have started to try and help recently.
Using Standard mode it was impossible to avoid 1 of my creamware cards sharing an IRQ with my Matrox Card. I could get the first 2 cards sharing an IRQ of their own but the 3rd card would Always share an IRQ with my graphics card no matter which slot it was in or what I set the bios to.
In ACPI mode, it assigns them all a separate IRQ so there is no sharing at all. But it functions identically to above.
@Garyb,
In some instances, the dsp overload errors would appear and everytime I clicked to reload dsps, it would reappear again and again. If I pressed cancel the system would lose sync and when I attempted to change sample rate to regain sync the dsp overload messages would come back. Making it impossible to use the project until I removed certain synths even though the total project was only using 3 or dsps out of the 33 that I have. In one example it seemed to be minimax that was causing the problem.
In other instances I would save a project only for SFP to crash after the next time I load it. I still have some projects that I cannot load again. It will load all the modules up, but just as it starts to display the windows SFP crashes with a pepscope.dll error.
If I delete the SFP registry file it is sometimes able to load the project. But even after removing certain modules and resaving it, it will still crash.
Thanks for you interest.
Getting support from creamware is appallingly slow although they have started to try and help recently.
-
marcuspocus
- Posts: 2310
- Joined: Sun Mar 25, 2001 4:00 pm
- Location: Canada/France
If cw card share with matrox, move the cw card elsewhere.
Even in ACPI where in windows you will see that it as it's own IRQ, in hardware terms, it doesn't. That's why you're having the same behavior.
Move it until it does not share with anything else or maybe only with another cw card.
To see if it's sharing, look when you start the PC, forget totally about what windows tell you, it's not reliable, cuz they are software assigned in windows.
Even in ACPI where in windows you will see that it as it's own IRQ, in hardware terms, it doesn't. That's why you're having the same behavior.
Move it until it does not share with anything else or maybe only with another cw card.
To see if it's sharing, look when you start the PC, forget totally about what windows tell you, it's not reliable, cuz they are software assigned in windows.
@marcuspocus
As I said in my previous post, I did try every available pci slot combination under standard mode and one card ALWAYS ended up sharing IRQ with the matrox. It didnt matter which slot it was in or what IRQs I tried to force them to in the BIOS.
@Immanual
yes I wondered abotu this option too, but really that only has an effect on the STDM connections. When I used to have the Luna as the first card I recieved allot of STDM errors "Cannot make STDM connection .." Now I have it as the last card I do not recieve them anymore. However The symtoms I describe above regarding dsp overloads occur even when I remove the luna card an Also when I just have 1 card in the system. So it cannot be related to STDM.
I suspect it is more likely to be a combination of my old SP card having trouble syncing with the new cards and my projects getting corrupted somehow.
As I said in my previous post, I did try every available pci slot combination under standard mode and one card ALWAYS ended up sharing IRQ with the matrox. It didnt matter which slot it was in or what IRQs I tried to force them to in the BIOS.
@Immanual
yes I wondered abotu this option too, but really that only has an effect on the STDM connections. When I used to have the Luna as the first card I recieved allot of STDM errors "Cannot make STDM connection .." Now I have it as the last card I do not recieve them anymore. However The symtoms I describe above regarding dsp overloads occur even when I remove the luna card an Also when I just have 1 card in the system. So it cannot be related to STDM.
I suspect it is more likely to be a combination of my old SP card having trouble syncing with the new cards and my projects getting corrupted somehow.
I was actually informed by a CW tech that those busses aren't meant to be simultaneously connected. I thought it strange as I heard that there was some relationship to the # of internal routing connections you can make, but he insisted that they're not meant to be connected across multiple STD/M busses simultaneously and that the multiple connections are available to facilitate connections at varying PCI card depths that each type of SHARC card uses. Any Creamies who can confirm or deny this for us?On 2003-06-19 13:03, Immanuel wrote:
orbita
Just a guess: I think your system will work better witout the Luna card - having 5 connectors between the cards - and no card trying to keep up with only one connector.
Sam
<font size=-1>[ This Message was edited by: dehuszar on 2003-06-21 18:43 ]</font>
@dehuszar: I don't quite understand the reasoning in your post, or what the Creamware guy meant, but:
You need as many S-TDM connections between cards as possible. They carry a certain number of audio channels between the cards.(144 @44.1/32bit pr. cable if I remember it corectly.) So, more cables= More channels.
In the example above with 2 Scope cards and a Luna, you connect 5 cables between the 2 scopes, and the first cable goes on to the Luna.
About the "unexpected dsp-overload" message:
<b>Usually</b> it has nothing to do with hardware setup or software installation;
It is specific devices that's causing it, under certain conditions...
One example is the Minimax: It does not work proberly in 96KHz. Another example is the big mixers, with phasecompensation on.
It has to do with dsp allocation as far as I can tell; What will fit on one chip at 44.1 or 48, wont at 96. (I'm fighting with this on one of my own designs.) So the Minimax and other devices will need an update to function proberly at 96KHz...
Kim.
You need as many S-TDM connections between cards as possible. They carry a certain number of audio channels between the cards.(144 @44.1/32bit pr. cable if I remember it corectly.) So, more cables= More channels.
In the example above with 2 Scope cards and a Luna, you connect 5 cables between the 2 scopes, and the first cable goes on to the Luna.
About the "unexpected dsp-overload" message:
<b>Usually</b> it has nothing to do with hardware setup or software installation;
It is specific devices that's causing it, under certain conditions...
One example is the Minimax: It does not work proberly in 96KHz. Another example is the big mixers, with phasecompensation on.
It has to do with dsp allocation as far as I can tell; What will fit on one chip at 44.1 or 48, wont at 96. (I'm fighting with this on one of my own designs.) So the Minimax and other devices will need an update to function proberly at 96KHz...
Kim.
Gee it feels good to know ur not the ONLY one out there with a problem.
I opened the cset.ini file and i'm not quite sure which line of code i am meant to be adding/deleting/altering? can someone plz give a semi detailed/ detailed description of what to do..
I am running a Gigabyte P4 Titan Intel 845 , socket 478 board (GA-8IRXP). unfortunately a RAID system...so having a few problem when using more than two tracks of recorded audio...
Please help meeeee!!
ps: what would be a good arrangment of cards on the motherboard...Pulsar II and scope
thank you
derek
I opened the cset.ini file and i'm not quite sure which line of code i am meant to be adding/deleting/altering? can someone plz give a semi detailed/ detailed description of what to do..
I am running a Gigabyte P4 Titan Intel 845 , socket 478 board (GA-8IRXP). unfortunately a RAID system...so having a few problem when using more than two tracks of recorded audio...
Please help meeeee!!
ps: what would be a good arrangment of cards on the motherboard...Pulsar II and scope
thank you
derek