Majiks Ramblings: Roland V-Studio 20 with Linux

Introduction

I recently acquired a Roland V-Studio 20 unit cheaply (£99 from Dawsons). It was a unit I had been interested in, and I have recently been having some discussions about this unit on another forum.

When I saw how cheap it was going for at Dawsons, I had to give it a try. One of my motivations was to see if I could get it working under Linux. This post describes how I got on. It also sort of doubles up as a review and technical description of the V-Studio 20 (VS-20).

Overview of the V-Studio 20

The V-Studio 20 is a computer audio interface, digital FX system and control surface designed for guitar and vocal use. The unit connects to a USB interface on your computer which also powers the unit. There is no option for an external power supply; this has to be used with a computer.

It is designed to be easy to use, and allows you to connect a guitar, bass, or mic directly in (with phantom power support if required). Of course you can also connect any traditional guitar pedals in front of it if you prefer to use them. It also has built in stereo microphones.

The guitar FX and amp/cabinet emulation and vocal processing are based on the latest Roland COSM technology, and you have the option to record "wet" (with FX) "dry" (with FX enabled but not recorded) or to completely bypass the FX. You can also "re-amp" by applying the FX to a previously recorded signal..

Whilst the FX are controlled by software on the computer, the processing is done on the unit itself, not through computer plugins. This means that it places no load on your PC, and can support zero-latency local monitoring.

There are audio line outputs which can be connected to an amp or active speakers as well as a headphone output. The unit also has connections for foot pedal controls.

The control surface has transport controls (stop, record, fast forward, etc.) and faders. These are designed to work in conjunction with software on a PC (the unit itself is not a mixer), and it is supplied with a simple DAW application "Guitar Tracks".

It is also a 24-bit interface which, as I previously mentioned in my Digital recording in a home studio blog, is important to maximise the quality of recordings.

Using with Linux

Drivers and ALSA

Unlike Windows and Mac systems, the approach Linux takes with drivers is different: most of them are already built in. This is because most peripherals are actually based on common standards. When you get a "driver" for a Windows PC, quite often it isn't a program, but really just a configuration file for built-in drivers.

Under Linux, the standard audio subsystem is ALSA (Advanced Linux Sound Architecture). This is equivalent to ASIO on Windows or CoreAudio on Mac. It's a low-level, low-latency sound driver architecture. It has various modules to handle different types of audio interface and protocols. The most common one for USB devices is snd-usb-audio.

With snd-usb-audio, USB sound cards are often completely plug-and-play on Linux, with no driver installs needed.

Unfortunately, whilst most USB audio is fairly standard, there are some vendors that have added additional capabilities, have bugs in their implementation, or are using relatively new or uncommon features. In order to support these the snd-usb-audio module supports a system of "quirks" where a data block can be used to describe a specific device in more detail. Without this data block, some USB audio devices were not recognised by Linux.

Furthermore, to introduce a quirk for a new device requires a new kernel to be built. This is a barrier for typical end-users. In most cases end-users have to wait for someone else to develop the quirk for the device, and for that change to make it through to a production kernel. In the past I have been one of those people who have submitted quirks into ALSA (and, subsequently, into the Linux kernel) for audio devices.

Here is an example of one of the quirks I have previously submitted:

        /* Boss JS-8 Jam Station  */
        USB_DEVICE(0x0582, 0x0109),
        .driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) {
                /* .vendor_name = "BOSS", */
                /* .product_name = "JS-8", */
                .ifnum = QUIRK_ANY_INTERFACE,
                .type = QUIRK_COMPOSITE,
                .data = (const struct snd_usb_audio_quirk[]) {
                        {
                                .ifnum = 0,
                                .type = QUIRK_AUDIO_STANDARD_INTERFACE
                        },
                        {
                                .ifnum = 1,
                                .type = QUIRK_AUDIO_STANDARD_INTERFACE
                        },
                        {
                                .ifnum = 2,
                                .type = QUIRK_MIDI_STANDARD_INTERFACE
                        },
                        {
                                .ifnum = -1
                        }
                }
        }
},

ALSA support for Roland

Earlier last year (2013) a couple of the main ALSA developers recognised that there were an increasing number of quirks being added for some vendors equipment (including BOSS/Roland) and that these quirks were all very similar in nature. They then developed changes to snd-usb-audio which provided generic support for Roland devices so that future per-device quirks shouldn't be needed. These changes are now in the newer kernels and should allow full support for most current Roland and Boss audio cards.

For this support you will need a v3.10 or later kernel. Part of my motivation for purchasing the VS-20 was to test this.

To do this I had to compile my own kernel. I was using an older version of Linux Mint (v13) but even the newer versions aren't using the latest kernels yet. I downloaded and compiled the latest stable kernel release, 3.12.7, installed it, and rebooted. After some shenanigans with my Nvidia drivers, I got it working and checked for the sound card. It was there and worked perfectly.

Jacked up

The default sound system on most desktop Linux systems is Pulseaudio. This sits over ALSA and provides the ability to select between audio interfaces and to adjust input and output levels. It's a very flexible system but isn't really suitable for pro-audio use for many reasons. For pro audio use on Linux, we use Jack Audio Connection Kit (JACK for short). JACK does many cool things, including allowing you to connect the audio or MIDI output from one application into the audio or MIDI input of another.

With the latest kernels, the VS-20 works perfectly with JACK.

JACK allows the user to tweak the buffers in order to balance latency versus CPU load, very similar to ASIO. As I'm not worried about latency too much (due to the built-in monitoring on the VS-20) I set my settings pretty conservatively as shown below:

This gives nearly 35ms delay, which is quite a lot, but it reduces the occurrence of buffer glitches known as "xruns". Low latency is normally only important for real-time audio monitoring. If you are relying on PC based plugins to handle processing, then latency is important as the audio has to go from your sound card, to the PC, through the plugin, and back to the sound card. Each of these adds a little delay to the signal which can all add up to horrible latency unless you tweak and tune your system.

In the case of the VS-20, the processing is all done onboard the unit and there is a zero-latency monitoring point on the VS-20. As such, I don't have to worry about minimising latency.

In and Out

The VS-20 provides a stereo input and output pair, plus two MIDI inputs and outputs. Note the VS-20 has no MIDI synth capability: the MIDI ports are used for control purposes. Here's how JACK reports the device:

Tue Jan 14 13:30:42 2014: Starting jack server...
Tue Jan 14 13:30:42 2014: JACK server starting in realtime mode with priority 10
Tue Jan 14 13:30:42 2014: control device hw:2
Tue Jan 14 13:30:42 2014: control device hw:2
Tue Jan 14 13:30:42 2014: Acquired audio card Audio2
Tue Jan 14 13:30:42 2014: creating alsa driver ... hw:2|hw:2|512|3|44100|0|0|nomon|swmeter|-|32bit
Tue Jan 14 13:30:42 2014: control device hw:2
Tue Jan 14 13:30:42 2014: configuring for 44100Hz, period = 512 frames (11.6 ms), buffer = 3 periods
Tue Jan 14 13:30:42 2014: ALSA: final selected sample format for capture: 24bit little-endian
Tue Jan 14 13:30:42 2014: ALSA: use 3 periods for capture
Tue Jan 14 13:30:42 2014: ALSA: final selected sample format for playback: 24bit little-endian
Tue Jan 14 13:30:42 2014: ALSA: use 3 periods for playback

Note that it reports it as a 24-bit device with a sample rate of 44.1kHz.

Controlling the VS-20

One of the potential stumbling blocks with using the VS-20 on Linux is that it requires a PC based control program to manage and select the COSM effects.

The good news is this works without an problems on WINE. In fact, the filename for the download from the Roland site was "vs20_wine_v100.zip". This was a point and click install for me.

The VS-20 Editor provides full control of the VS-20 through an emulated pedal board model, where patches can be edited, selected and saved. It communicates to the VS-20 through one of the MIDI ports. On Windows the driver names this MIDI port to make it obvious which one to use. On Linux the generic driver just calls the MIDI ports "VS-20 MIDI 1" and "VS-20 MIDI 2". FOr the VS-20 Editor, you need to use MIDI 2.

Here is the VS-20 Editor running on Linux:

Using with a DAW

Using the VS-20 with a DAW at a basic level is as simple as any other sound card. I used it with Ardour 3 and you just connect the JACK inputs to tracks as normal. In fact Ardour normally does this for you when you create a new track.

Setting levels

Setting the recording level is important: there is an "OUTPUT LEVEL" control on the VS-20 itself, but this only seems to control the local output level, not the USB levels.

There is also an INPUT SENS control which seems to be the analogue preamp setting. The VS-20 manual suggests you set this so that the PEAK indicator occasionally goes on to get the best quality.

This may result in the recording level to the USB input being too high. To adjust this you need to use the VS-20 Editor and click on the SETTING button. You will get a pop-up which allows you to configure various settings including REC LEVEL:

This also lets you adjust the audio routing. A good way to approach this is to select the patch you want and then play (or sing) loudly and adjust the VS-20 INPUT SENS control to peak. Then watch the input meters on Ardour and adjust the REC LEVEL on the VS-20 editor so that the peaks are well below full-scale. (10-12dB is recommended).

You can then start recording.

Control Surface

The final piece of the puzzle in getting the VS-20 working optimally with Linux is the control surface capability. Each of the buttons and sliders on the VS-20 is a MIDI control. By mapping these controls to and application like Ardour 3, you can control the transport buttons, faders and so on from the VS-20, which is quite cool.

The only problem I had with this is that the way control surfaces are defined in Ardour 3 is slightly restrictive in that the MIDI feedback cannot be configured. On the VS-20, for instance, the track arm buttons have LED indicators. When you press one of the track arm buttons it sends a MIDI Note On to Ardour, but Ardour assumes that the feedback MIDI message back to the VS-20 should be the same Note On. On the VS-20 it is not. This means that, whilst you can control Ardour from the VS-20, the LED lights do not reflect the status of the controls. This isn't a big issue as under normal circumstances you will have the Ardour screen in front of you, and will read the status from that.

It may be possible to use qmidiroute or similar to translate the default Ardour feedback into the correct MIDI event, and I may experiement with that. For any Ardour 3 users, the MIDI Control surface definition is attached below:

<?xml version="1.0" encoding="UTF-8"?>

</ArdourMIDIBindings>

Majiks Ramblings

Tuesday, 14 January 2014

Roland V-Studio 20 with Linux