Front Panel:

My nomenclature, from left to right: F1 – F4

Rear Panel:

My nomenclature, from left (top) to right (down) : 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…

This is an update or re-write of an earlier post from 2014, titled “A work-around for Sonar’s Timeline Editing behavior: Slippy Clips”. It was really more of a case study than a work-around…

Since then, Cakewalk’s SONAR has been reborn as Cakewalk By Bandlab and includes many updates and new features, including “Ripple Editing”. This makes timeline editing much more convenient, and therefore I think it is time to revisit this case study.

So I have this project that contains a mixture of 7/8 and 4/4 bars. For example, in this section I have a series of 7/8 bars followed by a 4/4 at bar 26.

Whilst practicing the keyboard solo, I realized that one of those 7/8 bars needed to be 4/4 also. However, if I change bar 24 from 7/8 to 4/4 by inserting a meter change at bar 24, this happens:

All the measures following bar 24 are no longer aligned on the beat. In fact, the meter of all bars following 24 have changed from 7/8 to 4/4, until bar 26 and 27 which have explicit meter declarations of 4/4 and 7/8 respectively, in the timeline.

This suggests that we also need an explicit declaration of 7/8 meter on bar 25 so that only bar 24 is affected by our initial meter change:

Of course we still have our clips offset from the underlying measures… The easiest way of correcting this is to enable “Ripple Editing” for all tracks and slide the clips into alignment.

First, to enable Ripple Editing we use the control in the top right of the track view to toggle it from “Off” to “All”:

Then we can simply drag the clip at bar 25 into alignment:

The Ripple Edit setting automatically includes all other clips in the timeline (on ALL tracks) along with the one we’re relocating. Handy! The Snap To Grid feature is very helpful to ensure that the clips move exactly 1/8 note to align to the start of the measure.

Before we do anything else, however, we should restore the Ripple Editing setting from “All” to “Off”, because if you forget that it is enabled while moving clips around, you can very easily mess up your project.

These kinds of edits are much easier with Ripple Editing! Thanks to the Cakewalk Developers for implementing it.

I’m writing this post mostly to remind myself how it’s done.

Overview: I’ve got a nice setup in Guitar Rig, including a virtual volume pedal,  and I really want to be able to control it using a MIDI controller foot pedal.

Step 1 – Add an audio track for our guitar, to capture the guitar performance.
You’ll also want to select the appropriate input channel on your audio interface.

Step 2 – Put an instance of Guitar Rig in the FX bin, and select our super-awesome patch:

Step 3 – Using the VST2 drop-down menu in the plugin header, select “Enable MIDI Input”:

Step 4 – Add a MIDI track to capture the MIDI controller data.

Step 5 – Assign the appropriate input channel for the MIDI track.

In my case, MIDI control data will be generated from my Roland A-80 controller keyboard with various pedals connected to it, connected to the Midisport 2x2 In A, so I assign the input channel thusly:

Step 6 – Assign the output channel of the MIDI track to the Guitar Rig Plugin.
This is possible because we enabled MIDI input in Step 3 above – we get an option to select the plugin as the destination for the MIDI data in the output channel list:

Step 7 – Define a controller inside the Guitar Rig plugin

Go to the Options > Controller tab in Guitar Rig, and click on “Add Controller”.

At this point, a “New Control” module appears in the Controller list in Guitar Rig.

Step 8 – Click the “Learn” button and wiggle the controller’s foot pedal:

Notes:

• Obviously the controller must be turned on!
• Assuming the foot pedal has been assigned to CC#4 (which is typical), you should see the controller number appear against the control definition in Guitar Rig.
• For diagnostic purposes, it helps to have the meters in Cakewalk displaying incoming MIDI messages.

Step 9 – Assign the controller to the Volume Pedal

In the controller list, click on the Menu button and select Volume Pedal > Pedal

At this point, moving the expression pedal should be reflected in Guitar Rig’s UI as moving the volume pedal level:

If we now arm both tracks for recording, we can record the guitar audio and the MIDI controller data at the same time, capturing the performance.

The “Producer” tier of Cakewalk’s SONAR has included bundled 3rd party plugins over the years. Some of these were “limited” editions, and some were full products. It’s had some kind of amplifier simulator plugin ever since version 8, I think it was Guitar Rig 3 LE (limited edition).

Most recently prior to Cakewalk’s BandLab acquisition, it included a special “Cakewalk edition” of Overloud’s TH3. Now that Cakewalk (formerly known as “SONAR”) is distributed at no charge by Bandlab, it does not include any bundled 3rd party plugins.

At some point I installed IK Multimedia’s AmpliTube 3 which could be downloaded for free back in 2011. (It’s now at version 4.)

Since then I must have taken advantage of one of the periodic bargain upgrade prices for Guitar Rig, because on my DAW, the full version 4.0 was installed. This week I upgraded Guitar Rig to version 5.

These are all good products, but I haven’t really explored them in detail because I tend to use hardware FX for guitar and bass recording, specifically the Line6 POD 2.0, with which I’ve always obtained good results.

But creativity is fostered through experimentation and playing around, which brings me to this month, in which I re-wired my bass in stereo, and started playing around with amp simulator plugins. Specifically, parallel effect chains for the stereo bass signal.

I got interesting results with the time-limited demo of the full version of TH3, but the Cakewalk edition that I have installed is too feature-limited. The full version TH3 is no longer supported, and it costs more money than I’m comfortable with to get to the current offering, TH-U.

I’ve had more luck with Guitar Rig 4, partly because it is a “full” product. When I checked the Native Instruments web site, I saw I could upgrade to the latest version 5 at a very nice price, so I did – even though it hasn’t been updated since 2011.

Guitar Rig (like its brethren) provides a container in which you can build a series of virtual effect units and amplifiers and speaker cabinets into a customized signal chain. This is pretty cool, but it does lack the interactivity of a physical pedalboard, unless you pair the software up with a special hardware controller, such as the Rig Kontrol:

This physical pedalboard plugs into your computer via MIDI or USB and can talk to the virtual effect rack. You can enable or disable effects in the chain, or manipulate volume or wah pedals.

Unfortunately, it is no longer supported, although you can find them on ebay, reverb, etc.

On the plus side, if you have a MIDI controller in your studio (such as a keyboard with an expression pedal) then you can use that instead. Which is what I’ll write about next.

This is going to be a somewhat random post but I want to record this before I forget what I just found out.

I was playing around with Arturia’s CS80V when the patch I was playing suddenly changed: the release time increased. Also I could see the patch had changed because an asterisk appears in the patch name.

I reset the patch by selecting it in the browser, and continued playing. Suddenly, it happened again!

This time I watched the GUI of the synth to see if I could see it happen:

Sure enough, about a minute later the patch changed sounds and something caught my eye – a slider had changed positions:

Moving the slider back restored the original sound (although of course, the patch was still “changed” as far as the environment was concerned).

OK, how to diagnose this? I’ll cut a long story short and say eventually I set a track to record MIDI data from my controller, in case something funky was entering the MIDI event stream, and played a few notes.

A short time later, I had this:

Those vertical lines are Continuous Controller (CC) events:

I was recording on Track 2 and that’s three events for Continuous Controller 83 that I can’t explain.

I need to find out why my Roland A80 master keyboard is emitting these controller events. Is this new behavior, or has it always happened?

Normally they are harmless, I guess, but the default MIDI Controller mapping for CS80v  has CC# 83 mapped to this VCA envelope release time slider:

So that explains the phantom finger on the slider. The ones in RED have been set to respond to a specific CC#.

It’s easy enough to fix – we can use the MIDI Mapping feature in Arturia’s software instruments to load an “empty” controller mapping:

Now the patch remains unchanged even when I play back the track containing the controller data.

Next up, find out why the A80 is emitting those random controller values...

Modern digital audio workstations offer a plethora of ways to solve your mixing and routing problems. Inspired somewhat by Craig Anderton’s latest column in Sound on Sound, I discovered a new way to apply reverb selectively to multiple tracks, in Cakewalk By BandLab using the Sonitus Reverb VST. Here’s my use case:

I have Lead and Backing vocal tracks, and I want to apply a long-tail reverb to portions of the verse and chorus phrases. (The main sustained notes provide a wash of reverb in the background, but keeping it clean and un-muddled by fricatives and fast syllables.)

In the past I have created a “VOX FX” Buss, put an instance of Sonitus Reverb on it, and directed it to feed the “VOX” main buss. Finally, I add a Send on each vocal track to feed the VOX FX, and use “Send Level” automation on each track:

This works well, and allows the automation curves to be adjusted per-track.

But what if you have more than two tracks, and per-track envelopes isn’t needed? Could there be a way to send audio to the reverb using a single automation curve? I experimented with using an Aux track, intending to add a send on each vocal track to the Aux track, then use the “Automated Send To FX Buss” trick described above.

However, I realized that I could simplify things by putting the reverb effect on the Aux track itself, and then automating the “VST Input Level” instead:

From the Edit Filter selector (displaying “Clips” by default) we can drill down into the Sonitus Reverb and select “Input” from the automation choices:

Now we can draw the automation envelope (only one is needed) to control the amount of audio from all tracks being processed by the reverb:

This gets the job done, and no need for a general purpose fx buss.

As I mentioned above, there are good reasons NOT to do it this way – but it is nice to have the option.

UPDATED 27 Sep 2019

It seems you can’t “freeze” an AUX track, so if you find yourself in the resource crunch and the FX bin on the Aux track is CPU-heavy, well, that’s another good reason not to use this technique.

So much for keeping a regular Studio Diary… where did the time go?

In my defense I will say that the 2019 brought a long-awaited, real-world landscaping project into being, and that has taken a lot of attention.

On the other hand, since the last update I have completed two new tracks:

“The Toks Invade Bogland” was finished up last year and sounds pretty good. I’ve moved on to the song sequence titled “The God Program” and just finished up the first piece in the sequence, a solo piano overture of sorts, called “The Cathedral of Hosts”.

I really wanted to be able to perform the piano part right through from beginning to end, and to record a complete single take, and I almost did it. The truth is that I did end up tweaking a few bum notes (bad velocity). This took a lot of practice!

This quiet, contemplative track contains many musical themes and motifs that are expanded on in later sections of the song sequence:

The first sound you hear is the Roland VK8 keyboard, a “virtual clonewheel” that emulates a hammond organ. I’m using a shimmery patch as a background pad.

The piano is Modartt’s Pianoteq 4, using the “D4” model. The latest version of Pianoteq is actually 6, but they’ve tweaked the piano model and replaced it with a Steinway-endorsed “Steinway D” model. I tried using the more recent versions and ended up going back to version 4, which for some reason has a nicer character for this track.

At about 1:30 you can hear the FingerFiddle IOS app with which I perform the strings (violin and cello). This is a very cool app that requires a fair amount of practice to sound decent, almost like a “real” instrument.

At 1:55 there are some “Ahhh” vocals padding out the sound, and shortly after that a Marimba that is actually a combination of another instance of Modartt Pianoteq (version 6 this time) doubled with Native Instruments’ FM8 for extra DX7-ish bite.

The new DAW is running well. Cakewalk by Bandlab, the re-branded Digital Audio Workstation software formerly known as “SONAR” is probably the most stable it has ever been, with regular updates that focus on bug fixes rather than new features, although there are some of those as well.

Recommended, as ever.

Next: taking the demo of “Enlightenment”, the second part of God Program, and turning it into a finished track.

Onward!

I can’t remember exactly when I purchased my Korg EX-8000, but based on archival recordings, it must have been around 1991. It made the trip across the Pacific from New Zealand back in 1999, and it has been in storage for roughly the last decade, along with other items of equipment that I don’t have room for in my tiny studio.

At this point, I’ve decided that someone else should be enjoying this 8-voice DCO synthesizer with analog resonant filters of goodness, and I should find another home for it.

Before I can do that, I have to make sure everything is still in working order.

In the case of synthesizer keyboards and modules, providing the item has been stored correctly in a cool and dry location (which of course is the case here), then the most likely problem will be that the patch and configuration memory storage has been lost due to the internal battery running out of charge.

Indeed, this was exactly the case. Upon plugging the EX-8000 into my Philmore ST-1000 heavy duty step-up power transformer, 220V output, I discover that no sound can be produced from pressing the keys on a connected MIDI keyboard, but that pushing the “A4” button on the front panel will produce a “tick”. Reviewing the parameter values, clearly we have a corrupted memory because some of the values don’t make sense, although spinning the value editor dial will soon bring them back into line.

With some tweaking I can turn the “click” into a siren or “bloop”. Progress! All 8 oscillators appear to be in good shape, providing I can restore the memory.

Alas, upon bouncing the power on the unit, all my parameter edits have been lost. The backup battery is almost certainly the culprit. Time to open her up!

Replacing the battery

1. Remove the rack-mount ears

2. Remove 6 screws holding the cover in place (2 each side, and at the back)

Apart from the power supply and the I/O boards, the two main boards of the synth are in a sandwich configuration. You can remove 3 screws and swing them up on a kind of plastic hinge:

You need to do this to access the battery, plum in the middle of the underside. I use a ruler to carefully prop the boards upright.

I could see some green crusty stuff around the battery which isn’t a good sign.

Okay, now the bad news here is that the CR-2032 battery is actually soldered directly into the PCB via a little bracket. You can’t just pop the battery out and replace it. The only sane option here is to remove the lower PCB from the chassis and replace the battery+bracket with a true low-profile socket.

Fortunately, this is not too difficult. I recommend taking a lot of pictures of the cables and connectors to make sure you know how they are laid out and connected.

3. Unplug all cables from the board

4. Unscrew the four screws at each corner holding the PCB to the metal brackets

WARNING: The two orange pin arrays on the bottom right are soldered directly in, they are not plugs!

Instead, you need to trace them to the other end, around the other side of the sandwich, and unplug the other end from the “top” board.

Then you should be able to remove the board from the unit:

Replacing the corroded battery and bracket is very easy if you’re handy with a soldering iron and a solder-sucker. The socket I used didn’t quite line up with the vacated holes in the PCB, but a little wire lead and some silicone caulk (and some heat-shrink) yielded a nice result:

After a new CR-2032 battery is inserted into the socket, and the board mounted safely back in the case with the leads re-attached (refer to those pictures you took!), and a quick test proves that any parameter change I make is retained during a power cycle. Hooray!

Restoring the default patches

Fortunately, other folks have done the hard work on finding the patches, and restoring them turns out to be more-or-less straightforward.

There’s two ways to restore patches:

• Play a .WAV file into the tape FROM port on the unit
• Use a SYSEX loader to load the patches in via MIDI

Tons of good information here:

• https://www.muffwiggler.com/forum/viewtopic.php?p=606314
• http://www.dw8000.com/downloads.html
• https://www.pallium.com/bryan/dw8000.php
• https://www.pallium.com/bryan/dwpatches.php

After some initial trouble of getting levels set correctly, I succeeded using the .WAV file following this process:

• Email the .wav file to myself as an attachment
• Open the email on my iPhone
• open the attachment
• connect iPhone to the TAPE FROM socket using a normal stereo 3.5 mm jack lead
• set my iPhone playback (headphone) volume to MAX
• switch the EX8000 FROM TAPE level switch to LOW
• switch the EX8000 TAPE switch to ENABLE
• press LOAD
• tap the iPhone to start playback of the .WAV file

After some flashing, the bank numeric indicator cycled through the banks, and the LED display said GOOD. Success! Those patches sound great.

Switching power supply from 230V (New Zealand) to 120V (US)

The final step in getting the Korg EX-8000 ready to leave the studio is to convert it to use a 120V mains supply voltage. When I started this process, I figured I’d need to replace the mains power  transformer but, no, it’s way easier than that! The transformer already handles multiple voltages. From the service manual:

Yeah, that ‘former has multiple taps on the primary side. In real-life:

Although you can’t see it in this image, the terminals are actually labelled with the numerical identifiers. On my unit, the mains leads (black+yellow) deliver voltage to terminals 1 and 6. According to the schematic, that matches a 240V supply, which is best match for the NZ mains voltage of 230 V.

The schematic offers both 117V and 100V terminals (3 and 4) and suggests that terminal 4 should be used by default – It would be nice to think that the Service Manual is assuming a US standard mains supply, but that’s probably not a good assumption. The Service Manual says “Tokyo/Japan” on the front page, and Mains Voltage in Japan is 100V.

In the US, it’s 120V, although it used to be 117V. Terminal 3 seems like a better choice.

The PSU board has three connectors – CN2A, CN3A and CN4A – which I disconnected to protect the rest of the unit from any screw-ups in voltage changes.

Then I tested the voltages coming out of the transformer and measured 10 VAC from Black to each of the Red wires.

On CN3A I measured 5 and 10 VDC from the center pin to each of the outer pins. That’s our baseline, our known “good” values using the 220V mains supply.

The CN3A lead indeed does go to board KLM-662, and according to the schematic, should be supplying 0, –5, and +5 V on pins 1, 2, and 3. (See above).

So, that matches my observations (-5 : 0 is +5; and –5 : +5 is +10).

At this point I performed some soldering: Moving the black lead from pin 1 to pin 3 on the primary side of the transformer; and also replacing the mains socket from the proprietary 2-pin KS-17 to a more common IEC standard appliance socket.

See: http://www.dw8000.com/projects.html

Once that is done, it was time to plug into the regular US mains and re-test those voltage readings. Excellent, all looked the same as before. Could it be this easy?

Apparently, yes. I’ll run it for a while on 120V in my studio, and see if anything blows up. Either I’ll fall back in love with this sound module, or I’ll see about putting it on CraigsList or something.

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

Some observations:

• 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.