Wait for (Audio) Hardware in systemd

Wait for (Audio) Hardware

In some cases it can be necessary to wait for a specific device, like a USB interface, before starting a service with systemd. This is the case for the JACK server in some setups.

With system.device

''systemd.device'' makes it possible to let services depend on the state of specific hardware. The following instructions work only for a static hardware setup and can fail if the hardware configuration is changed.

First: Find if systemd has a unit configuration file for the device. The following code lists all devices:

$ systemctl --all --full -t device

This will be a lot of output. Narrow down the search by grepping for the ALSA name of the device - in this case 'Track':

$ systemctl --all --full -t device | grep Track

The output looks as follows in this case:

sys-devices-pci0000:00-0000:00:14.0-usb2-2\x2d2-2\x2d2:1.0-sound-card1.device                               loaded active plugged M-Audio Fast Track

The '.device' identifier can now be used in the UNIT description's parts After and Requires:

[Unit]
Description=Jack audio server
After=sound.target sys-devices-pci0000:00-0000:00:14.0-usb2-2\x2d2-2\x2d2:1.0-sound-card1.device
Requires=sys-devices-pci0000:00-0000:00:14.0-usb2-2\x2d2-2\x2d2:1.0-sound-card1.device

Wait for (Audio) Hardware in systemd

Wait for (Audio) Hardware

In some cases it can be necessary to wait for a specific device, like a USB interface, before starting a service with systemd. This is the case for the JACK server in some setups.

With system.device

''systemd.device'' makes it possible to let services depend on the state of specific hardware. The following instructions work only for a static hardware setup and can fail if the hardware configuration is changed.

First: Find if systemd has a unit configuration file for the device. The following code lists all devices:

$ systemctl --all --full -t device

This will be a lot of output. Narrow down the search by grepping for the ALSA name of the device - in this case 'Track':

$ systemctl --all --full -t device | grep Track

The output looks as follows in this case:

sys-devices-pci0000:00-0000:00:14.0-usb2-2\x2d2-2\x2d2:1.0-sound-card1.device                               loaded active plugged M-Audio Fast Track

The '.device' identifier can now be used in the UNIT description's parts After and Requires:

[Unit]
Description=Jack audio server
After=sound.target sys-devices-pci0000:00-0000:00:14.0-usb2-2\x2d2-2\x2d2:1.0-sound-card1.device
Requires=sys-devices-pci0000:00-0000:00:14.0-usb2-2\x2d2-2\x2d2:1.0-sound-card1.device

Waveguide Strings in Faust

Waveguides are physical models of one-dimensional oscillators. They can be used for emulating strings, reeds and other components. A more detailed explanation is featured in the Sound Synthesis Introduction. The following example implements a string with losses, excited with a triangular function.

text


Faust Code

Load this example in the Faust online IDE for a quick start.

import("all.lib");

// use '(pm.)l2s' to calculate number of samples
// from length in meters:

segment(maxLength,length) = waveguide(nMax,n)
with{
nMax = maxLength : l2s;
n = length : l2s/2;
};




// one lowpass terminator
fc = hslider("lowpass",1000,10,10000,1);
rt = rTermination(basicBlock,*(-1) : si.smooth(1.0-2*(fc/ma.SR)));

// one gain terminator with control
gain = hslider("gain",0.99,0,1,0.01);
lt = lTermination(*(-1)* gain,basicBlock);


idString(length,pos,excite) = endChain(wg)
with{

nUp   = length*pos;

nDown = length*(1-pos);

wg = chain(lt : segment(6,nUp) : in(excite) : out : segment(6,nDown) : rt); // waveguide chain
};

length = hslider("length",1,0.1,10,0.01);
process = idString(length,0.15, button("pluck")) <: _,_;

References

2018

  • Romain Michon, Julius Smith, Chris Chafe, Ge Wang, and Matthew Wright. The faust physical modeling library: a modular playground for the digital luthier. In International Faust Conference. 2018.
    [details] [BibTeX▼]

2007

Audio Buffers

Most systems for digital signal processing and music programming process audio in chunks, which are defined by a so called buffer size. These buffer sizes are usually powers of 2, usually ranging from $16$ samples - which can be considered a small buffer size - to $2048$ samples (and more). Most applications, like DAWs and hardware interfaces allow the user to select this parameter. Technically this means that a system collects (or buffers) single samples - for example from an ADC (analog-digital-converter) - until the buffer is filled. This compensates irregularities in the speed of execution for single operations and ensures a jitter-free processing.


Latency

The choice of the buffer size $N$ is usually a trade-off between processor load and system latency. Small buffers require faster processing whereas large buffers keep the user waiting until a buffer has been filled. In combination with the sampling rate $f_s$, the buffer-dependent latency can be calculated as follows:

$$ \tau = \frac{N}{f_s} $$

Round trip latency usually considers both the input and output buffers, thus doubling the latency. For a system running at $48\ \mathrm{kHz}$ with a buffer size of $128$ samples - a typical size for a decent prosumer setup - this results in a round trip latency of $5.5\ \mathrm{ms}$. This value is low enough to allow a perceptually satisfying interaction with the system. When exceeding the $10\ \mathrm{ms}$ threshold it is likely that percussions and other timing-critical instruments experience disrupting latency.


Buffers in Programming

In higher level programming environments like PD, MAX, SuperCollider or Faust (depending on the way it is used), users usually do not need to deal with the buffer size. When programming in C or C++, most frameworks and APIs offer a processing routine which is based on the buffer size. This accounts for solutions like JUCE or the JACK API, but also when programming externals or extensions for the above mentioned higher level environments. These processing routines, also referred to as callback, are called by an interrupt once the the hardware is ready to process the next buffer.

Pulse Width Modulation: Example

Pitch:

Manual Pulse Width:

Time Domain:

Frequency Domain:

Working with Images

Getting the sprawl access point image

Download the operating system image for the sprawl access points! According to its postfix .xz the image is compressed with the XZ compression algorithm. Before writing the image to the sd card it has to be decompressed.

On Ubuntu/Debian you can install xz-utils and use unxz:

$ sudo apt-get install xz-utils
unxz sprawl_pi_image_20200628_shrinked.img.xz

On MacOS try the unarchiver. On Windows try the usual way to decompress files or download xz-utils.

Writing images on sd card

MacOS

➜  ~ diskutil list
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                 Apple_APFS Container disk1         1000.0 GB  disk0s2

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +1000.0 GB  disk1
                                 Physical Store disk0s2
   1:                APFS Volume OWC Aura Pro SSD - Data 520.8 GB   disk1s1
   2:                APFS Volume Preboot                 82.6 MB    disk1s2
   3:                APFS Volume Recovery                525.8 MB   disk1s3
   4:                APFS Volume VM                      2.1 GB     disk1s4
   5:                APFS Volume OWC Aura Pro SSD        11.2 GB    disk1s5

/dev/disk2 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *63.9 GB    disk2
   1:             Windows_FAT_32 boot                    268.4 MB   disk2s1
   2:                      Linux                         63.6 GB    disk2s2

disk2 seems to be the sd card with 64 GB. To access the raw device /dev/rdisk2 is used. To write to this device you have to be root (administrator). Unmount the device before using dd.

diskutil unmountDisk /dev/disk2
sudo dd if=rpi.img of=/dev/rdisk2 bs=4M

Linux

$ sudo dd if=rpi.img of=/dev/disk/by-id/
ata-PLDS_DVD-RW_DS8A8SH_S45N7592Z1ZKBE0758TK
ata-SAMSUNG_MZMPA016HMCD-000L1_S11BNEACC10413
ata-SAMSUNG_MZMPA016HMCD-000L1_S11BNEACC10413-part1
ata-SAMSUNG_MZMPA016HMCD-000L1_S11BNEACC10413-part2
ata-SAMSUNG_MZMPA016HMCD-000L1_S11BNEACC10413-part3
ata-SanDisk_SSD_PLUS_240GB_184302A00387
ata-SanDisk_SSD_PLUS_240GB_184302A00387-part1
ata-SanDisk_SSD_PLUS_240GB_184302A00387-part2
ata-SanDisk_SSD_PLUS_240GB_184302A00387-part3
ata-SanDisk_SSD_PLUS_240GB_184302A00387-part4
ata-SanDisk_SSD_PLUS_240GB_184302A00387-part5
mmc-SDC_0x000000e2
mmc-SDC_0x000000e2-part1
wwn-0x5001b448b9edd143
wwn-0x5001b448b9edd143-part1
wwn-0x5001b448b9edd143-part2
wwn-0x5001b448b9edd143-part3
wwn-0x5001b448b9edd143-part4
wwn-0x5001b448b9edd143-part5
$ sudo dd if=rpi.img of=/dev/disk/by-id/mmc-SDC_0x000000e2 bs=4M status=progress

Windows

On Windows the easiest way to write an image to a sd card is to use a dedicated application like Balena Etcher.

Wavefolding Example

The following example calculates the spectrum of a sinusoidal function, folded with a sinusoidal transfer function:

Pitch:

Pre-Gain:

Time Domain:

Frequency Domain:

Using APIs with Python

Python & APIs

With the modules requests and json it is easy to get data from APIs with Python. Using the above introduced methods for sequencing, the following example requests a response from https://www.boredapi.com/:

#!/usr/bin/env python3

import requests
import json

response = requests.get("https://www.boredapi.com/api/activity")
data     = response.json()

print(json.dumps(data, sort_keys=True, indent=4))

# print(data["activity"])

Envelopes: ADSR

Envelopes are an essential part of control in electronic music and computer music. They are used to shape the characteristics of sound or other processes over time and are an integral part of synthesizers. Since they are that basic and versatile, they will be introduced in this early section.


One of the most common envelopes, already featured in early synthesizers and in prominent examples as the MiniMoog, is the ADSR envelope (Hiyoshi, 1979). It is comprised of four segments:

  • Attack

  • Decay

  • Sustain

  • Release

Attack time, decay time and release time can usually be controlled by the user via dials or sliders, whereas the sustain time depends on the duration a key is pressed and the sustain level may depend on the stroke velocity. Depending on the settings, the ADSR model can generate amplitude and timbral envelopes for slowly evolving sounds like strings or sounds with sharp attacks and release:

Your browser does not support the HTML5 canvas tag

Attack Time:

Decay Time:

Sustain Level:

Sustain Time:

Release Time:


When used in synthesizers, this envelope can be used to control the overall level or the timbre - for example through the cutoff frequency of a filter or by means of partial amplitudes.


References

1979

  • Teruo Hiyoshi, Akira Nakada, Tsutomu Suzuki, Eiichiro Aoki, and Eiichi Yamaga. Envelope generator. December 18 1979. US Patent 4,178,826.
    [details] [BibTeX▼]

Working with Groups

Creating Groups

Groups - or group nodes - can be a very useful concept for keeping track of the signal flow. Without any further actions, all nodes are placed in the default Group 1. Additional groups can be arranged regarding the order of execution. A new group can be added from sclang as follows:

~g1 = Group.new();

Adding Nodes to Groups

Synth nodes can be added to groups on creation or afterwards. Any existing node - in this case the ~osc node from the previous example <http://ringbuffer.org/computer_music_basics/SuperCollider/combining-nodes-in-supercollider/> - can be moved to a group using the following commands:

// make it the first node in the group
~osc.moveToHead(~g1)

// make it the last node in the group
~osc.moveToTail(~g1)

Relative Group Positions

As with nodes, further groups can be added in relation to existing groups. The following action makes sure that a new group will be placed after the previously defined group:

~g2 = Group.after(~g1);

Nested Groups

Groups can contain other groups, allowing a hierarchical structure of nodes:

~g3 = Group.head(~g2);

More on Groups

The group object allows many more actions. They are listed in the SC documentation on groups. After adding another group before the third one

~g4 = Group.before(~g3);

the server node structure looks as follows:

/images/basics/sc-group-nodes.png

The server does not know the groups by their variable names in sclang. Hence they are numerated. Node indices - or IDs - of groups can be assessed from the language:

~g1.nodeID;
~g2.nodeID;
~g3.nodeID;
~g4.nodeID;

Exercise