Scope PCI cards Sync Source lights blinking -> audio dropouts

[rodos1979]

Hello to all!

Old user from the past here.. (wow it's been 17 years :S )

Two Pulsar2 cards in a DAW machine from 2010, running Scope 7 in Windows 7 x64.

My Pulsar cards work fine and I can use the lowest ULLI with no problem but occasionally I have clicks and pops even when listening to an mp3 in media player. The machine is DAW optimized and runs RME Babyface at a buffer of 64 without any issues.

While trying to understand what might be the problem, I paid attention that whenever I had an audio dropout the Sync Source lights in the Samplerate Settings Window blinked as if I connected something to the SPDIF or the ADAT (I have nothing connected).

Sometimes lights insist blinking and the cards are unusable. But if I disconnect the cables-thing (sorry, can't remember now how it is called :S) and reconnect it the issue gets fixed.
What might be wrong? Somewhere I had read that this might be caused by a faulty STDM cable. Could it be? I want to try fixing it with all easy things first, before considering something more drastical. If the STDM cable may be the cause, then where do I find a new one?

Thanks!

[valis]

Cable-whip

Try getting some De-oxit 5% and spraying that both into the connector and the end of the Cable-whip to get rid of oxidation/grime and see if that improves the matter. To be more thorough, you can start with a bit of De-Oxit 100% to clean and then 5% solution (which is 95% oil) to 'keep it clean' (sealant). I order both from amazon and/or directly from CAIG who makes De-Oxit.

[rodos1979]

Thank you valis!

Cable-whip! Ah yes! .. Is WD-40 good for this job or I need De-oxit? I have LOGO 100 as well, which is an anti-rust spray made in USA but sold under this name in Greece.

BTW, today I saw this:



Any idea what this error could mean? I hope my cards are not dying...

[t_tangent]

If you are talking about this type of WD40 then it looks like it would work ok.

https://www.walmart.com/ip/WD-40-Specia ... 3=&veh=sem

Other options, such as that which Valis recommended should work as well. I also use DeOxit for some purposes. You could also try cleaning the gold connectors on the Pulsar card that the STDM connects to, and also the connectors on the other side that fit into the PCI slots. For those you could try as above or Isopropyl Alcohol and a cotton bud, and I have seen some tech reports that using a pencil erasor works on those gold traces, but gently does it.

Re your System Error, I also get a similar timeout error on one of my PCI cards from time to time, but cant remember if its exactly the same message, its been like that for years, but it only happens when I reboot sometimes, and so seldomly that a quick reboot and the card works fine again so I never worried about it.

Hope you manage to get it sorted. Bearing in mind the age of these PCI cards now, it could even be a capacitor or a cold solder joint that is causing the issue, but I wouldnt worry about those until you have tried the above possible solutions.

[garyb]

plain contact cleaner. no regular WD40, EVER!

the WD40 Specialist product contains no WD40. it is Diflouroethane, Hexane and Alcohol which are the usual kinds of ingredients in contact cleaner.

[rodos1979]

I have just cleaned thoroughly everything with alcohol and sprayed contact cleaner to all the contacts (STDM cables, contacts on the pci cards, cable whip connector). Cards now look almost as new! I'll just have now to wait a few days and see if the problem is gone...

On a side note.. What is Async? Is this reading normal? :


It's 14.3 as a floating number or 2 as an integer for 1/1 . And why does it change when I press the two-green-circle-button? What does the button do?

Thanks!

[valis]

That shows %'s instead of fixed numbers. A rough guide is: Sync=fixed DSP resources, ASync is dsp code that also relies on the host machine, and may correlate to increased PCI bus traffic which is where the system sometimes bottlenecks first. Hence why it's good to watch each.

Ie, when you are nearing high usage on all dsps devices will straddle more dsp's and so phase coherence can be an issue with certain tasks, and when you reach a high Async count with devices that use delay lines and such you can stress the PCI bus and get bandwidth related errors on lesser performing machines. I'm sure Gary can clarify further if I'm off on any point.

[garyb]

i hope that you used 99% pure alcohol and not rubbing alcohol. 70-80% rubbing alcohol contains a lot of water and will leave a film...

[rodos1979]

Thanks valis!

Gary, yes I used 99% pure alcohol.

After some days of usage I can say that the blinking problem has not appeared .. but I do still get some occasional dropouts.. Since this machine is built as a DAW (with DPC latency around 100μs) and never had any problem with my RME cards, and since my Scope cards seem to work fine, I guess that there must be some incompatibility with the Scope cards in this system.

After googling around I found that my motherboard (Gigabyte EX58-UD5 - which has two PCI slots) shares the IRQ of the first slot with the video card.


So, I'll try to remove the Scope XTC which is seating on the first PCI slot and see if I still get occasional dropouts. If not, then I'll keep the Pulsar2 and, unfortunately, I will have to sell the XTC.

[valis]

Depending on your motherboard, and what the BIOS or EFI implementation is, there are various ways to handle how IRQs get allocated. I might suggest investigating this line of inquiry before resorting to more drastic measures.

[rodos1979]

Unfortunately there is no way to set manually the IRQs in the BIOS. I found another thread somewhere in the internet with another Scope user having the same problem with the same motherboard. He solved it by changing the motherboard (after having first contacted Gigabyte and having a custom BIOS built for him)..

[garyb]

the video card should not make a problem.

the usb controller, however...

[rodos1979]

If I disable it, all usb ports will stop functioning? No mouse, no keyboard?..

[garyb]

no, only the port controlled by that controller will stop working. there are tons of usb ports on the motherboard and you can always use a hub.

[valis]

Actually I think that's a JMicron JMB36X SATA/PATA controller, which gives extra SATA & Parallel ATA ports. And gary is correct, any drives connected to those ports that are used while using scope will likely have issues as JMicron often has substandard drivers.

Btw, can you provide the make, model # and revision of your motherboard? If you provided that information, we can help you further.

[rodos1979]

I disabled that USB controller, as I never use the ports that it controlled anyway.. I tried disabling the JMicron controller too but this disables the e-SATA ports that I use for my external drives. I could disable it though any time I use Scope (if it is proved that this would help the performance of Scope) and enable it when not using it.
I will test with these two things disabled and see if performance of Scope improves.

My motherboard is Gigabyte EX58-UD5 rev. 1.0 running BIOS version F13.

[garyb]

i haven't had any problems with SATA controllers, but USB is a killer.

did you do the usual required bios changes(turn off hyperthreading, turbo, and most of all, EIST, Enhanced Intel Speedstep Technology)?

[t_tangent]

It might be worth checking your latency settings too. Do you have Scope set to minimum ULLI settings and if so try increasing them a little to see if the audio clicks disappear. Also try the DPC latency monitor to check if your system is running within its recommended settings

[valis]

Here's a link to the English (American download) Manual (10.1 MB). Sadly I see nothing in it in regards to slot sharing or the BIOS's ability to control how resources are allocated.

I did see mention of "GIGABYTE Dynamic Energy Saver" software, make sure you're not using this in your Windows installation. Such things tend to cause nasty DPC spikes and tune the CPU to states that are not optimal for audio usages.

Gary mentions EIST etc, you will find mention of how to set these states in the manual above. Gary knows what he's talking about, though I haven't had to disable USB ports on an Intel machine in some time. He may be correct there too...

I *do* see the JMicron controller sharing with your Pulsar2 on IRQ 17, and of course, the Pulsar2 sharing with the GPU on IRQ 16.

[rodos1979]

After some days of having disabled USB and eSATA controllers, I still do get occasional dropouts. So, the dropouts are not caused by the IRQ sharing with these devices I assume.

I must say (If I haven't already) that this machine is a DAW built for music by Scan 3XS (UK) and works perfectly with my RME audio card with no dropouts whatsoever at the lowest ASIO buffer. All bios settings are optimally set by Scan for DAW use and the dpc latency of the machine is excellent.



This is why I thought that the dropouts were caused by the Sync Source blinking lights, which were caused by dirty connections. The blinking lights problem is fixed by the cleaning of the cards and the connections. Since the day I cleaned the cards, I had no dropouts caused by lost Sync and no blinking lights.

But I still have occasional dropouts, even when I listen to music using the Windows Media Player or Youtube. Which makes me think that either
1) the STDM cable may have become faulty for some reason, or
2) one or both of the cards may have started to develop a problem, or
3) the motherboard of this machine does not like Scope pci cards, or
4) the motherboard cannot handle two Scope pci cards

I tend to believe it is number 4.. I will take out the XTC card I have and see if the machine behaves well with just the Pulsar2..