Scope PCI cards clicks & pops - Windows 7 & Cubase 10
-
- Posts: 43
- Joined: Sun Jun 01, 2014 5:15 pm
- Location: Geelong, Australia
Scope PCI cards clicks & pops - Windows 7 & Cubase 10
OK, so on the last ditch mission to resolve this....
Have read many threads here with interest - clearly a delicate area
Here's my setup:
Scope 5.1
3x PCI cards (12 DSP total, 2x Luna & 1x 6DSP Powersampler)
Windows 7
Machine:
CPU i7-4770 3.4GHZ
1150 board Gigabyte GA - Z87P-D3
Samsung 860 EVO SSD system Drive (250GIG)
16 GIG RAM (G Skill Ripjaws)
Asus EAH6450 Silent Graphics 1GIG
Audio & Samples data storage:
Seagate 1TB External USB drive
DAW / Audio software etc:
Cubase 10 Pro - USB eLicenser Dongle/Protection
Universal Audio Satellite Octo USB3
USB Pace iLok (Soundtoys PSP etc)
Waves (native, license now moved to system harddrive)
The computer has been tweaked for audio performance, windows, bios etc, & is essentially offline, Audio duties only
Cubase connects to Scope environment via multiple ASIO outs (32x), then to 2x A16 Ultras via Z-link & ADAT, into an outboard console
Only have 2 ASIO inputs set-up for recording/tracking
ULLI typically at 13ms or 7ms
In Cubase, running a typical session with no VSTi's, on playback with audio only, max 20 tracks so nothing heavy, but with various plugins inserted across outputs & tracks, ALWAYS gets intermittent crackles & pops. I'm suspecting some of it has been recorded at times. Unusable system, can't mix anything down. Have tried Audio Guard both on & off in Cubase, no difference either way but Audio Performance suggests that the computer is barely pushing or working hard
Latencymon tests OK with just Scope running, but no DAW/Cubase working. The issues start when I hit playback.
LatencyMon seems to be pointing to USB, Scope & Cubase for various issue:
Here's the IRQ situation, and from my understand I can't adjust this (easily, like in the (g)olden XP days) anyway even if I wanted to:
I tested disabling the Scope audio driver out of Cubase, but kept the midi, the Latencymon dropped right back into the green, so I figure it's the Scope ASIO factor specifically that's an issue.
The conclusion I've drawn is that unfortunately the 3 main things (Software/DAW, Scope PCI Hardware & USB requirements with my set-up of multi-outputs are either (a) a poor combination here or (b) one or two need to be addressed or swapped out with an alternative to get it working. Logically I'm thinking I'm flogging old technology in a modern system that's not built specifically for it (ie PCI bus bandwidth maximising)
So thinking my options (for this machine / motherboard) are:
1. Keep Cubase/DAW & plugins etc (I have 20 years of Cubase sessions!), change out Scope/audio management for an alternative sound card something like a RME pci-e that can I can simply hook outboard back into via ADAT (keep A16 ultras). Put the pci cards in a spare XP machine I have and use it as a 3rd separate Scope system
2. Try an internal SATA Audio drive - possibly would this deal with the USBPORT.SYS issue?? - Someone suggested I get a separate powered USB3 port to possibly address the USB issue
3.Try an alternative DAW, massive transition exercise of old projects, least preference and most disruptive creatively, & I'm suspecting I would find still the same issue using Scope ASIO, as other people using Ableton or Harrison report clicks/pops etc
I really can't see the point of trying a different PC build - from evidence on this forum it seems that it's a game of time consuming Russian roulette with various combos of motherboard/drivers/components etc...
Any thoughts or input would be most gratefully received.
Thanks in advance
PD
Have read many threads here with interest - clearly a delicate area
Here's my setup:
Scope 5.1
3x PCI cards (12 DSP total, 2x Luna & 1x 6DSP Powersampler)
Windows 7
Machine:
CPU i7-4770 3.4GHZ
1150 board Gigabyte GA - Z87P-D3
Samsung 860 EVO SSD system Drive (250GIG)
16 GIG RAM (G Skill Ripjaws)
Asus EAH6450 Silent Graphics 1GIG
Audio & Samples data storage:
Seagate 1TB External USB drive
DAW / Audio software etc:
Cubase 10 Pro - USB eLicenser Dongle/Protection
Universal Audio Satellite Octo USB3
USB Pace iLok (Soundtoys PSP etc)
Waves (native, license now moved to system harddrive)
The computer has been tweaked for audio performance, windows, bios etc, & is essentially offline, Audio duties only
Cubase connects to Scope environment via multiple ASIO outs (32x), then to 2x A16 Ultras via Z-link & ADAT, into an outboard console
Only have 2 ASIO inputs set-up for recording/tracking
ULLI typically at 13ms or 7ms
In Cubase, running a typical session with no VSTi's, on playback with audio only, max 20 tracks so nothing heavy, but with various plugins inserted across outputs & tracks, ALWAYS gets intermittent crackles & pops. I'm suspecting some of it has been recorded at times. Unusable system, can't mix anything down. Have tried Audio Guard both on & off in Cubase, no difference either way but Audio Performance suggests that the computer is barely pushing or working hard
Latencymon tests OK with just Scope running, but no DAW/Cubase working. The issues start when I hit playback.
LatencyMon seems to be pointing to USB, Scope & Cubase for various issue:
Here's the IRQ situation, and from my understand I can't adjust this (easily, like in the (g)olden XP days) anyway even if I wanted to:
I tested disabling the Scope audio driver out of Cubase, but kept the midi, the Latencymon dropped right back into the green, so I figure it's the Scope ASIO factor specifically that's an issue.
The conclusion I've drawn is that unfortunately the 3 main things (Software/DAW, Scope PCI Hardware & USB requirements with my set-up of multi-outputs are either (a) a poor combination here or (b) one or two need to be addressed or swapped out with an alternative to get it working. Logically I'm thinking I'm flogging old technology in a modern system that's not built specifically for it (ie PCI bus bandwidth maximising)
So thinking my options (for this machine / motherboard) are:
1. Keep Cubase/DAW & plugins etc (I have 20 years of Cubase sessions!), change out Scope/audio management for an alternative sound card something like a RME pci-e that can I can simply hook outboard back into via ADAT (keep A16 ultras). Put the pci cards in a spare XP machine I have and use it as a 3rd separate Scope system
2. Try an internal SATA Audio drive - possibly would this deal with the USBPORT.SYS issue?? - Someone suggested I get a separate powered USB3 port to possibly address the USB issue
3.Try an alternative DAW, massive transition exercise of old projects, least preference and most disruptive creatively, & I'm suspecting I would find still the same issue using Scope ASIO, as other people using Ableton or Harrison report clicks/pops etc
I really can't see the point of trying a different PC build - from evidence on this forum it seems that it's a game of time consuming Russian roulette with various combos of motherboard/drivers/components etc...
Any thoughts or input would be most gratefully received.
Thanks in advance
PD
Re: Scope PCI cards clicks & pops - Windows 7 & Cubase 10
that is not the place to check IRQ settings. you want system information\hardware resources\conflicts/sharing.
what is the USB problem?
are you running audio through USB for recording? that's just looking for trouble. USB really isn't meant for that. it's ok, with a soundcard, but it's a bad idea. it's for children, that's why it's popular, it's an easy driver to make. it is not good for reliable, realtime use, though. USB has the bandwiidth, but not continuously.
there is no reason that Cubase and Scope should not be happy, i use both, but you do need an idea about how things function.
what is the USB problem?
are you running audio through USB for recording? that's just looking for trouble. USB really isn't meant for that. it's ok, with a soundcard, but it's a bad idea. it's for children, that's why it's popular, it's an easy driver to make. it is not good for reliable, realtime use, though. USB has the bandwiidth, but not continuously.
there is no reason that Cubase and Scope should not be happy, i use both, but you do need an idea about how things function.
-
- Posts: 43
- Joined: Sun Jun 01, 2014 5:15 pm
- Location: Geelong, Australia
Re: Scope PCI cards clicks & pops - Windows 7 & Cubase 10
Gary, thanks for your response
IRQ 16 - is that an issue?
Would you suggest I be using a secondary internal SATA drive for the audio files / Cubase sessions that I'm working on, and then only have the USB external drive as a back-up?
The only USB 1 or 2 related peripherals I need are the USB dongle, iLok and possibly a Shuttle Control I've been trying out. I don't have any other USB audio interface (I assume the UAD Satellite on USB3 is not considered a USB audio interface??)
I know I'm old school with pushing the outboard / out of the box mixing set-up - that's a whole other conversation/debate. But am I incorrect in suspecting the combination of the 1150 motherboard architecture (PCI cards handled/funnelled through a pci-e to pci bridge) and the Scope 5.1 64 bit drivers handling ASIO, (and I've got these loaded up for playback with 32x channels) is just too much to expect? It may work fine for an ITB mixing situation that naturally limits the ASIO output load. Again please correct me if I've got this totally wrong!
Thanks again
I've attached IRQ sharing from System Infothat is not the place to check IRQ settings. you want system information\hardware resources\conflicts/sharing.
IRQ 16 - is that an issue?
It seems that's what Latency mon was pointing to - have I misinterpreted the test results?what is the USB problem?
well, I record IN directly via Scope (A16 Ultra) from the desk. I then feed back out the same way. It's all ADAT or Z-link. There is no audio streaming via a USB device, EXCEPT I'm guessing some of it goes in and out for plugin processing through USB3 for the UAD satellite (?? - please clarify/correct me here if I'm wrong so I can understand how this works properly!) All my Cubase sessions / audio files however are stored on / accessed from an external USB drive. Is this the embarrassing Rookie error I have in my set-up? I know other people use USB drives but possibly they have a different sound card set-up that isn't as sensitive or is clashing with the USB factor so it's not a problem?are you running audio through USB for recording?
Would you suggest I be using a secondary internal SATA drive for the audio files / Cubase sessions that I'm working on, and then only have the USB external drive as a back-up?
The only USB 1 or 2 related peripherals I need are the USB dongle, iLok and possibly a Shuttle Control I've been trying out. I don't have any other USB audio interface (I assume the UAD Satellite on USB3 is not considered a USB audio interface??)
Dude am I trying! I'm open to any suggestions, adjustments or recommendations. Clearly I don't have the technical understanding of many others who live & breathe computers here - how much computer knowledge depth is needed here? I'm a musician & I would expect most end users here are primarily that to - obviously dealing with computer based recording (for a couple of decades) we (naturally) develop a certain understanding of computer systems, relevant to our particular set-ups and what we're trying to achieve with them.but you do need an idea about how things function
I know I'm old school with pushing the outboard / out of the box mixing set-up - that's a whole other conversation/debate. But am I incorrect in suspecting the combination of the 1150 motherboard architecture (PCI cards handled/funnelled through a pci-e to pci bridge) and the Scope 5.1 64 bit drivers handling ASIO, (and I've got these loaded up for playback with 32x channels) is just too much to expect? It may work fine for an ITB mixing situation that naturally limits the ASIO output load. Again please correct me if I've got this totally wrong!
Thanks again
Re: Scope PCI cards clicks & pops - Windows 7 & Cubase 10
Absolutely recommend use of a secondary internal drive to record to rather than the usb drive
Use the usb drive as backup and only after recording
Also disable that USB driver while recording and only enable it when you need access to the USB drive.
Do that by right clicking on it from Windows device manager and disable it.
Try that and see if it works.
Use the usb drive as backup and only after recording
Also disable that USB driver while recording and only enable it when you need access to the USB drive.
Do that by right clicking on it from Windows device manager and disable it.
Try that and see if it works.
Re: Scope PCI cards clicks & pops - Windows 7 & Cubase 10
i hate computers.
yes, disable usb controller 8C2D in the device manager. you will lose a usb port or two but there are plenty of others. you can also use a hub.
usb is not suited to real-time record streaming. use another sata drive. use the usb drive for storage. if you wanna go old school, that's great, but simplfy when recording parts. use stereo out for monitoring. when mixing use a lot of individual outs and then you can use all the outboard you like. or something. you don't want to make the recording operation any more difficulty than it needs to be, in real studios, they have different rooms with different setups and gear for recording and mixing.
actually, you should get decent results however you prefer to work. there WILL be limits, but then there always are. a socket 1150 motherboard should work really well.
yes, disable usb controller 8C2D in the device manager. you will lose a usb port or two but there are plenty of others. you can also use a hub.
usb is not suited to real-time record streaming. use another sata drive. use the usb drive for storage. if you wanna go old school, that's great, but simplfy when recording parts. use stereo out for monitoring. when mixing use a lot of individual outs and then you can use all the outboard you like. or something. you don't want to make the recording operation any more difficulty than it needs to be, in real studios, they have different rooms with different setups and gear for recording and mixing.
actually, you should get decent results however you prefer to work. there WILL be limits, but then there always are. a socket 1150 motherboard should work really well.
-
- Posts: 43
- Joined: Sun Jun 01, 2014 5:15 pm
- Location: Geelong, Australia
Re: Scope PCI cards clicks & pops - Windows 7 & Cubase 10
Thanks for that
OK so clearly a massive fail with trying to use an external USB drive for audio
Will try that.
If I disable the "8C2D" (a good name for a Droid ) is it then a matter of trial and error with identifying the particular USB ports that will be lost?
I assume this won't impact the USB 3 ports - are they managed independently?
I know in an ideal world we separate the recording and (complex) mixing processes......but the way I seem to have developed to work is laying tracks down in a way like having a tape machine connected to an in-line console (which is what I have), hearing the mix come together during the tracking process. Someones when I'm mixing I'm hearing another part, so I just drop it on top and keep going....Each to their own I guess
Appreciate the thoughts and comments
Will see how I go with an internal drive and possibly one of those USB3 hubs fidox suggested in another post
Cheers
OK so clearly a massive fail with trying to use an external USB drive for audio
Will try that.
If I disable the "8C2D" (a good name for a Droid ) is it then a matter of trial and error with identifying the particular USB ports that will be lost?
I assume this won't impact the USB 3 ports - are they managed independently?
I know in an ideal world we separate the recording and (complex) mixing processes......but the way I seem to have developed to work is laying tracks down in a way like having a tape machine connected to an in-line console (which is what I have), hearing the mix come together during the tracking process. Someones when I'm mixing I'm hearing another part, so I just drop it on top and keep going....Each to their own I guess
Appreciate the thoughts and comments
Will see how I go with an internal drive and possibly one of those USB3 hubs fidox suggested in another post
Cheers
Re: Scope PCI cards clicks & pops - Windows 7 & Cubase 10
USB is a serial "PIO" protocol. PIO means "Programmed Input & Output" and basically means the CPU is responsible for all operations on the device. Years and year ago, we were concerned about whether a device was PIO or DMA as the latter had "direct memory access" and could finish an i/o operation on its own after an Interrupt Request was served by the CPU. Ie, the CPU could initiate an operation, then move on to another task while the 'memory hole' that the device was going to 'fill' (or read from) to finish that operation was handled entirely by the device--it could read from or write to that memory hole without the CPU. With a PIO device the CPU must hang out and wait for the entire operation to complete, as it initiates the i/o operation (after the interrupt request is received and then handled). In the single core era, this was a VERY big issue, and in the dual core era also an issue. To compound matters back then, USB ports were implemented in a way that was not very efficient and reliant on additional silicon (more chips on the board).
Things have changed somewhat over the years. CPU's have core resources to spare, usually. There's enough Bus bandwidth now as well that we don't worry as much about running out of PCI/PCIe bandwidth for USB operations. What has NOT changed from the perspective of audio cards and especially Scope cards is that the amount of TIME an operation takes is still important, regardless of how much bandwidth this operation takes. In other words, if a device doesn't respond quickly enough then the audio operation cannot be completed, as that data isn't in place to be handled.
As you have been discussing, this is the source of clicks & pops. ANY device that does not release its interrupt request fast enough is a problem for audio as well as any other realtime task (an interrupt request is what a CPU receives when it has to handle any operation to a device on the system that is not located in the CPU itself or system ram). One way the CPU can 'defer' handling an interrupt request is something called a Deferred Procedure Call (DPC) and so one thing you'll see discussed when dealing with audio performance issues is looking for DPC Latency problems, which I can see from your first screenshot you've been looking at already.
In fact, in your first screenshot what I see is: USB 1.1_d.0 Port Driver is returning from its ISR routine too slowly (and the Scope driver spends a lot of kernel time handling its physical i/o as well, but this is to be expected.)
An ISR routine is an Interrupt Service Routine, or the specific block of code that handles the interrupt condition by doing the actual data transfer to & from the CPU thus 'interrupting' the active process. When the ISR is complete, the CPU returns back to the process (your DAW or Operating system's program loops). So the culprit you guys have been discussing is the USB port that is 'waiting around' for some operation to finish, and thus release the CPU resources tied up.
There are two ways to implement USB ports on a motherboard:
[*]USB controller built into an AMD or Intel chipset (what we used to call the "southbridge")
[*]3rd party USB chipset, typically off of a PCIe lane connected to the chipset ("southbridge")
The former have improved immeasurably since the USB 1.1 & 2.0 era, enough so that RME trusts Intel USB implementation more than PCIe lanes and have gotten rid of their 'safety buffer' when they see their cards connected to the USB bus. If PCIe or Firewire are involved, the safety buffer is still active. HOWEVER, this does NOT mean that all USB devices are equal, and that the RME devices are always happy. Simply that when there's no other devices to contend with, modern USB implementations in and of themselves are not a problem *when using an Intel or AMD implementation*. 3rd party chipsets are still a problem.
Checking the product page for your Gigabyte GA-Z87P-D3 motherboard shows that the Z87 chipset that board uses provides the USB ports you have on the board (6 USB 3.0 ports & 8 USB 2.0 ports). So no need to worry about 3rd party chipsets, which are an issue because they are often used to implement features BEFORE a specification is complete (and thus implemented by AMD or Intel in an official chipset release). This, along with some chipsets on the audio interface side, is why certain USB2 audio cards did not play well with USB3 devices (you alluded to reading somewhere that different generation devices didn't play well, this was one of two common issues that audio users like us would have encountered in the last 5-7 years).
Ok so, most of this is recounting what you and Gary have already discussed in this thread.
What's important to look at now is:
Anything connected to the same PORT (this is a Logical device) will have to contend with all other devices on that port for bandwidth. If a device is slow, causes a wait state (it went to sleep or is waiting on its own resources locally to respond to a request--like a drive read or write operation) or is otherwise busy, this can cause other devices on the chain to wait.
In the past we could go into device manager and choose View > Devices by Connection (or Resources by connection) but there's so many virtualized resources in a modern system that this won't give us the same level of detail it once did (in fact I rarely actually see the USB chain as it exists in these views). Similarly the Windows "System Information" application will only show you what the USB root controllers are:
All this tells me is that I have a 3rd party chipset for my USB 3.1 ports (there are 4 physical ones exposed on the back). Now, I could show you the view from Device manager, but while it does show some of the 'Composite devices' and two additional USB Hubs connected (a 3.0 and a 3.1) to various ports, it doesn't say WHERE they are connected in terms of addressing.
I personally use AIDA64 to see my full USB chain (which shows the same thing that you see in Mac OS's System Information when viewing USB devices, interestingly enough):
Now, if I look in the above screenshot (my second one) from AIDA64, I can see the same 2 USB controllers and you can actually see what's connected where in terms of how the Operating System (and thus CPU) is addressing everything. However let's look at the technical specs again:
This system (the one I'm typing on, not my Scope system btw) is an Intel Z370 Chipset. Checking Intel's ARK again (like I did above for you) I see that Intel has implemented the following:
USB 3.0 Up to 10
USB 2.0 Up to 14
However in the actual implementation from my motherboard maker, they have only exposed the following: two USB-C, six USB 2.0 ports, four 3.0 ports and four 3.1 ports (connected to the ASMedia controller). So that's actually only 12 of the 24 ports available connected to the Intel controller (plus four to the 3rd party controller as 3.1 wasn't available with the Intel Z370). So a good number of the ports in the screenshot above will never show a device, as they aren't exposed on the motherboard or back panel.
So.....you'll see I do have a hub. In my case this is largely for convenience, as I can place it on my desk for quick use in connecting usb thumb drives and SDHC card readers, etc. If I were to connect my WD drive to a hub that also had several other peripherals connected (like my 1000hz gaming mouse), then you would realize that the cumulative latency for this SINGLE port (the hub is connected to a physical port that connects to a virtual port, and thus one of the Root hubs at the top) is the combined latency of all devices connected.
In other words, your USB SSD isn't the only issue here. It's a combination of ALL devices connected to your hub, and the specific chipsets each device uses to handle its own tasks. Ie, if one of the devices connected to that virtual (and physical) port is still in a wait state but another device has to be serviced then the CPU will wait on the first device to finish its full operation and then still need to come back around and service the second device on the *same* port, and it can look like the USB driver (USB 1.1_d.0 Port Driver in your case) is the culprit.
Ok, so there's a lot of info here but how does it help you in practice?
In general it's not a good idea to use an audio card or a USB drive on a hub if you can help it, if there are going to be other devices on that hub that may cause an issue. And who would use a hub with only one device? Oddly enough when the first 3rd party USB 3.0 chipsets were out and having problems with USB 2.0 soundcards, using a USB 2.0 hub was actually one way to solve these issues--but that's an unusual case and only certain hubs would solve this issue anyway. Well, Gary has told you this as well..
What's more salient and worth investigating is that there are times where physical ports MAY be connected to the same virtual port. You can't see this without using a tool like I have above, to see what is addressed where. And when you do, you can start to clearly see what devices may share with each other because you can see the full tree of devices (assuming the tool you're using to expose this shows the tree properly). Your system has enough ports that this is not as likely as big of an issue as it was in the USB 2.0 era (where Intel only implemented 4 ports).
HOWEVER, note that your ROOT HUB is a *hub*. A hub is not a switch, it's simply an electrical connection. So ALL of your USB devices share the same physical addressing lines, and are ALL contending for the same bandwidth at the point the USB hub is implemented (chipset). SO much like when two devices are on the same port but one is in a wait state (busy), when the USB root hub is busy services any device ALL other devices will have to wait. This loops us back to the USB 1.1_d.0 Port Driver showing a very high Deferred Procedural Call...
Yes, your USB SSD is likely a major cause of latency here. But now you should hopefully have enough issues to further debug any DPC Latency results that give you the same ISR driver (USB 1.1_d.0 Port Driver) as a problem.
Things have changed somewhat over the years. CPU's have core resources to spare, usually. There's enough Bus bandwidth now as well that we don't worry as much about running out of PCI/PCIe bandwidth for USB operations. What has NOT changed from the perspective of audio cards and especially Scope cards is that the amount of TIME an operation takes is still important, regardless of how much bandwidth this operation takes. In other words, if a device doesn't respond quickly enough then the audio operation cannot be completed, as that data isn't in place to be handled.
As you have been discussing, this is the source of clicks & pops. ANY device that does not release its interrupt request fast enough is a problem for audio as well as any other realtime task (an interrupt request is what a CPU receives when it has to handle any operation to a device on the system that is not located in the CPU itself or system ram). One way the CPU can 'defer' handling an interrupt request is something called a Deferred Procedure Call (DPC) and so one thing you'll see discussed when dealing with audio performance issues is looking for DPC Latency problems, which I can see from your first screenshot you've been looking at already.
In fact, in your first screenshot what I see is: USB 1.1_d.0 Port Driver is returning from its ISR routine too slowly (and the Scope driver spends a lot of kernel time handling its physical i/o as well, but this is to be expected.)
An ISR routine is an Interrupt Service Routine, or the specific block of code that handles the interrupt condition by doing the actual data transfer to & from the CPU thus 'interrupting' the active process. When the ISR is complete, the CPU returns back to the process (your DAW or Operating system's program loops). So the culprit you guys have been discussing is the USB port that is 'waiting around' for some operation to finish, and thus release the CPU resources tied up.
There are two ways to implement USB ports on a motherboard:
[*]USB controller built into an AMD or Intel chipset (what we used to call the "southbridge")
[*]3rd party USB chipset, typically off of a PCIe lane connected to the chipset ("southbridge")
The former have improved immeasurably since the USB 1.1 & 2.0 era, enough so that RME trusts Intel USB implementation more than PCIe lanes and have gotten rid of their 'safety buffer' when they see their cards connected to the USB bus. If PCIe or Firewire are involved, the safety buffer is still active. HOWEVER, this does NOT mean that all USB devices are equal, and that the RME devices are always happy. Simply that when there's no other devices to contend with, modern USB implementations in and of themselves are not a problem *when using an Intel or AMD implementation*. 3rd party chipsets are still a problem.
Checking the product page for your Gigabyte GA-Z87P-D3 motherboard shows that the Z87 chipset that board uses provides the USB ports you have on the board (6 USB 3.0 ports & 8 USB 2.0 ports). So no need to worry about 3rd party chipsets, which are an issue because they are often used to implement features BEFORE a specification is complete (and thus implemented by AMD or Intel in an official chipset release). This, along with some chipsets on the audio interface side, is why certain USB2 audio cards did not play well with USB3 devices (you alluded to reading somewhere that different generation devices didn't play well, this was one of two common issues that audio users like us would have encountered in the last 5-7 years).
Ok so, most of this is recounting what you and Gary have already discussed in this thread.
What's important to look at now is:
Anything connected to the same PORT (this is a Logical device) will have to contend with all other devices on that port for bandwidth. If a device is slow, causes a wait state (it went to sleep or is waiting on its own resources locally to respond to a request--like a drive read or write operation) or is otherwise busy, this can cause other devices on the chain to wait.
In the past we could go into device manager and choose View > Devices by Connection (or Resources by connection) but there's so many virtualized resources in a modern system that this won't give us the same level of detail it once did (in fact I rarely actually see the USB chain as it exists in these views). Similarly the Windows "System Information" application will only show you what the USB root controllers are:
All this tells me is that I have a 3rd party chipset for my USB 3.1 ports (there are 4 physical ones exposed on the back). Now, I could show you the view from Device manager, but while it does show some of the 'Composite devices' and two additional USB Hubs connected (a 3.0 and a 3.1) to various ports, it doesn't say WHERE they are connected in terms of addressing.
I personally use AIDA64 to see my full USB chain (which shows the same thing that you see in Mac OS's System Information when viewing USB devices, interestingly enough):
Now, if I look in the above screenshot (my second one) from AIDA64, I can see the same 2 USB controllers and you can actually see what's connected where in terms of how the Operating System (and thus CPU) is addressing everything. However let's look at the technical specs again:
This system (the one I'm typing on, not my Scope system btw) is an Intel Z370 Chipset. Checking Intel's ARK again (like I did above for you) I see that Intel has implemented the following:
USB 3.0 Up to 10
USB 2.0 Up to 14
However in the actual implementation from my motherboard maker, they have only exposed the following: two USB-C, six USB 2.0 ports, four 3.0 ports and four 3.1 ports (connected to the ASMedia controller). So that's actually only 12 of the 24 ports available connected to the Intel controller (plus four to the 3rd party controller as 3.1 wasn't available with the Intel Z370). So a good number of the ports in the screenshot above will never show a device, as they aren't exposed on the motherboard or back panel.
So.....you'll see I do have a hub. In my case this is largely for convenience, as I can place it on my desk for quick use in connecting usb thumb drives and SDHC card readers, etc. If I were to connect my WD drive to a hub that also had several other peripherals connected (like my 1000hz gaming mouse), then you would realize that the cumulative latency for this SINGLE port (the hub is connected to a physical port that connects to a virtual port, and thus one of the Root hubs at the top) is the combined latency of all devices connected.
In other words, your USB SSD isn't the only issue here. It's a combination of ALL devices connected to your hub, and the specific chipsets each device uses to handle its own tasks. Ie, if one of the devices connected to that virtual (and physical) port is still in a wait state but another device has to be serviced then the CPU will wait on the first device to finish its full operation and then still need to come back around and service the second device on the *same* port, and it can look like the USB driver (USB 1.1_d.0 Port Driver in your case) is the culprit.
Ok, so there's a lot of info here but how does it help you in practice?
In general it's not a good idea to use an audio card or a USB drive on a hub if you can help it, if there are going to be other devices on that hub that may cause an issue. And who would use a hub with only one device? Oddly enough when the first 3rd party USB 3.0 chipsets were out and having problems with USB 2.0 soundcards, using a USB 2.0 hub was actually one way to solve these issues--but that's an unusual case and only certain hubs would solve this issue anyway. Well, Gary has told you this as well..
What's more salient and worth investigating is that there are times where physical ports MAY be connected to the same virtual port. You can't see this without using a tool like I have above, to see what is addressed where. And when you do, you can start to clearly see what devices may share with each other because you can see the full tree of devices (assuming the tool you're using to expose this shows the tree properly). Your system has enough ports that this is not as likely as big of an issue as it was in the USB 2.0 era (where Intel only implemented 4 ports).
HOWEVER, note that your ROOT HUB is a *hub*. A hub is not a switch, it's simply an electrical connection. So ALL of your USB devices share the same physical addressing lines, and are ALL contending for the same bandwidth at the point the USB hub is implemented (chipset). SO much like when two devices are on the same port but one is in a wait state (busy), when the USB root hub is busy services any device ALL other devices will have to wait. This loops us back to the USB 1.1_d.0 Port Driver showing a very high Deferred Procedural Call...
Yes, your USB SSD is likely a major cause of latency here. But now you should hopefully have enough issues to further debug any DPC Latency results that give you the same ISR driver (USB 1.1_d.0 Port Driver) as a problem.
-
- Posts: 43
- Joined: Sun Jun 01, 2014 5:15 pm
- Location: Geelong, Australia
Re: Scope PCI cards clicks & pops - Windows 7 & Cubase 10
valis - thank you for taking the time to put down such a detailed explanation / lesson in all things USB
Just to clarify, the external drive in question is a just a standard powered Seagate Expansion magnetic drive connected via USB - so I assume this is even worse in terms of timing (than a SSD........
Anyway so to sum up, in layman's terms
- Scope PCI has little if no tolerance for interruptions when dealing with flow/management of audio data so we try and set up the system to keep Scope "happy" in this way
- to keep Scope happy and mitigate clicks & pops we need a system that prioritises or clears the way for Scope's processing and is less prone to interruptions from other things or processes,
- USB by nature typically causes (significant) interruptions no matter how "fast" the cpu/system or whatever is
- as a rule for these Scope systems, it seems best to have as little if no USB aspect dealing with audio in the system, for audio channelling or data flow for systems dealing with Scope
?? is that kind of it/accurate? - I know that's a super basic way of putting it compared with your level of technical explanation
If I kind of get it, It totally makes sense for the issues occurring, in my case, my having the main audio files are being fed via a USB connected drive
I'll get an internal SATA and hopefully that sorts it out.
I'm still not 100% clear on whether I need a hub for this motherboard or not, since if I take the USB connected drive out of the picture surely just a couple of USB dongles and the UAD USB3 seems to be not an issue here?
Anyway we'll see how we go - I'll report back.
I suppose to be fair we're trying to do achieve something here using legacy pci technology that whilst we know what it's potential is, it clearly requires very specific conditions with essentially no margin for error when it comes to timing.
So what I'm hearing here is that really if we want to play ball with Scope then we need to have the knowledge of the conditions it needs to behave as we expect/need it to, particularly for recording audio. As a standalone synth or environment not dealing with ASIO / streaming audio to and from disks etc then perhaps we get away with less attention to detail in this regard or greater system headroom / margin for error in regards to timing (??)
I may be relatively slow on the uptake here but I'm trying to improve my understanding of how it all works - I think I'm learning something! Thanks again for your input and assistance
PD
Just to clarify, the external drive in question is a just a standard powered Seagate Expansion magnetic drive connected via USB - so I assume this is even worse in terms of timing (than a SSD........
Anyway so to sum up, in layman's terms
- Scope PCI has little if no tolerance for interruptions when dealing with flow/management of audio data so we try and set up the system to keep Scope "happy" in this way
- to keep Scope happy and mitigate clicks & pops we need a system that prioritises or clears the way for Scope's processing and is less prone to interruptions from other things or processes,
- USB by nature typically causes (significant) interruptions no matter how "fast" the cpu/system or whatever is
- as a rule for these Scope systems, it seems best to have as little if no USB aspect dealing with audio in the system, for audio channelling or data flow for systems dealing with Scope
?? is that kind of it/accurate? - I know that's a super basic way of putting it compared with your level of technical explanation
If I kind of get it, It totally makes sense for the issues occurring, in my case, my having the main audio files are being fed via a USB connected drive
I'll get an internal SATA and hopefully that sorts it out.
I'm still not 100% clear on whether I need a hub for this motherboard or not, since if I take the USB connected drive out of the picture surely just a couple of USB dongles and the UAD USB3 seems to be not an issue here?
Anyway we'll see how we go - I'll report back.
I suppose to be fair we're trying to do achieve something here using legacy pci technology that whilst we know what it's potential is, it clearly requires very specific conditions with essentially no margin for error when it comes to timing.
So what I'm hearing here is that really if we want to play ball with Scope then we need to have the knowledge of the conditions it needs to behave as we expect/need it to, particularly for recording audio. As a standalone synth or environment not dealing with ASIO / streaming audio to and from disks etc then perhaps we get away with less attention to detail in this regard or greater system headroom / margin for error in regards to timing (??)
I may be relatively slow on the uptake here but I'm trying to improve my understanding of how it all works - I think I'm learning something! Thanks again for your input and assistance
PD
Re: Scope PCI cards clicks & pops - Windows 7 & Cubase 10
that is pretty much correct.
as i keep saying, the Scope stream is a real-time stream. if the stream is interrupted, there will be data loss and that sounds like a click or pop.
as to hubs, they are no big deal. neither is USB3. USB3 seems superior, data-flow-wise, but the number advantage is burst only, not continued streaming. for data transfer, the only advantage is lower transfer times when copy/pasting from the computer to the external drive. you only need a hub if you have more devices to connect than you have working USB ports, or if you want to route the USB ports from the back of the computer to the front. if you use a hub, use a powered one.
yes, as a stand-alone system, none of this is important, because the audio will not be going through Windows in any way. Scope cards are external hardware, the audio is NOT part of the computer. the computer only provides power and a gui. in fact, if the computer crashes, but remains on, the card will continue to function in the state that it was in before the crash, but you won't be able to change anything on the card until reboot.
as i keep saying, the Scope stream is a real-time stream. if the stream is interrupted, there will be data loss and that sounds like a click or pop.
as to hubs, they are no big deal. neither is USB3. USB3 seems superior, data-flow-wise, but the number advantage is burst only, not continued streaming. for data transfer, the only advantage is lower transfer times when copy/pasting from the computer to the external drive. you only need a hub if you have more devices to connect than you have working USB ports, or if you want to route the USB ports from the back of the computer to the front. if you use a hub, use a powered one.
yes, as a stand-alone system, none of this is important, because the audio will not be going through Windows in any way. Scope cards are external hardware, the audio is NOT part of the computer. the computer only provides power and a gui. in fact, if the computer crashes, but remains on, the card will continue to function in the state that it was in before the crash, but you won't be able to change anything on the card until reboot.
Re: Scope PCI cards clicks & pops - Windows 7 & Cubase 10
Apologies for misreading and thinking there was an external SSD. And yes a normal external HD is magnitudes worse in terms of USB performance, especially as they typically have slower 2.5” laptop drives with inexpensive chipsets (these enclosures are sometimes cheaper than the bare drive).
All other responses seem fine. By dedicating a system to Scope I see similar DSP performance on systems from 2001 to current although the GUI and any ASIO (meaning native plugins) related performance is as you would expect for a given era of PC. This backs up what Gary is stating about how certain features may improve burst speeds but don’t necessarily improve real-time
System performance (being “ready” for the next task) as far as scope is concerned.
As a parable imagine a conveyer belt that feeds the Packages to a sorting robot. The robot may be able to handle 1 or 10 packages at a time but once it starts moving the packages it has in hand, if another package comes along that package will have to wait on the conveyor belt—or fall on the floor—until the robot is ready to pick up the packages again. Being able to carry more packages does not necessarily mean it is ready for the next set of packages any faster. Conversely, even if we presume that we also have a robot that can turn around faster and thus grab new groups of packages (data) faster, if a package is stuck coming down the conveyer belt and doesn't arrive in time that robot will then have an 'empty process cycle' where it has nothing in hand to hand off! This is the nature of audio dropouts, there's nothing to deliver as something else stalled the delivery of the data, and we have a click or pop as a result.
In other words bandwith and latency are related but increasing bandwith (or CPU’s IPC— Instructions per clock cycle) does not necessarily improve assistance ability to perform real time tasks. We have to consider the whole of the system including components attached, drivers, and even software updates and memory resident applications.
All other responses seem fine. By dedicating a system to Scope I see similar DSP performance on systems from 2001 to current although the GUI and any ASIO (meaning native plugins) related performance is as you would expect for a given era of PC. This backs up what Gary is stating about how certain features may improve burst speeds but don’t necessarily improve real-time
System performance (being “ready” for the next task) as far as scope is concerned.
As a parable imagine a conveyer belt that feeds the Packages to a sorting robot. The robot may be able to handle 1 or 10 packages at a time but once it starts moving the packages it has in hand, if another package comes along that package will have to wait on the conveyor belt—or fall on the floor—until the robot is ready to pick up the packages again. Being able to carry more packages does not necessarily mean it is ready for the next set of packages any faster. Conversely, even if we presume that we also have a robot that can turn around faster and thus grab new groups of packages (data) faster, if a package is stuck coming down the conveyer belt and doesn't arrive in time that robot will then have an 'empty process cycle' where it has nothing in hand to hand off! This is the nature of audio dropouts, there's nothing to deliver as something else stalled the delivery of the data, and we have a click or pop as a result.
In other words bandwith and latency are related but increasing bandwith (or CPU’s IPC— Instructions per clock cycle) does not necessarily improve assistance ability to perform real time tasks. We have to consider the whole of the system including components attached, drivers, and even software updates and memory resident applications.
Re: Scope PCI cards clicks & pops - Windows 7 & Cubase 10
USB 1 sucks for audio. I’ve had no issues with the Zoom UAC8 on USB3. USB2 - don’t know never tried it.
Re: Scope PCI cards clicks & pops - Windows 7 & Cubase 10
ok, if you are using usb for an interface, you want at least usb2, but for transferring data, any will work. obviously, faster is faster.
Re: Scope PCI cards clicks & pops - Windows 7 & Cubase 10
Modified my robot example paragraph above for better clarity, what actually happens when we have an audio dropout is the robot is stuck waiting...and I think that accounts for both issues in delivery of audio data now.
-
- Posts: 43
- Joined: Sun Jun 01, 2014 5:15 pm
- Location: Geelong, Australia
Re: Scope PCI cards clicks & pops - Windows 7 & Cubase 10
Reporting back......unfortunately still stuck down the system troubleshooting rabbit hole
So since last post system changes:
- internal SATA secondary hard drive to handle audio
- got a powered USB3 hub, shared USB host controller disabled
I'm coming to the conclusion that I've got an issue with ASIO performance and/or UAD plugins on mix down, or both. It could be my particular machine is not good enough, or possibly I'm pushing the limits with the Scope pci factor, may not as simple as that....but either way the system's not performing.
I originally went down the Creamware path (20 years ago about) for it's (relatively cost effective) audio routing / multiple output capacity. I got a Luna and an A16U and went from there. At the time, what triggered it, was that I didn't want to be stuck "in the box". Everything (for me) mixing-wise sounded better, clearer, bigger, wider, more professional, when separated out and summed externally even on cheaper outboard gear.
Somewhere along the way back then I picked up a UAD1 and brought this into the mix (no pun intended)....Expanded Scope DSP capacity (with additional cards)......Ended up with a fully loaded system on a dual core - 3x Scope PCI + 2x UAD1 - the sound itself was heading towards a good result, but was constantly pushing the limits of the computer / pci bus with outputs and plugins.
So last year bit the bullet with a PC upgrade, which in turn conceded a UAD upgrade, as limited PCI slots in modern systems and wanting to keep/house Scope PCI set-up meant UAD2 options (for PC) limited(forced) to a Satellite USB3 (as opposed to the pci-e options.....make sense/logical?
So now a year or so down the track, seems still the way I want to work is proving not possible as a combination and I need to work out which component to cut loose or change out.
So I've got rid of the external USB drive, but this hasn't changed or improved anything from a performance. It seems the USBPORT.SYS issue is still occurring when the UAD2 is processing, but I find this confusing as isn't this UAD a USB3 device and handled separately via different drivers and controllers? Again my technical knowledge/understanding lacking in this area.
So a few "tests" showing Latencymon on the same Cubase mixdown session, testing various combinations of either (a) multiple or reduced/stereo ASIO output and (b) UAD2 in or out of the picture. Just to clarify, session has only around 16 channels of actual audio running here. There is 1x midi track for the drums that triggers a separate machine so NO VSTi's, we have 4 channels of mono vocals, mono bass, 3x stereo guitars, 3x mono guitars, 1x stereo keys/organ & 3x FX sends (delay/reverb) - it's not that heavy in terms of playback
1. Fully loaded, multiple ASIO out, UAD2 across various outputs - this is the scenario I'm aiming for
Clearly a failing combination
2. Totally Ditching the UAD2 & plugins removed from session - (ie UAD satellite turned off , computer rebooted), but keeping multiple ASIO outputs
Unfortunately still not great
3. Kept UAD loaded, reduced ASIO to stereo output only
Actually worse!!
4. Nothing - No UAD, Stereo outputs only
Success!!!.......well, not really as I may as well be back in 2001, stuck ITB with just a DAW and native plugins
OK, so what I've come to / concluded is this:
1. UAD2 is not performing either way, with multiple or reduced ASIO
2. Scope is not performing with multiple ASIO outputs, so can't mixdown via console/ouboard in this set-up
3. Scope performs but with limited ASIO and just use native DAW / processing
If I go back 15 or 20 years as to what my aim for making & mixing music was in my studio, (and still is), that is to maintain outboard mixing environment, I'm clearly not winning trying to achieve it with Scope and a current PC / DAW system.
I think it's come time for looking at an alternative way of getting audio out of my computer if that's what I want to keep trying to do. As this is what it seems is the main sticking point. So why am I pushing this path so hard? well (a) sound and (b), creative workflow and using the physical gear I have aquired/invested in and know inside out.
The difference in the "mix", in having say UAD processing in or out, is arguably not so significant as there are ways of achieving vintage emulations with alternatives natively, or as I have been in Scope......BUT the difference in mix clarity between an ITB stereo output vs a fully separated outboard console (with what I have) is freakin chalk & cheese.....
Let's just talk about drums for a sec. I do/process these on a 2nd/separate XP Scope machine, via midi, triggering Slate Drums, which is hosted in V-Stack (if anyone remembers that little gem of a VST host). I can then process the drums with UAD1 and other 32 bit toys before then spitting out to Scope (for further processing), before then coming out for submixing on the outboard console. I've tested between a single stereo drum bus output and a properly separated multi-channel output scenario and it's an insane difference.
All I'm needing now is the main DAW to play ball with some form of interface to get audio separated out to the console, ideally having UAD. Since I have 32 channels I/O via A16U's makes sense to keep these convertors. I'm clearly pushing s%$# uphill with the current rig. Scope may be an amazing system, killer as a standalone, with everything It can do, it arguably has no equal. BUT, I'm just not winning here with it in my set-up as the main handler of audio in 2020.
The RME RayDATpci-e looking like a good option - no PCI bridging, a single pci-e, 32 ADAT out that I can hook A16U's straight into - seems it's a product focused just on audio routing & stability/performance in this regard - simple
If there's anything I've missed or something else I should try open to any suggestions before I concede defeat and take a different path.....
Yes I could look at combined reduction of outputs and plugins but that defeats the benefit of my overall set-up / how I want to work / achieve the sound I know is possible (with simply click free audio performance) etc.........If I've got it so wrong here, how the f$%& do "proper" studios achieve multiple outputs from a computer for outboard mixdown scenarios? What exact gear are they using? Is it some ridiculously high end MADI thing that's like $10K for just 16channels of I/O? Are we asking too much for a relatively low cost /legacy technology set-up? If so, what exactly is the upgrade required?
So since last post system changes:
- internal SATA secondary hard drive to handle audio
- got a powered USB3 hub, shared USB host controller disabled
I'm coming to the conclusion that I've got an issue with ASIO performance and/or UAD plugins on mix down, or both. It could be my particular machine is not good enough, or possibly I'm pushing the limits with the Scope pci factor, may not as simple as that....but either way the system's not performing.
I originally went down the Creamware path (20 years ago about) for it's (relatively cost effective) audio routing / multiple output capacity. I got a Luna and an A16U and went from there. At the time, what triggered it, was that I didn't want to be stuck "in the box". Everything (for me) mixing-wise sounded better, clearer, bigger, wider, more professional, when separated out and summed externally even on cheaper outboard gear.
Somewhere along the way back then I picked up a UAD1 and brought this into the mix (no pun intended)....Expanded Scope DSP capacity (with additional cards)......Ended up with a fully loaded system on a dual core - 3x Scope PCI + 2x UAD1 - the sound itself was heading towards a good result, but was constantly pushing the limits of the computer / pci bus with outputs and plugins.
So last year bit the bullet with a PC upgrade, which in turn conceded a UAD upgrade, as limited PCI slots in modern systems and wanting to keep/house Scope PCI set-up meant UAD2 options (for PC) limited(forced) to a Satellite USB3 (as opposed to the pci-e options.....make sense/logical?
So now a year or so down the track, seems still the way I want to work is proving not possible as a combination and I need to work out which component to cut loose or change out.
So I've got rid of the external USB drive, but this hasn't changed or improved anything from a performance. It seems the USBPORT.SYS issue is still occurring when the UAD2 is processing, but I find this confusing as isn't this UAD a USB3 device and handled separately via different drivers and controllers? Again my technical knowledge/understanding lacking in this area.
So a few "tests" showing Latencymon on the same Cubase mixdown session, testing various combinations of either (a) multiple or reduced/stereo ASIO output and (b) UAD2 in or out of the picture. Just to clarify, session has only around 16 channels of actual audio running here. There is 1x midi track for the drums that triggers a separate machine so NO VSTi's, we have 4 channels of mono vocals, mono bass, 3x stereo guitars, 3x mono guitars, 1x stereo keys/organ & 3x FX sends (delay/reverb) - it's not that heavy in terms of playback
1. Fully loaded, multiple ASIO out, UAD2 across various outputs - this is the scenario I'm aiming for
Clearly a failing combination
2. Totally Ditching the UAD2 & plugins removed from session - (ie UAD satellite turned off , computer rebooted), but keeping multiple ASIO outputs
Unfortunately still not great
3. Kept UAD loaded, reduced ASIO to stereo output only
Actually worse!!
4. Nothing - No UAD, Stereo outputs only
Success!!!.......well, not really as I may as well be back in 2001, stuck ITB with just a DAW and native plugins
OK, so what I've come to / concluded is this:
1. UAD2 is not performing either way, with multiple or reduced ASIO
2. Scope is not performing with multiple ASIO outputs, so can't mixdown via console/ouboard in this set-up
3. Scope performs but with limited ASIO and just use native DAW / processing
If I go back 15 or 20 years as to what my aim for making & mixing music was in my studio, (and still is), that is to maintain outboard mixing environment, I'm clearly not winning trying to achieve it with Scope and a current PC / DAW system.
I think it's come time for looking at an alternative way of getting audio out of my computer if that's what I want to keep trying to do. As this is what it seems is the main sticking point. So why am I pushing this path so hard? well (a) sound and (b), creative workflow and using the physical gear I have aquired/invested in and know inside out.
The difference in the "mix", in having say UAD processing in or out, is arguably not so significant as there are ways of achieving vintage emulations with alternatives natively, or as I have been in Scope......BUT the difference in mix clarity between an ITB stereo output vs a fully separated outboard console (with what I have) is freakin chalk & cheese.....
Let's just talk about drums for a sec. I do/process these on a 2nd/separate XP Scope machine, via midi, triggering Slate Drums, which is hosted in V-Stack (if anyone remembers that little gem of a VST host). I can then process the drums with UAD1 and other 32 bit toys before then spitting out to Scope (for further processing), before then coming out for submixing on the outboard console. I've tested between a single stereo drum bus output and a properly separated multi-channel output scenario and it's an insane difference.
All I'm needing now is the main DAW to play ball with some form of interface to get audio separated out to the console, ideally having UAD. Since I have 32 channels I/O via A16U's makes sense to keep these convertors. I'm clearly pushing s%$# uphill with the current rig. Scope may be an amazing system, killer as a standalone, with everything It can do, it arguably has no equal. BUT, I'm just not winning here with it in my set-up as the main handler of audio in 2020.
The RME RayDATpci-e looking like a good option - no PCI bridging, a single pci-e, 32 ADAT out that I can hook A16U's straight into - seems it's a product focused just on audio routing & stability/performance in this regard - simple
If there's anything I've missed or something else I should try open to any suggestions before I concede defeat and take a different path.....
Yes I could look at combined reduction of outputs and plugins but that defeats the benefit of my overall set-up / how I want to work / achieve the sound I know is possible (with simply click free audio performance) etc.........If I've got it so wrong here, how the f$%& do "proper" studios achieve multiple outputs from a computer for outboard mixdown scenarios? What exact gear are they using? Is it some ridiculously high end MADI thing that's like $10K for just 16channels of I/O? Are we asking too much for a relatively low cost /legacy technology set-up? If so, what exactly is the upgrade required?
Re: Scope PCI cards clicks & pops - Windows 7 & Cubase 10
i guess it just depends on what is more important, this computer that is either set up incorrectly, or just does not work, correctly, or the UAD and Scope and outboards and audio...
i am using Windows 10 in 2020 and i do not have these problems, ever. i use Scope exclusively as an interface with vstis and outboard, believe it or not.
the RME is a good product.
i am using Windows 10 in 2020 and i do not have these problems, ever. i use Scope exclusively as an interface with vstis and outboard, believe it or not.
the RME is a good product.
Re: Scope PCI cards clicks & pops - Windows 7 & Cubase 10
ATAPI? Is there still an external volume going in this case, or are you using software to load ISO's and the like?
-
- Posts: 43
- Joined: Sun Jun 01, 2014 5:15 pm
- Location: Geelong, Australia
Re: Scope PCI cards clicks & pops - Windows 7 & Cubase 10
My time is the most important, for making music & the associated creative process, everything else gear related just supports that pursuit - if I didn't have to use a computer to work/layer tracks I'd happily do so. I'm not wedded to Scope specifically as is primarily just an audio interface/management tool for me (rather than instrument for synths etc, although I do have a separate Scope synth rig on a separate machine running as standalone). I've tried different workflows/say used various multitrack options over the years but the convenience/flow editing & flexibility of DAW's always drew me back into a computer environment to produce music and have it all laid out an managed on a dual screen, as opposed to a crappy little display. But I hate the bloated factor of Windows. Wish something existed like stripped down OS machine that all you have is the DAW of choice & plugins and audio routing. I probably could live without UAD if push came to shove as there are native alternatives, but it would disappointing as some of their emulations are nice. BUT I wouldn't give up my console / outboard mojo factor. You can interchange plugins for similar results, but there's something definitely "3D" about the outboard/console sound that (to me) nothing ITB I have found comes close to achieving.......but to be fair I haven't directly compared say a super high end Pre ->converter at high resolution recording which is then mixed ITB. The A16U is my A/D conversion and to me it needs something else, like processing or console summing / separation. I know many people have moved into the complete ITB mixing approach but it's a path I've yet to properly explore, and if I did/had I arguably wouldn't need Scope for what I'm doing.
Totally believe you.....but PCI or Xite? Would you care to share your set-up & PC specs? I'm guessing in my case either it's the way the particular motherboard and/or driver/software is (not) managing the PCI factor well enough...
It seems like streamlined piece of kit setup specifically for managing multiple I/O & routing - I'm yet to hear of anyone having an issue with them, regardless of computer, as long as there's a pci-e slot, and it's looking like a more logical fit for my particularly DAW/studio set-up - it would be an easy swap in/out......compared however with Scope that seems to be very sensitive to the host systems and specific chipsets etc.......the first sound card I owned was a digi96/8 PAD & still have it in another machine - it's been swapped over a few different machines over the years. It's 20 years old. Simple, stable and still rock solid. At the time I would have stuck with RME but Creamware had the phyiscal I/O options with A16U unit - there was nothing else like it for near the same money so I made the switch the best I could with what I could afford at the time....the RME is a good product.
-
- Posts: 43
- Joined: Sun Jun 01, 2014 5:15 pm
- Location: Geelong, Australia
Re: Scope PCI cards clicks & pops - Windows 7 & Cubase 10
Nope, no external volume exists (I'm assuming you're referring to like a CD or DVD drive??)
Why would I load "ISO"'s? Are you referring to when say originally windows 7 was installed from a USB drive??
(The secondary SATA drive is partitioned - (a)Audio Data (b) Sample Library and (c) General Storage....assuming this is unrelated....
Is this strange/ unusual? Why/how would this be running? I've limited any start-up items. I don't understand.........
Could my motherboard be the issue? Should I be considering changing it? It wasn't that expensive but it seemed a suitable fit for the specs for a 3x pci set-up and usb options. But clearly something is a problem here.....I'm open to suggestions
Re: Scope PCI cards clicks & pops - Windows 7 & Cubase 10
audio data and sample library on one disk?
i wouldn't.
even if they're different partitions, it's still the same drive. that might be ok for some, but not others...
Scope cards and XITE are not soundcards. it's much easier to make a soundcard. yes, people get clicks with an RME interface too, but most don't. in fact, most people using Scope don't have a problem
i have both XITE and PCI. both work. if you want to use them, then you have to know their limitations and build accordingly. my Scope hardware has outlived many computers. it always has worked, too. i have music on the radio. i spend as little time and effort on the computer as possible, and as much time on music as possible. that means the computer works correctly or i chuck it in the recycle bin, and get another. the exact hardware is almost irrelevant. most computers work. some new components just suck out of the box, there is always a failure rate in construction of processors and motherboards and ram and power supplies and video cards. nobody makes 100% perfect runs of electronic goods.
i don't know. it's possible that whatever you use will disappoint you(maybe not). i can't see or touch your system to know what you are doing and how you are doing it. you shouldn't have all these troubles, though. what motherboard is that again? personally, while i always look for what is available for the least amount of money, i never buy cheap stuff.
i wouldn't.
even if they're different partitions, it's still the same drive. that might be ok for some, but not others...
Scope cards and XITE are not soundcards. it's much easier to make a soundcard. yes, people get clicks with an RME interface too, but most don't. in fact, most people using Scope don't have a problem
i have both XITE and PCI. both work. if you want to use them, then you have to know their limitations and build accordingly. my Scope hardware has outlived many computers. it always has worked, too. i have music on the radio. i spend as little time and effort on the computer as possible, and as much time on music as possible. that means the computer works correctly or i chuck it in the recycle bin, and get another. the exact hardware is almost irrelevant. most computers work. some new components just suck out of the box, there is always a failure rate in construction of processors and motherboards and ram and power supplies and video cards. nobody makes 100% perfect runs of electronic goods.
i don't know. it's possible that whatever you use will disappoint you(maybe not). i can't see or touch your system to know what you are doing and how you are doing it. you shouldn't have all these troubles, though. what motherboard is that again? personally, while i always look for what is available for the least amount of money, i never buy cheap stuff.