/ Reference / Audio Trouble-Shooting

mic speaker
Wherein we collect notes on trouble-shooting your audio configuration.

If you are new to the world of Audio IO, please review the Nuts and Bolts section below.

If you're an old pro looking for specific Fiddle+ChucK routing details there's another place for that.

Operating System Audio Configuration

The most common way to manage your audio devices is through the Operating System configuration tools. These settings are generally adhered-to by Fiddle but, as we see below, you may wish to configure ChucK's VM options to differ from the OS defaults.

Fiddle uses the OS device settings for its sound playback features. Fiddle doesn't access your input device(s) directly. However, it may request access to the microphone so that the ChucK sessions that Fiddle launches can record input signals.

Here is a quick summary of the places where the rubber hits the road for your favorite operating system.

Windows

• The mic taskbar icon is displayed when an application is accessing your microphone.
• The volume_up taskbar icon can be accessed to verify your current output device.
• Input and Output devices are configured via the Sound Settings Panel.
• Input Device Access is configured via Microphone Permissions and also via prompt when first starting ChucK.

You can find these panels by entering these keywords into the search field of the Task Bar.

MacOS

• Input and Output devices are configured via the Sound panel in System Preferences.
• Input Device Access is configured via the System Preference panel under Security and Privacy / Privacy / Microphone and also via prompt when first starting Fiddle.

Linux

Given the diversity of the Linux platform, it's very hard to provide single instructions for controlling your sound driver setup But you already know that. That said, your System Settings may have a Hardware section that includes the Sound panel where Output and Input devices can be configured via GUI.

At the lowest level ALSA is usually the default sound driver atop which sits the PulseAudio layer. Sound professionals seem to prefer the jackd system and so we install this during a default Fiddle installation.
This is done so we can distribute a single build of ChucK that can interoperate with either Pulse or jackd according to your requirements (more below).

ChucK Device Selection

Since ChucK is where most of the audio IO action resides, configuring your audio options for ChucK is actually the higher priority.

ChucK can be configured via ChucK Panel's vm options. The default behavior is to match the OS default sound settings and if you aren't doing live recording, the system defaults are likely perfectly serviceable. But to afford you the the most flexibilty you can explictly request a sound driver via ChucK's invocation options.

chuck --driver:<name> ...

Here are per-platform notes on driver options.

On Windows, ASIO4ALL is a convenience shim that doesn't guarantee the ASIO performance benefits to all devices. Use with care, but select ASIO to connect to it.

Nuts and Bolts of Digital Audio

Elsewhere we discuss the idea of importing previously recorded sound into your compositions. Here, the focus is recording "live" sounds where concepts of feedback and latency rear their ugly heads.

The process of capturing an audio signal for processing in a DAW is referred to as recording, digitizing, or AtoD (Analog to Digital Conversion). The inverse of this process, converting a digital audio signal to an analog signal, is referred to as DtoA (Digital to Analog Conversion).

First, it is actually the job of your computer's sound capturing device to perform the actual AtoD and DtoA conversions. Your computer may have multiple input devices and only grant recording access to your DAW with your permission. So the first requirement for recording is to verify that your device actually shows up in the operating system and that you've granted Fiddle/ChucK access to your device(s). The topic of installing and configuring an audio IO device is touched upon above, but mostly beyond the scope of this document. When battling your OS to achieve device connectivity keep in mind that it's a lot easier than it used to be.

Assuming that you've succeeded in getting your OS to acknowledge your Audio Device(s) the next issue is to introduce your DAW to the OS. The combination of OS and DAW matches a device driver with audio devices (built-in or external), to produce a digital audio stream that can be consumed by a DAW or conveyed for output to them. This aspect of the audio pipeline is probably the most confusing. In the most general setting any audio application can communicate with any audio device in the way chosen by the app.

Most apps fall back to the default configuration presented by the OS, but DAWs often expose the driver selection to users in order to offer the best quality and most flexibility. Different drivers offer tradeoffs between exclusive access, producing the lowest latency, and shared access, producing the most integrated experience with all other audio signal on your system. Since sound recording and monitoring is so central to many music productions it is usually the case that you'll want to think of this as a special-case from the other uses of audio on your system (like listening to SoundCloud). So, for example, in Windows you might use ASIO for your DAW and even route the ASIO output signal to a separate set of speakers or headphones. To listen to SoundCloud you might use the built-in Direct Sound driver. This hybrid solution is a bit of a pain but reduces friction when moving between media production and media consumption.

When setting out to record live, you must carefully consider the implications of feedback. If your monitoring of the input signal can be sensed by the analog pickup device(s) (mic, guitar) that you are recording you'll get feedback which can ruin the recording, your equipment or even harm your ears. For this reason its very common to use headphones to monitor the progress of your recording. Of course this means that you have to figure out how to route the output sound to your headphones and even decide whether you'd like to monitor the signal at the input or output side of the sound production pipeline. Many USB audio interfaces like Focusrite Scarlett, the M-Audio Air or the Tascam 102 offer you these choices as well as an option to mix the input and output signals.

The lag between when a note is struck and when the digital representation of the note reaches your DAW is known as the recording or input latency and can depend heavily on your computer + driver configuration. The smaller the input latency, the better. If your input latency is greater than 10 milliseconds it may not be a workable configuration. Once your DAW gets a hold of the digital signal it can introduce processing latencies. Complex effects-chains are usually the source of such latencies so its best to keep a lid on heavy effects during live recording and add them offline.

On MacOS, the device driver issues are usually a non-issue because Apple paid a lot of attention to the requirements of audio professionals when creating OS X. On Windows and Linux, the story is more complicated. For Windows, the built-in Direct Sound driver is often unacceptable for live recording due to its significant latency. Windows audio professionals seems to favor the ASIO driver model that is built-in to the USB audio-capturing devices mentioned above. As for Linux, well your mileage will certainly vary and may depend heavily upon your sysadmin chops. The Pulse Audio system seems to offer the same desktop integration advantages as Windows Direct Sound and after many years appears to be the closest thing to a standard on Linux distros. But for audio professionals, jackd appears to be the standard choice, presumably for similar factors that make ASIO the choice on Windows.