Hi
I would consider myself reasonably seasoned in the idiosyncrasies of the scope drivers but I've hit a brick wall with PT11.
My setup:
i7 3930k/32GB GSkill/2011 chipset
Asrock x79 extreme6 (not OC'd, all C states off, no HT, no turbo or speedstep or VT)
VirtuVia PCIe to PCIx4 external expansion with 550w ATX PSU
Windows 8 pro 64bit, Scope 5.1 64bit
Scope Pro 14dsp NFR(2002) w/24 ADAT, Scope Project 6DSP (2003) w/24 ADAT, Sync plate) in VV
Currently HPET is on w/dynamic tick disabled, previously had dynamic tick unchanged (enabled)
Dedicated word clock distributor with all ADAT i/o utilized. All sound cards run from WC from the master clock.
Performance:
9x masterverbs. Previously when cards were on the MB 4x masterverbs
Changing the host board number in cset.ini makes no difference since I've been in Win8 pro 64bit. Anybody else manage to get it to change? Please give your syntax.
Other DAWs such as Ableton Live 64bit, Reaper 64bit, Fruityloops and PT10 are able to get ULLI down to 4ms@48khz with the odd crackle (fine for writing, not mixing)
Scope Driver Bugs:
Common to all DAWs, motherboards and OSs is bad stability: It doesnt take much to crash the ASIO driver, the DAW can NEVER call the wrong sample rate or try to change it without crashing asio, often the clock source needs jigging around to bring all adat inputs into sync thus its not practical to be changing from 44.1 to 48k, WAVE drivers flakey mostly unusable. If the ulli is to low it will often freeze the DAW and crash the asio. When asio crashes you have to restart scope. I WISH that Scope 6 drivers will be improved but I'm not holding my breath given the history.
With PT11HD it will crash upon loading with any ULLI setting other than the biggest ie 23ms@48khz which is not alright for VIs and writing. I'm using ASIO 32 source 64.
Has anyone else had better luck with PT11?
What asio driver modules, what ulli and clock source etc
Regards
Ben
Scope 5.1 64bit and Protools 11HD problems
Scope 5.1 64bit and Protools 11HD problems
Last edited by bcslaam on Sun Aug 11, 2013 12:28 am, edited 3 times in total.
Re: Scope 5.1 64bit and Protools 11HD problems
Ben, your instability is not a driver issue. i'm not sure what's up with ProTools on your machine, but PT is fine with Scope afaik.
pm me. we'll figure it out.
pm me. we'll figure it out.
Re: Scope 5.1 64bit and Protools 11HD problems
Just tried my RME fireface 800 in same machine and it works perfectly in PT11 at 64samples. Still points to driver IMO,
PMed you Gary, please note that I also said above PT10 works fine with scope. Have you had experience with PT11?
PMed you Gary, please note that I also said above PT10 works fine with scope. Have you had experience with PT11?
Re: Scope 5.1 64bit and Protools 11HD problems
no.
not one other complaint, either...
are you changing sample rates with the host open?
that's not instability, that should cause a crash.
the Scope card is not a sound card. it is a completely seperate piece of hardware that interfaces with windows through a VERY simple driver that presents the streams and receives the streams according the the standard ASIO protocol. if you change something like samplerate or ASIO type or number, the DSPs must be reloaded, communication with the host is interrupted and then you get a crash. again, this SHOULD happen.
some programmers have added extra features into their ASIO communications that are fine for windows sounds, which can be controlled by windows because a windows soundcard's environemnt is inside windows. the Scope environment is NOT inside windows, only the gui is in windows. windows has no idea what is inside the Scope environment, nor can it. this is part of what makes XTC mode troublesome. it's not a problem of a defect, however. it's a matter of perspective and purpose.
clock source is irrelevant to the driver. Scope tells the sequencer the clock and that's it. if the clock is steady, then it's steady.
ASIO driver type MIGHT be an issue, basically you have two choices.
1. 16/24/32bit integer which means ASIO Source or ASIO2 Source
2. 32bit floating point which means ASIO flt Source or ASIO2 flt Source.
you must match the appropriate Destination module, ASIO Dest for ASIO and ASIO2 Dest for ASIO2
that's it. i'd probably use the floating point ASIO2 modules with PT. of course, the proper pair must be in the routing window with the proper number of i/o before opening PT.
ULLI settings only matter to the CPU. it's just a measure of how much time the CPU has to make it's calculations, and the ASIO host affect this much more than Scope does. if you don't have absolutely 100% click-free operation at 3ms @ 44.1, then your computer is either set up improperly for the card, or you have hardware issues. the setup is easy, but it is important. Scope is a realtime system and the computer is not. if the CPU is allowed to throttle down to save energy, it won't be able to keep up with the cards.
i know there's a bunch of redundancy here, but there;s also either a misconception or something missed if you're having problems. please look at this again:
http://forums.planetz.com/viewtopic.php?f=3&t=31345
i don't have any of the described problems and i never have since Creamware days. i built a lot of systems and they all work right the first time, with the exception of a time with a bad stick of ram and a time with a bad power supply. i never built a socket 1155 machine, so i missed those issues.
the other possibility is that Avid has enabled a feature that made trouble with Wavelab. this feature aided in the automatic configuration of the soundcard, something that a Scope card cannot respond to. this caused Wavelab to hang. S|C sent a card to Steinberg and they made a registry hack that removed the feature. i doubt it would help PT, but here's the link to the reg hack from babaorum, the user who yelled at Steinberg so much that they fixed it:
https://dl.dropbox.com/u/3150024/AsioSc ... d_XITE.zip
not one other complaint, either...
are you changing sample rates with the host open?
that's not instability, that should cause a crash.
the Scope card is not a sound card. it is a completely seperate piece of hardware that interfaces with windows through a VERY simple driver that presents the streams and receives the streams according the the standard ASIO protocol. if you change something like samplerate or ASIO type or number, the DSPs must be reloaded, communication with the host is interrupted and then you get a crash. again, this SHOULD happen.
some programmers have added extra features into their ASIO communications that are fine for windows sounds, which can be controlled by windows because a windows soundcard's environemnt is inside windows. the Scope environment is NOT inside windows, only the gui is in windows. windows has no idea what is inside the Scope environment, nor can it. this is part of what makes XTC mode troublesome. it's not a problem of a defect, however. it's a matter of perspective and purpose.
clock source is irrelevant to the driver. Scope tells the sequencer the clock and that's it. if the clock is steady, then it's steady.
ASIO driver type MIGHT be an issue, basically you have two choices.
1. 16/24/32bit integer which means ASIO Source or ASIO2 Source
2. 32bit floating point which means ASIO flt Source or ASIO2 flt Source.
you must match the appropriate Destination module, ASIO Dest for ASIO and ASIO2 Dest for ASIO2
that's it. i'd probably use the floating point ASIO2 modules with PT. of course, the proper pair must be in the routing window with the proper number of i/o before opening PT.
ULLI settings only matter to the CPU. it's just a measure of how much time the CPU has to make it's calculations, and the ASIO host affect this much more than Scope does. if you don't have absolutely 100% click-free operation at 3ms @ 44.1, then your computer is either set up improperly for the card, or you have hardware issues. the setup is easy, but it is important. Scope is a realtime system and the computer is not. if the CPU is allowed to throttle down to save energy, it won't be able to keep up with the cards.
i know there's a bunch of redundancy here, but there;s also either a misconception or something missed if you're having problems. please look at this again:
http://forums.planetz.com/viewtopic.php?f=3&t=31345
i don't have any of the described problems and i never have since Creamware days. i built a lot of systems and they all work right the first time, with the exception of a time with a bad stick of ram and a time with a bad power supply. i never built a socket 1155 machine, so i missed those issues.
the other possibility is that Avid has enabled a feature that made trouble with Wavelab. this feature aided in the automatic configuration of the soundcard, something that a Scope card cannot respond to. this caused Wavelab to hang. S|C sent a card to Steinberg and they made a registry hack that removed the feature. i doubt it would help PT, but here's the link to the reg hack from babaorum, the user who yelled at Steinberg so much that they fixed it:
https://dl.dropbox.com/u/3150024/AsioSc ... d_XITE.zip
Re: Scope 5.1 64bit and Protools 11HD problems
hi gary
I always keep an eye on these issues and over the years ive tried everything youve suggested to others including the link you gave above. Nothing has given me 100% stability. I've never been able to run at the lowest ulli without issues.
Have I understood you correctly in that you say you should be able to run scope on its lowest setting or else there is setup issues. I always assumed its very common to not be able to run any sound card at its lowest setting trouble free.
PT11 apparently has a dual buffer feature which could be causing issues.
Regardless how is it that when I run PT11 with my FF800 at the lowest setting there is no issues.
I've built many pcs for my scope cards. With this one I rigorously tested with masterverb to get the best pcie slot to put the VV card in. It was a unanimous decision. Slot4 gave the best results (9) by over double the others. Before that I had the cards in the internal PCI slots and had poor performance (4)
These same overall stabilty issues have plagued me even back when it was a BX pentium setup.
It seems strange that I'm not able to change the host card in win8 pro 64 via the cset.ini. I was able to in other OSes. It keeps going to the scope card as the host. Thing is its older than my 6dsp card and I wanted to try that as host. Also back in the XP days I seem to recall my scope card coming up as 15dsp which would suggest its 1st gen. In my current setup however it comes up as 14dsp. And the date sticker is 21.06.02 which is supposed to be 2nd gen by a few months. Maybe its an "inbetween" board being a NFR. Or maybe its faulty.
I hope you dont mind me keeping this public I'm hoping it could help others who are trying to run PT11.01HD
Cheers
Ben
I always keep an eye on these issues and over the years ive tried everything youve suggested to others including the link you gave above. Nothing has given me 100% stability. I've never been able to run at the lowest ulli without issues.
Have I understood you correctly in that you say you should be able to run scope on its lowest setting or else there is setup issues. I always assumed its very common to not be able to run any sound card at its lowest setting trouble free.
PT11 apparently has a dual buffer feature which could be causing issues.
Regardless how is it that when I run PT11 with my FF800 at the lowest setting there is no issues.
I've built many pcs for my scope cards. With this one I rigorously tested with masterverb to get the best pcie slot to put the VV card in. It was a unanimous decision. Slot4 gave the best results (9) by over double the others. Before that I had the cards in the internal PCI slots and had poor performance (4)
These same overall stabilty issues have plagued me even back when it was a BX pentium setup.
It seems strange that I'm not able to change the host card in win8 pro 64 via the cset.ini. I was able to in other OSes. It keeps going to the scope card as the host. Thing is its older than my 6dsp card and I wanted to try that as host. Also back in the XP days I seem to recall my scope card coming up as 15dsp which would suggest its 1st gen. In my current setup however it comes up as 14dsp. And the date sticker is 21.06.02 which is supposed to be 2nd gen by a few months. Maybe its an "inbetween" board being a NFR. Or maybe its faulty.
I hope you dont mind me keeping this public I'm hoping it could help others who are trying to run PT11.01HD
Cheers
Ben
Re: Scope 5.1 64bit and Protools 11HD problems
BTW I did try all ASIO modules just before, keeping them matched. Didnt help.
Re: Scope 5.1 64bit and Protools 11HD problems
i know you have some experience, so don't think i'm talking down at you. in trying to help i have to ask dumb questions like-when you try all those modules, you ARE closing the sequnecer in between each attemot, correct? jfyi, when a sequnecer crashes, it often will not release the ASIO driver until Scope closes and then is reopened. this allows windows to see the ASIO driver again, and then the sequencer can see the driver again when it is restarted.
perhaps it has something to do with PT's multithread or multicore support settings. it's my understanding that you can't use PT11 at all. if it's just not stable at low latencies, but it works at very high latencies, then yes, it's a setting in PT or a setup issue or a backround process or a crazy vst load(i know it's not that).
it's often possible for an upgrade to mess up registry entries and that can make a system stop working. these corrupted entries can often be fixed by rerunning program installers. usually, it's not necessary to uninstall first, although sometimes if there are two or more seperate versions of a program, they will mess each other up because of confusing file paths. uninstalling an old version and rerunning the new version's installer sometimes can fix this.
if the ULLI options show latencies below 13ms, a second generation card is the host card.
since XP sp2, i have never done major tweeks. i have setup and given advice about machines being used by people at the top levels of the etertainment business, and nobody who wants a working system wants to fiddle with it all the time. professionals just want to use it, so i don't like experiments or wringing the last drop of performance. i want it to work so that they never call me. i always go for stable over anything else and i make sure the cards are in a happy environment. even though i could get just a little more performace, ultimately a system can do what it can do, and then you make music with it. no matter what, you will always want more. seriously, i get in the cset like never. well, almost never. the tips and tricks tweeks are all it should take.
yes, it should run at the lowest latency, but i run it at the second lowest for safety. latency is the time that the cpu takes to do calculations for every runing process. the more processes, the higher the latency setting needs to be. this has nothing to do with Scope or it's driver. it has everything to do with the the lowest setting that the cpu can keep a consistent steady stream of audio and midi data. you can't entirely trust the CPU meter either. there are theoretical limits and then there are practical limits. the CPU meter is theoretical. it's also subject to the same latency as the audio, so by the time it registers a dropout, the dropout has already occured. such a meter is only good for keeping a general eye on the load. but again, YES, you should have reliable audio at 4ms@ 44.1k, unless you are running a bunch of heavy VSTis or VSTs that are maxing out the CPU even momentarily, or unless you've picked up a virus from a USB stick(so common where files are shared) or the internet, or you have some other silly process in the backround eating too many clock cycles.
yes, there have been some people with problems, but you'd be amazed how many do NOT have problems. most problems are from pilot error, faulty hardware, improper setup or other software, especially cracks. in fact, i have yet to see a more stable app than Scope, not that there aren't things that can crash it. there is no software without bugs, nor any software that can't be crashed.
perhaps it has something to do with PT's multithread or multicore support settings. it's my understanding that you can't use PT11 at all. if it's just not stable at low latencies, but it works at very high latencies, then yes, it's a setting in PT or a setup issue or a backround process or a crazy vst load(i know it's not that).
it's often possible for an upgrade to mess up registry entries and that can make a system stop working. these corrupted entries can often be fixed by rerunning program installers. usually, it's not necessary to uninstall first, although sometimes if there are two or more seperate versions of a program, they will mess each other up because of confusing file paths. uninstalling an old version and rerunning the new version's installer sometimes can fix this.
if the ULLI options show latencies below 13ms, a second generation card is the host card.
since XP sp2, i have never done major tweeks. i have setup and given advice about machines being used by people at the top levels of the etertainment business, and nobody who wants a working system wants to fiddle with it all the time. professionals just want to use it, so i don't like experiments or wringing the last drop of performance. i want it to work so that they never call me. i always go for stable over anything else and i make sure the cards are in a happy environment. even though i could get just a little more performace, ultimately a system can do what it can do, and then you make music with it. no matter what, you will always want more. seriously, i get in the cset like never. well, almost never. the tips and tricks tweeks are all it should take.
yes, it should run at the lowest latency, but i run it at the second lowest for safety. latency is the time that the cpu takes to do calculations for every runing process. the more processes, the higher the latency setting needs to be. this has nothing to do with Scope or it's driver. it has everything to do with the the lowest setting that the cpu can keep a consistent steady stream of audio and midi data. you can't entirely trust the CPU meter either. there are theoretical limits and then there are practical limits. the CPU meter is theoretical. it's also subject to the same latency as the audio, so by the time it registers a dropout, the dropout has already occured. such a meter is only good for keeping a general eye on the load. but again, YES, you should have reliable audio at 4ms@ 44.1k, unless you are running a bunch of heavy VSTis or VSTs that are maxing out the CPU even momentarily, or unless you've picked up a virus from a USB stick(so common where files are shared) or the internet, or you have some other silly process in the backround eating too many clock cycles.
yes, there have been some people with problems, but you'd be amazed how many do NOT have problems. most problems are from pilot error, faulty hardware, improper setup or other software, especially cracks. in fact, i have yet to see a more stable app than Scope, not that there aren't things that can crash it. there is no software without bugs, nor any software that can't be crashed.
Re: Scope 5.1 64bit and Protools 11HD problems
There was no offense taken. Just as healthy debate 
I'm able to run PT11.01 HD at the highest latency albeit its crashed a few times, also persistent heavy stuttering on stop, buffer outbursts etc
I thought PT to be on the more latent and demanding end of the DAW spectrum...yet then I run it on the RME and its like chalk n cheese, 64 samples no crackles, tight stop and start. I guess its possible that my motherboards bridging and the VirtuVia bridging are both bogus. But 9 masterverbs in the VV is no disaster.
You're right that Scope app itself is very stable but the ASIO modules crash so easily and scope keeps chugging along on one leg. btw I realize changing sample frequency live is a no go.
Once Im able to get it running at highest latency, I step down the ulli setting quitting and reloading each time of both apps. I managed to get the second one back (12ms@48k) working a couple of times but got a whole lotta errors. eg where PT often hangs with bex64 events (a buffer issue?)
If one of the cards is faulty what has been your experience of the milder cases?
I'm able to run PT11.01 HD at the highest latency albeit its crashed a few times, also persistent heavy stuttering on stop, buffer outbursts etc
I thought PT to be on the more latent and demanding end of the DAW spectrum...yet then I run it on the RME and its like chalk n cheese, 64 samples no crackles, tight stop and start. I guess its possible that my motherboards bridging and the VirtuVia bridging are both bogus. But 9 masterverbs in the VV is no disaster.
You're right that Scope app itself is very stable but the ASIO modules crash so easily and scope keeps chugging along on one leg. btw I realize changing sample frequency live is a no go.
Once Im able to get it running at highest latency, I step down the ulli setting quitting and reloading each time of both apps. I managed to get the second one back (12ms@48k) working a couple of times but got a whole lotta errors. eg where PT often hangs with bex64 events (a buffer issue?)
If one of the cards is faulty what has been your experience of the milder cases?
Re: Scope 5.1 64bit and Protools 11HD problems
actually, Cubase and Sonar are much more demanding than PT.
yes, there's a setup issue somewhere. it should work much better than that.
we'll work out a time to talk...
yes, there's a setup issue somewhere. it should work much better than that.
we'll work out a time to talk...
Re: Scope 5.1 64bit and Protools 11HD problems - solved
I think I solved the PT issue!
A total removal of PT10/11 and drivers and re-install of just PT11.01HD, no co-install with 10.3.6, has me up and running at the second lowest ulli setting.
I'm still getting bex64 crashes on exiting PT when a Vienna Ensemble Pro instance is loaded, which then crashes the ASIO module needing a Scope restart.
The crash on exit is due to VEP but the ASIO crash is typical of Scope. Not a big problem though.
I was getting runtime 6025 errors before the re-install. Which means PT was corrupted somehow.
Thanks Gary for keeping the faith. I was beginning to doubt the virtuvia and the 2011 chipset being able to keep scope alive but it has.
A total removal of PT10/11 and drivers and re-install of just PT11.01HD, no co-install with 10.3.6, has me up and running at the second lowest ulli setting.
I'm still getting bex64 crashes on exiting PT when a Vienna Ensemble Pro instance is loaded, which then crashes the ASIO module needing a Scope restart.
The crash on exit is due to VEP but the ASIO crash is typical of Scope. Not a big problem though.
I was getting runtime 6025 errors before the re-install. Which means PT was corrupted somehow.
Thanks Gary for keeping the faith. I was beginning to doubt the virtuvia and the 2011 chipset being able to keep scope alive but it has.
Re: Scope 5.1 64bit and Protools 11HD problems - solved
sure. i'm VERY glad that it's working.
the reason that the Scope driver is gone after the VEP error is that PT doesn't give up the ASIO driver when it crashes so Windows thinks the driver is occupied. restarting Scope removes the driver from the system when Scope closes, and then reinitializes the driver when Scope reopens.
btw-it seems that the Z87 chipset with Socket 1150 motherboards DOES work, so there's still plenty of life in the old girls...
the reason that the Scope driver is gone after the VEP error is that PT doesn't give up the ASIO driver when it crashes so Windows thinks the driver is occupied. restarting Scope removes the driver from the system when Scope closes, and then reinitializes the driver when Scope reopens.
btw-it seems that the Z87 chipset with Socket 1150 motherboards DOES work, so there's still plenty of life in the old girls...
Re: Scope 5.1 64bit and Protools 11HD problems - solved
another dumb question...
are you running the 64bit version of VEP?
are you running the 64bit version of VEP?
Re: Scope 5.1 64bit and Protools 11HD problems - solved
Yes 64bit in host but a mixture of 32 and 64 on remote servers as VEP allows.
Re: Scope 5.1 64bit and Protools 11HD problems - solved
there's also what Windows allows....
64bit operation is a landmine where vst plugins are concerned. mixing 32bit apps with a 64bit os can lead to suprises for the system, which equals a crash. i don't know that that's the problem here, it's just something that can be a problem.
Re: Scope 5.1 64bit and Protools 11HD problems
its come back againNow with a fresh re-install of pt11.01 I'm still getting crashes with scope, if I do get it up and running there is false starts etc doesnt happen with RME. The fresh re-install seemed to help but then the next day its all crap again
Gary do you have clients running scope and pt11.01hd?
Re: Scope 5.1 64bit and Protools 11HD problems
Further testing on the same machine with RME Fireface800 and it behaves great.
Just to be clear I am getting 2 unrelated (AFAIK) PT11.01HD crashes:
1) bex64 which consistently happens if a VEP instance is loaded. If there were none loaded in that session then no bex64 crash. This happens with both Scope and RME as the soundcard.
2) runtime 6025 which happens only when using Scope. Same machine but using RME this crash never occurs.
With the RME after a bex64 crash subsequent loads to PT had no issues. Thus the theory of PT latching on to the driver and not giving it back after a crash is flawed. Not only have I double checked for PT services and processes (there were none) after the bex64 crash but with the RME I can load PT straight back up without having to restart the RME drivers or pc. After a bex64 crash (which is a problem with VEP) Scope needs to be restarted. IMO due to the buggy ASIO modules.
I have re-installed PT11.01HD again and when using Scope I get runtime 6025, when using RME no probs.
Please if there is anyone out there who IS running Win8pro, PT11.01 and Scope 5.1 all in 64bit please chime in and give some insight.
Just to be clear I am getting 2 unrelated (AFAIK) PT11.01HD crashes:
1) bex64 which consistently happens if a VEP instance is loaded. If there were none loaded in that session then no bex64 crash. This happens with both Scope and RME as the soundcard.
2) runtime 6025 which happens only when using Scope. Same machine but using RME this crash never occurs.
With the RME after a bex64 crash subsequent loads to PT had no issues. Thus the theory of PT latching on to the driver and not giving it back after a crash is flawed. Not only have I double checked for PT services and processes (there were none) after the bex64 crash but with the RME I can load PT straight back up without having to restart the RME drivers or pc. After a bex64 crash (which is a problem with VEP) Scope needs to be restarted. IMO due to the buggy ASIO modules.
I have re-installed PT11.01HD again and when using Scope I get runtime 6025, when using RME no probs.
Please if there is anyone out there who IS running Win8pro, PT11.01 and Scope 5.1 all in 64bit please chime in and give some insight.
Re: Scope 5.1 64bit and Protools 11HD problems
yes! people are using PT11.
the Scope card is NOT a soundcard, although it's used as one. windows can reset the RME driver because windows runs the RME card. the proof of that is the availablility of the control panel inside the ASIO host. try using the control panel with the Scope card and see what it does. the reason the driver is not available after PT crashes from VEP is the reason i laid out. your opinion is incorrect. i'm sorry that i can't give a more solid clue about how to fix your issue.
the Scope card is NOT a soundcard, although it's used as one. windows can reset the RME driver because windows runs the RME card. the proof of that is the availablility of the control panel inside the ASIO host. try using the control panel with the Scope card and see what it does. the reason the driver is not available after PT crashes from VEP is the reason i laid out. your opinion is incorrect. i'm sorry that i can't give a more solid clue about how to fix your issue.
Re: Scope 5.1 64bit and Protools 11HD problems
Thanks for your help this far. If others are running pt11 (remember I said v10 no problem) without issue then...
Ill have to put it down to a hardware problem. The virtuvia, 2011 chipset.
Either way life is too short. Time to move on and end my 15yr struggle with scope.
All the best
Ben
Ill have to put it down to a hardware problem. The virtuvia, 2011 chipset.
Either way life is too short. Time to move on and end my 15yr struggle with scope.
All the best
Ben
Re: Scope 5.1 64bit and Protools 11HD problems
Scope is not a soundcard- its a religion. Do thy configuration penance and outlays and ye shall ascend to the sonic heavens.
Re: Scope 5.1 64bit and Protools 11HD problems
mmm. 15yrs is enough.All good, I should of known better to try make it the main daw card again. Its better to the side as a synth and mastering/fx machine. I've come back to that many times over the years.
I just get illusions of grandeur when I redo my setup.