PlanetZ forums - scopeusers.com

I'm running windows 7 32 bit and I'm having similar problems with recording into ASIO. I had what seemed to be stable ASIO just a short while ago, but lately I bought some new devices and I've been having trouble since. I was having lots of clicking problems with larger projects (small projects worked ok) which was mostly resolved by disabling all the onboard USB systems and using a USB on PCI-e for my dongles etc. That eliminated some IRQ conficts. While the clicking is reduced, it is still there intermittently, and is of the variety like the image shared above where the sync is lost.

I know it is not a problem with my audio interface as it is turning up in RdDrum. I'm uncertain wether the issue comes from RDdrum itself.

The only way I've been able to record clean audio is using VDAT, and that has its own issues in 5.1.

I've got a 3xPCI system. I'm wondering if it might help to go back to 4.5. I wish my windows XP computer hadn't died (motherboard blew out). Or that I could still manage to install XP today, but microsoft won't authorize. I've made a second partition and plan to intall 4.5 there in XP mode under windows 7.

hi, jksuperstar! it seems that that is particularly loss of part of sinewave, the sync is internal.

gruebleengourd, i don't think that it's a problem of Scope 5.1, as far as I remember Scope always had a 'sensitive' driver, just on the older computers it was less shit going on concurrently, so if you calm everything down and leave Scope more or less alone, it works fine.

I have tried every combination of suggested 'scope tweaks' like disabling, degrading, crippling something, like less cores, no speedstep, less devices but in the end i observed that in my system it doesn't change anything (but degrade performance for other tasks).
I've been able to get 10 hours of glitchless recordings with 4ms buffer, but I had to tune daw's process priority and make sure no p2p or browsers are running along. windows somehow doesn't care too much about priorities, you can still choke higher priority processes with lower priority power hungry tasks. I have a lot of hardware in this system, but it all plays along well. Although Lynx shares IRQ with SCSI, it's quite more click-impermeable even without priority tweaks. Somehow I think that Scope driver revision could make things better. IRQ conflict is when thing doesn't work at all, but in our clicky cases it's just device getting attention too late. Why Lynx with same buffer is happy and Scope is not? By the way, when I don't have clicks, I don't have them at any buffer setting. When I do, even largest doesn't help. What I also noticed, that even software doesn't know about those clicks. DAWs have an indicator of lost buffers. For other cards, if they click, the counter turns red and indicate lost buffers. For scope, it does only sometimes, only with 'specific' clicks which are rare. My theory is that this buffer loss occurs somewhere aside ASIO, how to say. Before it, maybe. As I understand, Scope has to run it's own OS and that OS presents ASIO ports to applications, and you can draw as many ASIO channels as you wish. Within that Scope OS everything works fine, so that's why VDAT never drops out. it's between Scope and ASIO, between Scope and wave driver it presents to a system, that's the place where it doesn't get enough priority and something nasty happens. Developers should see this post and comment on it
And by the way, I have no problems with VDAT under x64. Just make sure there's no April ..355 update installed.

IRQ 0 System timer OK
IRQ 1 Standard PS/2 Keyboard OK
IRQ 3 Communications Port (COM2) OK
IRQ 4 Communications Port (COM1) OK
IRQ 5 Printer Port (LPT1) OK
IRQ 8 System CMOS/real time clock OK
IRQ 10 Intel(R) 8 Series/C220 Series SMBus Controller - 8C22 OK
IRQ 10 Intel(R) 8 Series/C220 Series Thermal - 8C24 OK
IRQ 13 Numeric data processor OK
IRQ 17 PCI standard PCI Express to PCI/PCI-X Bridge OK
IRQ 17 Texas Instruments 1394 OHCI Compliant Host Controller OK
IRQ 20 PCI standard PCI Express to PCI/PCI-X Bridge OK
IRQ 20 Adaptec SCSI Card 39320A - Ultra320 SCSI OK
IRQ 21 Lynx AES16 OK
IRQ 21 Adaptec SCSI Card 39320A - Ultra320 SCSI OK
IRQ 21 Intel(R) 8 Series/C220 Series USB EHCI #2 - 8C2D OK
IRQ 21 Intel(R) 8 Series/C220 Series USB EHCI #1 - 8C26 OK
IRQ 21 Intel(R) Active Management Technology - SOL (COM3) OK
IRQ 22 PowerCore/Classic OK
IRQ 23 Sonic Core Scope OK
IRQ 4294967281 Intel(R) USB 3.0 eXtensible Host Controller - 0100 (Microsoft) OK
IRQ 4294967282 Intel(R) HD Graphics 4600 OK
IRQ 4294967283 Intel(R) Management Engine Interface OK
IRQ 4294967284 Intel(R) Ethernet Connection I217-LM OK
IRQ 4294967285 Intel(R) I210 Gigabit Network Connection OK
IRQ 4294967286 Intel(R) I210 Gigabit Network Connection OK
IRQ 4294967287 Intel(R) I210 Gigabit Network Connection OK
IRQ 4294967288 Intel(R) I210 Gigabit Network Connection OK
IRQ 4294967289 Intel(R) I210 Gigabit Network Connection OK
IRQ 4294967290 Intel(R) I210 Gigabit Network Connection OK
IRQ 4294967291 Intel(R) 8 Series/C220 Series PCI Express Root Port #3 - 8C14 OK
IRQ 4294967292 Intel(R) 8 Series/C220 Series PCI Express Root Port #2 - 8C12 OK
IRQ 4294967293 Intel(R) 8 Series/C220 Series PCI Express Root Port #1 - 8C10 OK
IRQ 4294967294 Intel(R) Desktop/Workstation/Server Express Chipset SATA RAID Controller OK

What software are you using with ASIO? Some are more successful than others.

Scope cards work in realtime doing many processes concurrently.

the PC does one task at a time(that's what interrupts are about). if you load the machine up with tasks, it WILL fall behind the audio stream and that sounds like clicks and pops(dropouts).

this isn't about the driver.

Hmm, but what's scope doing in this scenario is pumping some 2Mbit per second over 1000 Mbit/s capable PCI bus through ASIO to a software application that is doing recording and drawing some meters, what takes only 0,1% cpu and this tandem still fails even there are plenty of free resources around... it seems like taking precedence over Scope software (driver or something) is like taking candy from a baby.

I've checked DPCs and ISRs and nothing is misbehaving too much. At least Lynx card doesn't feel offended by that. Actually scscope.sys is among top three latency causers. If scope's wave drivers are plagued by random clicks, that might be the same root of a problem, although smaller, for ASIO too. I'll play with process priorities some more and too bad I can't write drivers I'd like to find a solution, and it's possible as other drivers performance shows.

TIMING.

if the stream is realtime, and the computer is not, timing is crucial. theoretical bandwidth means nothing if it's not available in a timely fashion. anything that ties up any part of the chain for even a brief moment longer than expected and you have lost data, which sounds like a click or pop.

it's not the driver.

yes, Gary, exactly that, timing! But to cover up for that, we have buffers - the card can hold something in its pouch until the bucket arrives and takes what's in that pouch. But in our scenario, no matter how big a pouch (ulli setting), sometimes its contents is lost, even though asio software doesn't know it (doesn't display lost buffers). And the neigbouring card (Lynx) live in the same environment and somehow makes it through..and even when it looses, asio knows it and you have a dropout marker and a click. With Scope you mostly don't have an indication from software, so that's why I suspect a bug somewhere there.

the card cannot hold anything in it's pouch. it doesn't work that way.

the card is a separate computer that only operates in the now. it's not a soundcard. a soundcard is controlled by the ASIO app when using ASIO. go ahead and try to set up Scope in the ASIO app. the Scope driver merely present the data stream and receives the data stream, but the computer has absolutely no idea what is happening inside the card. with the Lynx card, the computer knows exactly what is happening inside the card. that's the difference. Windows doesn't speak DSP.

Well, Scope ASIO setup presents itself with some routing selections and latency setting panel. So there are buffers somewhere, how to say 'pouch'. If not in hardware, then in software: 64, 128, 256, 512, 1024 samples.
And yet for some random clicks even highest setting doesn't help. But VDAT in Scope is always click-free, Lynx AES16 on the same bus is click-free, so it's definitely ASIO implementation in Scope driver. And those wave drivers that are always clicky and have no working input... So we'd benefit from an updated driver.. Developers should look at it, maybe it's an easily fixable bug. If VDAT never chokes, it means it's somehow possible.

ok, you know best.....

no, there is no ASIO control panel.

VDAT is entirely inside Scope. only the VDAT storage is outside Scope.
the buffers don't work like you think.

the wave driver for 64bit DOES need an update.

the ASIO driver does NOT need an update to be click-free. you need to make your computer comply, not the other way around. SCOPE IS EXTERNAL HARDWARE even if the card is in the PC's slot. the Scope program is merely a GUI.

the Lynx card does not operate in the same manner as the Scope card. it's a soundcard under complete control of the Windows app. the Scope card requires the system to cooperate. the Lynx card is forced to cooperate with the PC. the Lynx card is NOT a realtime device.

A need for new drivers is not the case because both the Asio and Wave drivers ARE NEW Drivers in 5.1 software. IIRC the 64bit O/S Wave driver clicking happened at around release time and wasn't present at first. I think it is a strange bug that crept in and Sonic Core wasn't aware of it until after they released the software, but Wave drivers worked fine at first. The Asio should be fine tho. Both Asio and Wave are new drivers and it states this in the web shop in the description of 5.1 software here - http://www.sonic-core.net/shop/product_ ... grade.html

The new drivers was one of the reasons I could tell that XITE-1 and older PCI cards are not completely compatible and that Sonic Core was coding for two Platforms rather than just one as expected. The drivers were ready for pci first but it took awhile longer for them to be ready for XITE-1. If the two systems allowed for complete software compatibility the drivers for both systems would've been finished at the same time. I'm sure Sonic Core got hit with quite a few surprises that showed them the job would be a lot more difficult than expected since they essentially were coding for two platforms instead of one.


EDITED

Yea, garyb, ASIO Scope is working fine when the rest is fine. I've been able to detect a culprit - it's the intel lan driver that upsets Scope and Lynx too, to a bit lesser degree. Got an old version of the driver (proset 19.1) and it's better.

Sounddesigner, do you still have that old 'beta?' driver of Scope 5.1 somewhere? Of course i don't need them to be 'new', but i want them to work and now wave out is clicky and wave in is nonworking, both on pci and xite...

What's also strange is that on a website they state (Please note: No STS and no XTC mode available when running on 64bit Windows), cause for me they do work fine...

pranza wrote:Yea, garyb, ASIO Scope is working fine when the rest is fine. I've been able to detect a culprit - it's the intel lan driver that upsets Scope and Lynx too, to a bit lesser degree. Got an old version of the driver (proset 19.1) and it's better.

Sounddesigner, do you still have that old 'beta?' driver of Scope 5.1 somewhere? Of course i don't need them to be 'new', but i want them to work and now wave out is clicky and wave in is nonworking, both on pci and xite...

What's also strange is that on a website they state (Please note: No STS and no XTC mode available when running on 64bit Windows), cause for me they do work fine...

Oh I never had a beta. I was saying the Wave drivers were working for Sonic Core prior to release.

Glad to see your system working better now. Yea, rogue drivers especially internet stuff is often the culprit countering low-latency and causing pops/clicks/whatever. The dpc latency checker can usually detect rogue drivers, I don't know if you tried it? Can help you in the process-of-elimination.

The samplers and XTC mode should not be working in x64bit Windows, if you got them working that is odd and pretty much a miracle. Your system is the exception to the rule no doubt. Always great to have more options so you have a blessing. The Wave driver bug is the main reason that's SCOPE related that I probably never will go to a X64bit O/S system. Wave drivers increase the flexibility of SCOPE dramatically. Plus I have quite a few Native VST's that are 32bit only so 64bit makes no sense to me. Many developers (such as Cakewalk, XLN Audio, etc) don't handle 32bit all that great on my system so why trust them with X64bit is my question? X64bit to me smells like more strange bugs, more limited functionality, and less plugins in my arsenal that I can use in it. I'll stay on 32 bit O/S till truly forced to go x64bit. Some companies are trying to force consumers to go x64bit cause they no longer sell x32 bit versions for some of their plugins such as Propellerheads with Reason and IK Multimedia with Amplitube 4 and Sampletank but I simply stop upgrading those products wich is no problem since I have more than enough SCOPE and Native plugins to get the job done. SCOPE prevents me from desparately buying products from developers trying to twist my arm to get me to take on undesired things such as X64 plugins, dongles, and overpriced plugins. Due to SCOPE i can be extremely picky now with purchases and rarely make them now so developers can't twist my arm into anything undesirable anymore.

Yep, 64 bit is not the best for Scope, but I have minimal issues. My major problem is that I have too many Scope devices and not enough time to have fun with them. It's really sad, I haven't even installed all of the Zarg stuff I have keys for

Oh, everything I have is pretty much 64 bit and has been for a long time. This MacBook is almost 4 years old and it's got 64 bit and 16GB RAM... It's good for email, browsing, iMessage, and SSHing to servers. But this is not my Scope machine.

-Tom

Sounddesigner wrote: I'll stay on 32 bit O/S till truly forced to go x64bit. Some companies are trying to force consumers to go x64bit cause they no longer sell x32 bit versions for some of their plugins such as Propellerheads with Reason and IK Multimedia with Amplitube 4 and Sampletank but I simply stop upgrading those products wich is no problem since I have more than enough SCOPE and Native plugins to get the job done. SCOPE prevents me from desparately buying products from developers trying to twist my arm to get me to take on undesired things such as X64 plugins, dongles, and overpriced plugins. Due to SCOPE i can be extremely picky now with purchases and rarely make them now so developers can't twist my arm into anything undesirable anymore.

Great post !

I do the same,- didn´t upgrade since Phead Reason 6.5, so I can stay w/ Win XP 32Bit and SCOPE 5.1 32Bit as well.
There are tons of native plugins I rarely use on my machines and this also includes NI Komplete 7.
I hate I cannot upgrade Kontakt though,- but OTOH it´s not the end of the world at all, since I own a lot of hardware keyboards, synths and MIDI modules in addition.
My most powerfull PCs are Gigabyte socket 775, Intel Core2Quad Q6600 (2.4GHz) and socket 775 ASUS, Intel Pentium D 945 dual core 3.4GHz, both machines Win XP SP3, 4GB RAM while both can run XITE-1 and/or CW 15DSP PCI card.
Both also run all the native software I own.
I own 2 pairs (1 spare) of good Tannoy passive coax monitors and a pro Bryston3B amp together w/ passive volume control, XITE-1 and PCI 15DSP.
It sounds great and 64Bit won´t sound better.

Before I invest more money in new computer hardware and native software upgrades, OS included, I´ll squeeze the best out of what I already have and before doing a switch,- then losing plugins and have the "setup all new nitemare" in addition.
I´m probably willing to buy a then cheapo copy of Win7 32/64Bit when SCOPE 6 arrives, just because that will be what it needs,- but until that day will come, I´ll work w/ what I already have and save money.

Bud

pranza wrote:I've been able to detect a culprit - it's the intel lan driver that upsets Scope and Lynx too, to a bit lesser degree.

I disabled my motherboards Intel LAN device in the Device Manager and it seems like that may have fixed things here too. no glitches last night

hmm, I don't know what Ethernet chipset I have, but I can have Sonar running / playing and watching youtube videos just fine...

-Tom

shared irq?

possibly a shared IRQ. I never changed any of mine...

I will max out the CPU, before the ASIO breaks down on the lowest latency... with 32 stereo tracks...

-Tom

For those who are using foobar with wav drivers and have some clicks when listening, i managed to get rid of them by using wasapi, which can be downloaded on foobar website.
And the sound is better. But then you can't use 2 software using wav driver in the same time.

Hmm,

I've never even heard of Foobar. Just checked it out.

BTW, Winamp still works fine on Windows x64. And I think Winamp has plugins for MOD/S3M files and other trackers. There's even an Adlib S3M plugin. But my 20+ year old files don't sound quite right.

-Tom