PlanetZ forums - scopeusers.com

If anybody know how to sort out the following problem it would be most appreciated!!! I need to fix this once and for all... The Scope system/ my setup is not stable and I cant work like this in a proffesional studio any more. If things aren fixed soon I'm selling the lot. So please this is my last chance to get my Scope system stable - cos when it works I love it.

Atom /Garyb and all others that have stable systems and extended knowledge; your input is crucial for my mental health. ..t. I'm getting tired of Scope related problems!!!!

System being; XP pro w/SP2, P4, Asus p4p800, 2.6Ghz, 2G ram, 2x 120gb Seagate barracuda, Matrox G550 dual, Pulsar II, Luna w/zlink extension, 2 x A16Ultra.

from day one the system have been playing tricks on me. This is probably due to starter problems, IRq conflicts, Matrox screen card, the ususal beginner stuff. But I have tweejked and redone my system until It finnaly looked like a stable system..... But problems finding the sample rate in startup have been a issue all along... finnaly it looked like the STDM cable to the Luna (DSP board) was the issue... tutching it a bit while system being in slave mode usually got the sample rate locked..or leaving it in slave mode got the "sync light show" to subdue...

So problem 1) Sample rate locking issues

(hardware or software problem?)

A week ago I suddenly started getting Cpu spikes in the middle of a mix session. in Cubase Sx. The Vst meter is dancing like there is no tomorrow when no projects is loaded . When a cpu consuming project is loaded there is rytmical spikes every second or so. Sysinternal.exe show loads of DPC's and Interupt requests .- Scope is the clearly the issue (or comunication Scope /cubase SX) . Turning off scope solves the problem and the DPC's and Interupt requests normalize. .

When loading a empty Scope project the Spikes are not there , when loading only one asio dest., the spikes get back... So it def looks like a Asio issue.

Problem 2) Scope Asio drivers create lot of IRQ's and DPC's and (therefor) CPU spikes.

Strangely enough I have a different input latency in Cubase SX then output...

problem 3) Different inoput/output latency in Cubase

Should/might be related to sync/buffer setup so I tried Cubase asio test but get error code FF8-5-000C...

problem 4) Cant perform Cubase SX sync test. Not detected

Should I fiddle aroubd with Cubase buffer size? What's the best buffer setting?

Wll this will hopefully get some respons for starters - will post more info as we go along...

Please Help!

Thnaks and regards form Endre70

well, don't nail me down on Cubase, but imho there are some basic issues to be sorted out.
First of all - if clock sync gets lost on problems with the samplerate the Asio driver will go down the drain - regardless if you see it (immediately)
From my experience a reboot applies in such cases and not just a re-load (better safe than sorry - workflow is interupted anyway)
So before you can even consider Cubase or Asio you got to have the samplerate and (Scope) internal communication right.
Cables, STDM connector, proper ground (of the chassis)

If you touch the STDM connector and it changes sync, that does not necessarily mean the connection itself is the culprit - it might trigger an kind of 'small reset' of the communication, which picks up clock again.

On the other hand that cable is a known source of trouble - how far are your cards apart from each other ?
Does it look like you have 'cable left over' between the connectors ?
I found this (depending on how you treat/bend it) could in fact move the connector somehow.
There's a lot of vibration inside a PC case.

Not that I want you to do the same - this is just for illustration - (!)
I've cutoff the cable directly behind the mid connector, carefully removed the plug (the plastic parts are a bit sensible, one has to bend them with a tiny screwdriver to get the locks open) and placed it right between the 2 remaining connectors.

On the other hand you could bend 'dangling' STDM cable in a way that the case enclosure puts it down in the direction of the card, like a spring.

Is Scope sync master or an external device ?
If the latter is true, a damaged device/project can reset sync while it loads - I've observed this a couple of times as my Scope is synced to an A16, suddenly it's set to master while the A16 continues to 'think' it's still master and continues to send, which results in clicks and crackling for obvious reasons.

Are your cable whips (in case you use them) in good condition ? Some people had sync problems with short circuits in side the whip's connector.
It's easy to open and to inspect.

If all physical conditions are met, then I'd use the system over some time without Cubase and Asio, and check for clock issues - it might overheat for example
If all is stable then I'd setup a fresh project with Asio and try a simple host like Energy XT or Reaper or whatever not very demanding.

If you get that far you have a solid base and you can be almost certain that problems (if they show up) are located around the sequencer.
Imho it's important to sort everything out before dealing with Cubase, as it's the most compleyx component and depends on OS, driver and hardware more or less simultaneously.

cheers, Tom

if ASIO is causing a high number of interrupts, this is exactly what it should be doing (interrupts mean that data is being sent back & forth to the soundcard, and a low latency setting means that you'll have tons of interrupt calls). If you're seeing cpu issues as a result, that means there is a conflict somewhere, most likely a shared irq or something (like a graphics card) that isn't happy sharing the PCI bus's bandwidth.

There's tons of info on these forums to figure out & resolve these issues, and lots of helpful people who I'm sure will post. I would write more now but I'm short on time (its midnight & there's still work to be done).

Good luck don't give up!

are you trying to add or change the asio modules while cubase is open? that won't work.

the asio modules and sequencer midi modules are the jacks on the object that is cubase(cubase is a virtual recorder) in the scope world. when cubase opens, it checks scope to see what drivers are in the routing window, and how many channels are available and then configures itself. asio modules with the desired number of channels and sequencer midi source/dest modules must be set before opening cubase. you can connect and disconnect from those modules as much as you like anytime, but you can't remove them while cubase is open windows will freeze.

1. hardware probelm. try cleaning the card contacts with 99% or more pure alchohol. try a new s/tdm cable if that doesn't help. astro's post has good info.

2. latency is set in scope. who cares what cubase says. it's just info that you can't use(the program uses it though).

3. not an issue. see point #4

4. the "test" is a test of the wave drivers. it's useless but cubase isn't happy until you do it. put 24bit wave source and dest modules in your project and open cubase and then run the test. of course you have to have a stable samplerate first. what are you slaving the clock to? afaik when using z-link, scope must be master and the a16 must be slave! is this the source of your clicks?

And give us a printout of your irq allocations.

From my experience a reboot applies in such cases and not just a re-load (better safe than sorry - workflow is interupted anyway)

- done loads of reboots - ocational the system worKs a small session before the Cpu spikes starts again..

If you touch the STDM connector and it changes sync, that does not necessarily mean the connection itself is the culprit - it might trigger an kind of 'small reset' of the communication, which picks up clock again.

- That sounds right - cos I have had samplerate lock problems (which now is defined as a sync problem by U guys - Thanks!!) when only using the Pulsar II board as well - really from day one... I use Pulsar as Master by the way.

On the other hand that cable is a known source of trouble ....

The cable is a bit to long for my two cards, so it curves between them. Got Pulsar in slot 1 and Luna in last slot. (Yes I know the saying of not putting it in Slot 1 because of AGP sharing - but are people really sure about this? or is it only a saying related to some motherboards - It's the only two slots I can use to let the boards share IRQ with eachother only - any way. I have disabled AGP tp PCI in bios and in Matrox settings...so this should not be a problem.)

Not that I want you to do the same - this is just for illustration - (!)
I've cutoff the cable directly behind the mid connector, carefully removed the plug (the plastic parts are a bit sensible, one has to bend them with a tiny screwdriver to get the locks open) and placed it right between the 2 remaining connectors.

YES! will do the same at one point. Do you mean that u only use two connectors , first and middle one and cut away the third?

Is Scope sync master or an external device ?

SYnc master

Are your cable whips (in case you use them) in good condition ? Some people had sync problems with short circuits in side the whip's connector.
It's easy to open and to inspect.

Do not use Whip at the moment - but will check when using..

If all physical conditions are met, then I'd use the system over some time without Cubase and Asio, and check for clock issues - it might overheat for example

But it's strange that the issue starts right away when ther shouldnt be time for overheating....

If all is stable then I'd setup a fresh project with Asio and try a simple host like Energy XT or Reaper or whatever not very demanding.

I have tied without any stuff other than i asio dest/source and the DPC's and IrQ's start working a bit more then it should..... (therefor bubbling cpu when loading cubase)

cheers, Tom

Thanks a lot TOM!!!!

So It' looks like a sync issue which needs resolving...... But the bubbling CPU/spikes is also happening when the sync is in place and wverything looks fine...?! But maybe I should concentrate on the the sync issue for now.....

Endre70

valis wrote:if ASIO is causing a high number of interrupts, this is exactly what it should be doing (interrupts mean that data is being sent back & forth to the soundcard, and a low latency setting means that you'll have tons of interrupt calls). If you're seeing cpu issues as a result, that means there is a conflict somewhere, most likely a shared irq or something (like a graphics card) that isn't happy sharing the PCI bus's bandwidth.

There's tons of info on these forums to figure out & resolve these issues, and lots of helpful people who I'm sure will post. I would write more now but I'm short on time (its midnight & there's still work to be done).

Good luck don't give up!

But it shouldnt send interuots and DPC's!!! when not in use.. It's the asio drivers are just loaded not in use. Ok the word clock/sync will ofcourse send time code though...

No IRQ conflicts at the moment...

PCI bandwith issue... I have turned PCi steering of in bios and in software. Accelration to a minnimum,

Looking forward to more coments.

Thanks Vallis!!

Endre70

garyb wrote:are you trying to add or change the asio modules while cubase is open? that won't work.

the asio modules and sequencer midi modules are the jacks on the object that is cubase(cubase is a virtual recorder) in the scope world. when cubase opens, it checks scope to see what drivers are in the routing window, and how many channels are available and then configures itself. asio modules with the desired number of channels and sequencer midi source/dest modules must be set before opening cubase. you can connect and disconnect from those modules as much as you like anytime, but you can't remove them while cubase is open windows will freeze.

1. hardware probelm. try cleaning the card contacts with 99% or more pure alchohol. try a new s/tdm cable if that doesn't help. astro's post has good info.

2. latency is set in scope. who cares what cubase says. it's just info that you can't use(the program uses it though).

3. not an issue. see point #4

4. the "test" is a test of the wave drivers. it's useless but cubase isn't happy until you do it. put 24bit wave source and dest modules in your project and open cubase and then run the test. of course you have to have a stable samplerate first. what are you slaving the clock to? afaik when using z-link, scope must be master and the a16 must be slave! is this the source of your clicks?

I have tried both ways regarding loading asio drivers whle cubase is running and before running cubase. In the first scenario Cubase dos not freezw when fiddling around in Scope.. Just reload scope in Cubase VST setup and the new settings take place.

re 1) Yes I have cleaned board and cables ...

re2) Cubase did not have this issue prior to cpu spikes... so it might be connected..?

re 4) Just did what you said and after checking buffer sync test was ok, Thanks !!! but still no difference in CPU spikes/bubbles.. And still difference in latency reading for inn/out in Cubase..

As for Master and A16ultra. Scope is master and A16 syncs to z-link (therefore Scope)

Keep em coming if you like!

Thanks Garyb!!

Endre70

bassdude wrote:And give us a printout of your irq allocations.

Should be no conflicts, check pdf. It's in Norwegiann but U should get the general idea...

Endre70

...Do you mean that u only use two connectors , first and middle one and cut away the third?...

since you have to use the outer connectors (otherwise it's not terminated and runs amok) I once shortened the cable right at the middle plug because it didn't fit in my case.
When I got a 3rd card later, I pressed the remaining connector (which I had kept of course) between the other ones.

cheers, Tom

Update.... I have updated to scope 4.5 drivers (not software) and disabled onbord lan ... Sync lock working ate the momen ( due to Lan off) and CPU spikes/bubbles is currently away after new 4.5 drivers in 4.0 software. Reloding original 4.0 drivers from CD did not change anything)...!!!!!!!!!!!!!!!!!!!!!!!!!

I will monitor the system closely and report changes. But for now I can do my job!!!!!!!!!!

Seems your old drivers were corrupted, cos I've heard, the 4.0 and 4.5 drivers are identical ones. V 4.5 has some additional software.
Nevertheless, have fun with your running Scope system!

Sounds like asio to me.Have you looked in the asio multimedia setup,are the buffer sizes set to 5292,do you lose buffers during the sync simulation ?

No sync loss now. But sync problems when starting scope again this morning.... Again.... arrrrghh what to do to get it locked at once..?

endre70

OK latest update.....

The sync problem is a Hardware problem!!! Tried all tunings/tricks and also cleaning connectors/pci slot etc but it comes down to hardware failure.

Talked to Ralf and he mentioned that on some motherboards the pci slot is a bit to wide for the card. This is not hte case for my ASUSp4p800.

Tried another Pulsar II in my machine and this works fine, tried my Pulsar in another machine...sync problems.

Tuching the card a bit (while running, and earthed to chassie) the sync lights flickers and it goes back into sync.

This can only be: broken circuit, something wrong with a capacitor, other hardware issues..

So the card is beeing shipped to Germany as soon as I get the ref number from Ralf .....


Endre70

yep, sounds right...

endre70 wrote:...The sync problem is a Hardware problem!!! Tried all tunings/tricks and also cleaning connectors/pci slot etc but it comes down to hardware failure. ...
This can only be: broken circuit, something wrong with a capacitor, other hardware issues...

my 3rd card seems to be a similiar candidate, as the last item in the PCI chain it works as supposed - with only the 'main' card the clockrate drops out every 15 seconds or so. If I replace this card, sync is stable.
I got it for 50 bucks as 'no software/untested/possibly damaged', so I'm not at all surprised - as #3 DSP extender it works
if I find a suspective part that you could easily identify, I'll write back

cheers, Tom

So then you know what pain is .

Have you tried tuching/wiggeling (dont know if thats a proper english word but what the hell...) the card while runnig scope? Good luck to you and please report your findings.....

Endre

my post above post may have drawn a slightly distorted picture ...
There are few complaints from my side - I've had a stable system with 2 Pulsar Ones, then I bought that 'supposed to be broken' 3rd Pulsar for a bargain.
Of course I was happy that I could just add it and had some additional DSPs.
That system never ran out of sync, it's on a 1.2 Tualatin Asus TUSL2.

For testing purposes I sometimes remove the cards and plug them into something else - in this case an old HP workstation with dual P3.
I didn't dare to add the third card as it would end only 2 millimeters from the heatsinks of the HP 3D card, which is passively 'cooled' and hot as hell...

That's how I found out that under certain conditions (this is a dual CPU server board) the 'last' Pulsar has some trouble - possibly the previous owner had a dualcore machine, too - I don't know if the card reacts the same in the Asus board, it's 'regular' home, it might be more tolerant...

The area around some capacitors on the circuit board does look suspective indeed, so I thought I'd replace them and see if it improves things.
I ran out of parts yesterday and only replaced 4, it seems to have an infkuence as it seems to take longer for the dropout to appear and quicker to recover.
One should always measure and write such findings down... stupid me.

But the board is a bitch to (de)solder - it's extremely sensitive
... and yes, now I should know about pain, but there's this Hoyer 335 copy with the slightly high action and it's steel strings torturing my fingertips...

[later]
replacing the caps didn't change anything
moving the Pulsars back to the Asus all sync is stable and rocksolid.

nevertheless it was quite interesting, as on the dual cpu HP (under win2k server) SFP 'forgot' about the registration a couple of times when removing and adding a board.
Pointed it to the keyfile and the imported succeeded - rebooting etc didn't change a thing, but when one of the boards was exchanged the request was up again - strange, as the Pulsar related to the keys was (of course) never removed
I don't have a clue because the respective system was tested once with 2 Pulsars and worked, but since it's PCI performance was rather disappointing I SFP got it's dedicated Asus TUSL (leaving the SFP installation on the HP)
[/later]

cheers, Tom