Category: Computers (Page 1 of 2)

Front Panel:

My nomenclature, from left to right: F1 – F4

Rear Panel:

My nomenclature, following a U-shape from top left to top right: R1 – R7

Type (according to XPS 8930 manual):

 ID   Description                 Speed    Connected 
 --   --------------------------  -------  ----------
 F1   USB 3.1 Gen 1 Type C         5 Gbps  
 F2   USB 3.1 Gen 1                5 Gbps
 F3   USB 3.1 Gen 1                5 Gbps
 F4   USB 3.1 Gen 1                5 Gbps

 R1   USB 2.0                    480 Mbps  Keyboard
 R2   USB 2.0                    480 Mbps  Mouse
 R3   USB 3.1 Gen 2 Type C        10 Gpbs
 R4   USB 3.1 Gen 2               10 Gpbs  Scarlett 6i6
 R5   USB 3.1 Gen 1                5 Gbps
 R6   USB 3.1 Gen 1                5 Gbps
 R7   USB 3.1 Gen 1                5 Gbps  MIDISport 2x2

Here is a report from USB Device Tree Viewer 3.3.6:

Quite by accident I seem to have connected the Focusrite Scarlett 6i6 to its own dedicated high-speed USB hub, which I’m guessing is optimal.

However, we should remember that the USB port on the Scarlett is only USB 2.0. So we’re hopefully gaining some isolation or immunity from interference, but no throughput gains. Chances are we may have another device that could leverage the 10 Gbps speeds…

In which we upgrade our DAW and experiment with PCIe-PCI adapter cards.

ROSSINI has four internal hard drives:

• C: (SSD 256G) OS and applications
• D: (SSD 256G) audio projects
• E: (HD 1TB) backups, rips, temp
• H: (HD 600G), mp3 library; leftover stuff from the last DAW migration 8 years ago

Every time I upgrade my DAW I end up with a new primary OS drive and then I move over the drives from the older machine. ROSSINI was the third generation, and only some of the drives are transitioning to VIVALDI. E: and H: still have gobs of free space.

VIVALDI has a 512 GB SSD as the primary drive (it’s a tiny thing mounted directly on the motherboard!) and room for three additional full-size drives.

First up, some file management to back up the contents of D: to H: and also put everything I’ll need (installers, product keys, license files, sound libraries) on E:.

Then, D: and E: transferred cleanly into the new chassis:

I also upgrade the power supply, replacing the no-brand Dell 450W unit with a brand new SMART 600W from Thermaltake. I purchased this from PC Plus in town. Support your local retailers, guys.

(I always upgrade the PSU in my DAW computers, but this time I had an additional reason that I’ll get to later.)

There’s a free bay on the bottom left, but I’ll keep C: and H: in ROSSINI for now to serve as a backup machine for now, and eventually as a perfectly serviceable general-purpose PC. (The 4-core i7-920 is no slouch, really, and it has 16 GB RAM.)

Next Step: Powering up; cleaning up the Windows 10 Pro default installation (I can’t believe the number of options you have to disable to make it bearable); and installing my suite of audio applications, VSTs, and libraries.

That took about a full day.

Now it’s time to see how the Focusrite 6i6 USB 2.0 audio interface performs (see previous post for details of testing in ROSSINI):

Computer: VIVALDI
Interface: Focusrite Scarlett 6i6 USB2.0

Buffer Size  ASIO Reported RTL    Measured RTL
-----------  -------------------- ------------
     256      25.5 ms 1102 samples   0.037 sec
     128      13.1 ms  578 samples   0.020 sec
      64       8.2 ms  362 samples   0.013 sec

The RTL latency tested out exactly the same as ROSSINI! I was expecting better performance but it seems that RTL is not affected by processor speed or core count.

However, if you recall, playback of a large project on ROSSINI at 256 did result in clicks and pops. On VIVALDI, the same project played back smoothly at 128 but started clicking at 64.

Bottom line: It appears I could use the external USB 2.0 Focusrite 6i6 on VIVALDI and get almost the same RTL performance as the ECHO Layla 3G internal PCI card on ROSSINI. I’d call it acceptable.

But we’re not done yet. A few days earlier, a timely post from John Kenn on the Cakewalk SONAR Hardware forum suggested an interesting alternative: using a PCIe -> PCI adapter card. Perhaps we could use the ECHO Layla in VIVALDI after all?

Checking the specs on the Layla PCI card: it’s a half-height/low profile universal voltage PCI card (3.3V/5V).

Worth experimenting with, I think. Ahead of time, I ordered this PCI Express to PCI Adapter Card from StarTech.com for $60, and it arrived just before VIVALDI was shipped:

One catch: I needed a spare molex power connector to supply additional voltage to the adapter card. The generic PSU in the new XPS 8930 did not have any molex leads!

No problem. I was going to upgrade the PSU anyway, I’d just make sure I got one with standard molex as well as the usual MB, FAN, and SATA connectors. The SMART 600W from Thermaltake fit the requirements.

The adaptor card fit snugly into a spare PCIe x4 slot on the motherboard:

It’s sufficiently distant from the GPU fan that I don’t think there’ll be an issue there. (I don’t plan to drive the GPU too hard anyway).

The ECHO PCI card piggy-backs on to the adapter card without trouble:

In the picture above it looks as though the PCI card is having trouble sitting firmly in the PCI socket, but that’s on me – when I took the photo I hadn’t firmly located the two cards together. It’s tight, but they mate well together without using excessive force.

In fact, I recommend connecting the two cards together outside the chassis and then inserting them as one unit into the PCIe slot.  Just for kicks, I’ll show you the result:

Yeah, that’s not going to work as-is. The full-size back plate on the ECHO PCI card is going to have to be modified, or…

The solution is to remove the back-plate from the PCI card, and swap the back-plate on the adapter card with an alternative one that ships with it:

Without a back-plate of its own, the PCI card has more movement than I’m comfortable with, but luckily there’s a lip on the alternative back-plate that the card can rest against, and a convenient hole in the card that I could use to hold the PCI card in place using a little bolt with washers on either side.

Nice, just like a bought one.

Final assembly:

Not bad.

Power up; install ECHO drivers (they still work well in Windows 10 despite only being certified for Windows 7).

Works perfectly. Measurements are IDENTICAL to ROSSINI:

Computer: VIVALDI
Interface: ECHO Layla 3G PCI via PCIe adapter

Buffer Size ASIO Reported RTL     Measured RTL
----------- --------------------- ------------
   256       13.7 ms  602 samples    0.015 sec
   128        7.8 ms  346 samples    0.010 sec
    64        4.9 ms  218 samples    0.007 sec

That’s fantastic. Thanks John Kenn for the suggestion to investigate PCIe-PCI adapters. Apparently they work.

This little piggy, thinks he deserves an(other) upgrade. – The Prodigal Sounds, “The God Program”

“VIVALDI” is the name I have given to my new Dell XPS 8930 tower. It’s a i7-8700 6-core processor with 32 GB RAM because, why not.

It replaces – or will replace – “ROSSINI” which is a Dell Studio XPS 9000, with an i7-920 4-core 8 GB RAM (recently upgraded to 16 GB).

Long-time readers will be experiencing deja vu at this point.

PCI or USB? Or Firewire?

ROSSINI has been super-stable for me over the last 8 years with a PCI-buss audio interface from ECHO, the Layla 3G. 8 inputs, 8 outputs, SPDIF I/O and MIDI… it’s the perfect interface for me.  Ideally, I’d just move the audio card over to the new computer, along with the hard drives.

However, the new boy does not have a PCI card slot. (Good luck finding a modern motherboard that has one!) It only has PCIe, which are smaller and not plug-compatible with the older standard.

I could go on a rant here about how it’s been a long, long time since computer hardware companies gave a damn about backward-compatibility… but nobody’s got time for that.

I was prepared to say goodbye to my beloved Layla, if only I could find an alternative that worked. Not being able to afford a PCIe based interface from RME, I decided to experiment. USB 2.0-based audio interfaces are super-popular right now, because they are relatively cheap, and computers have become fast enough to handle the overhead of pushing the bits around.

I found a good price on a mid-range USB 2.0 device, the Focusrite Scarlett 6i6, 2nd Gen. They’ve had pretty good reviews, but I still didn’t really have an understanding of the relative real-world performance between modern USB-based and PCI/PCIe interfaces.

“Performance” can mean several things in the context of digital audio interfaces:

• digital-to-analog conversation accuracy
• signal-to-noise ratios (noise or hiss generated in the analog circuitry)
• data transfer latency (how fast can you get audio in and out of the computer?)

DAC quality is probably the least of our problems, it’s kind of a solved problem at any reasonable level of affordability.

S/N ratios are interesting because you definitely get what you pay for, especially when amplifying low input levels (such as required of microphone pre-amplifiers). That’s why you’ll see advertising blurbs talk about how “best in class” the mic-pres are on interfaces that offer such features, but no-one really cares about the DACs.

For my purposes, the ECHO Layla’s two microphone inputs have done me just fine, and this is from an interface that was introduced back in a time when having any mic pres  at all was a big deal, let alone who designed them or what the specs were.

I’m really only interested in measuring and comparing the total “round-trip” latency (RTL) of the interface: How much of a delay is introduced by the analog input and output circuits; the Digital to Analog conversion stage, and how the bits are pushed through the buss, in and out of the CPU and hard disks?

There’s more than one way to skin this particular cat (ASIO? WASAPI? WDM?) , so to keep things manageable, I’m comparing two ASIO interfaces, and just varying the buffer size to see what we get. (smaller buffer size = shorter delay; larger buffer size = longer delay but more stability)

Before I took ROSSINI apart, I took some measurements. The ASIO driver can report the latency to the audio software but you can also measure it by feeding an output of the interface back into an input; recording a transient (i.e. a snare hit) and then measuring the delay between the original audio clip and the resulting recording. By swiping in the time-line in SONAR/Cakewalk,  I can read off a measurement in seconds:

Results:

Computer: ROSSINI
Interface: ECHO Layla 3G PCI

Buffer Size  ASIO Reported RTL    Measured RTL
----------- --------------------- ------------
        256   13.7 ms  602 samples   0.015 sec
        128    7.8 ms  346 samples   0.010 sec
         64    4.9 ms  218 samples   0.007 sec

Interface: Focusrite Scarlett 6i6 USB2.0

Buffer Size  ASIO Reported RTL    Measured RTL
----------- --------------------- ------------
        256   25.5 ms 1102 samples   0.037 sec
        128   13.1 ms  578 samples   0.020 sec
         64    8.2 ms  362 samples   0.013 sec

• The measured RTL delay is slightly more than what the ASIO driver is reporting;
• It takes the USB-based 6i6 roughly twice as long to push audio data around the loop than the PCI-based Layla3G.

Conclusions:

• Perhaps there’s another layer of processing outside of what the driver can measure. Disk read/write?
• 11 ms is right around the point at which the delay is imperceptible to humans, and in order to get that on the Focusrite 6i6 I would have to reduce the buffer size down to an unstable level.

A less scientific test was next: I tried loading up one of my projects and playing back through the Focusrite 6i6. Even at a buffer size of 256 , I was getting a regular click or stutter every 8 seconds or so. However I have to acknowledge the caveat that this was not a normal configuration – i was reading the project data from a different location than normal:  H: drive is spinning-metal hard drive and not my usual D: SSD audio drive. So I am not drawing any conclusions from that test. It would have been nice if it had played back flawlessly under those conditions, though, wouldn’t it?

Next step is to see how the USB-based interface performs in the new DAW, with substantially more CPU power available to it. My understanding is that a higher-powered CPU will affect the performance of a USB-based interface more than a PCI- or PCIe-based one, due to the different amount of work performed in software for USB vs. the PCI architecture.

This little piggy, thinks he deserves an upgrade. – The Prodigal Sounds, “The God Program”

ROSSINI is the name I have given to my new Digital Audio Workstation computer. It’s a Dell Studio XPS 9000, with an i7-920 processor and 8 GB RAM running 64-bit Windows 7.

First, the good:

It’s a great case, with plenty of room. I specifically ordered it with only one hard drive. My older DAW, KABUKI, has two hard drives: the OS and software lives on the primary disk, and the SONAR projects and music archive and related files reside on the second. My plan was to lift drive 2 out of KABUKI and install it as the second drive in ROSSINI. This plan worked perfectly.

There was one drawback (dawback?): I also transplanted the PCI audio interface (M-Audio Delta 66) from KABUKI into ROSSINI, but ROSSINI only has one PCI slot, and it is right at the edge of the motherboard, which means that the back panel – the metal strip with the connections on it – is located in the last available slot, right at the bottom of the tower case. The 15-pin D-connector couldn’t actually be plugged in because the curved plastic base panel of the tower case overlapped too far, preventing the plug from aligning with the socket. 

You can sort of see where I’m talking about, in this picture from the Dell web site:

Not a problem: Set big-ass soldering iron to “imolate” and perform case mod. Now there is a nice (well, “scorched”) cutaway in the plastic lip, just the right size for the D-connector.

One reason for the upgrade is because M-Audio finally came out with 64-bit drivers for the Delta-66 (and the other interface I use, the Midisport 2×2 USB). I love the Delta, it’s been rock-solid under Windows XP in KABUKI for the last 5 or so years, so I didn’t see the point in upgrading until I could go fully 64-bit.

A word about Windows 7. I’m only using it because I want 64-bit. Under Windows XP, even if I had maxed out the computer with 4 GB RAM, Cakewalk’s SONAR could only access a maximum of 3.5 GB, and of course it is sharing the 4 GB with Windows itself. Under 64-bit windows, any 32-bit process can access a full 4 GB, if available. And of course, a 64-bit native application is not limited at all.

SONAR 8.5 is available in both 32-bit and 64-bit versions, but I am planning on sticking with the 32-bit version for now. I use a lot of 32-bit plugins – VST and DXi effects and synthesizers – that, although they would probably mostly work in 64-bit SONAR, would require a translation layer. I’m fine with the 32-bit version. A 4 GB memory limit is still more than twice what I was getting on KABUKI. In upgrading to ROSSINI, my sonar projects also have twice as many processor cores to abuse. (KABUKI was dual-core, ROSSINI’s i7-920 has four cores – eight if you count hyper-threading which I’m not sure that I do).

So far, everything is running O.K, although I suspect some kind of memory leak is going on, possibly in the audio driver. After about 30 minutes of working and recording takes, I get a nasty burst of digital noise every time I press RECORD and SONAR stops playback. Well, it keeps advancing along the time line as though it *was* playing back, but no sound is emitted. I’m still working on diagnosing this – there are a lot of places the problem could be stemming from.

Cakewalk SONAR and similar DAW applications allow you to use third party “plugins” such as effect processors or “soft” synthesizers. These plugins – usually VST or DXi format – take the form of DLL files (on Windows anyway), installed somewhere on your local file system. I use several commercial plugins, but there are also many free, high-quality offerings from many different vendors both professional and amateur, available for download from the Internet. After a while, your hard drive can be littered with DLL files in various locations. In my case, many of these I have downloaded, installed, evaluated, and rejected, but left around in case I ever want to try them on something else.

So when it comes to backing up your system, it would be nice to know which plugins you are actually using! Unfortunately, in SONAR at least, there is no convenient way to list the plugins in use in a project. I asked this question on the SONAR forum, and received a couple of helpful replies, but I am happy to report that I have found another way:

You will need a utility called Sysinternals Process Explorer, which you can download from that link.

• Run SONAR and load up your project (or projects).
• Run Process Explorer. You will see a list of all the applications and processes currently running.
• Locate and high-light SONARPDR.exe in the list. (That’s Sonar Producer. I do not know what name Sonar Studio would have.)
• Press Ctrl-L to toggle the display of the lower pane, then Ctrl-D to display DLL files(instead of file handles).
• Right-click on the column headings and choose Select Columns… and enable the [x] Path checkbox.

At this point you might see something like this:

This shows all the DLL files that SONAR has referenced as it loaded the project. I’ve clicked on the Path column to sort the list by file location, to make it easier to see the plugins differentiated from the other support files that SONAR uses. At that resolution it is difficult to read the text, so here is a portion of the image at normal size:

Here we can see that the project I have loaded is using TruePianos, Vintage Channel 64, pretty much all of the Sonitus FX suite, and Arturia’s awesome CS-80V. Oh, and a free audio “chopper” effect I downloaded from somewhere on the Internet called Gate3.

Once I’ve noted these down, I can switch to Sonar and load a different project, then switch back to Process Exporer and refresh the list with the F5 key. I will see a different set of DLL files. 

Interesting point: It seems that when you close and open a new project, not all the plugin DLLs will necessarily be closed. For example, when I switched to a project that used XLN Addictive Drums but did not use Arturia’s CS-80V, the AddictiveDrums.dll showed up in the list, but the CS80VDx.dll stayed visible (the CS80V.dll, however, did not remain in the list.). So if you want to be completely sure to see only those plugins used in the project, close SONAR and repeat the steps above for the next project.