User:Thisven

From ArchWiki

this.ven – FLOSS musician, tinkerer and privacy advocate

Everbody‘s trending on a tube or inside the f*
Book – you can‘t exist without a profile
So why should I stay away and miss all the news

Website


Sandbox for article rewrites:

Professional audio

This article describes why and how to configure your system for recording, mixing and playing back audio as well as using it to synthesize and generate sounds. Those activities are subsumed under the term professional audio (pro audio) and typically some of those require low latency performance.

Most applications do not need as much high-end hardware, compared to video production or gaming. Almost any computer produced since late 2012 can be optimized for pro audio. Please refer to Ardour manual's page on The Right Computer System for Digital Audio for more information.

Note: If you are looking for a guide on how to actually make music on GNU/Linux, refer to the Sonoj wiki or search the LinuxMusicians forums.

Getting started

After reading the Sound system article, you might be aware that Advanced Linux Sound Architecture or ALSA is part of the Linux kernel and used for drivers and interface on Arch Linux as the default Sound system. ALSA should work out of the box with a default Arch installation. If this is not the case, you must solve the problem before going any further.

However, "no sound" is likely a simple unmuting the channels problem in ALSA's mixer configuration. If you are using multiple audio devices (e.g. an USB audio interface and keep in mind integrated soundcards), you'd want to set the default sound card.

Have I set up sound properly?

$ speaker-test
See ALSA for troubleshooting.

A vanilla Arch Linux kernel is sufficient for low latency operation in most use cases. Applying further #System configuration will be necessary only if you are experiencing audio drop-outs (also known as glitches) or if you need (or want) to reach ultra-low latency operations.

To finish with optimizations, these ultra low latency operations may require you to set up a #Realtime kernel.

Although some pro audio software can work with ALSA directly, most of the #Applications mentioned later are JACK Audio Connection Kit or JACK clients. Therefore, you will need to install and setup one of the available sound servers which are outlined in the next section.

Choosing a sound server

Sound hardware cannot play back sound from more than one application simultaneously. While ALSA can theoretically be configured to mix applications in software this is typically left to a sound server. As ALSA alone cannot achieve low latencies easily and cannot synchronise multiple audio applications to play on time, starting all at the same time, at the same tempo, etc, and as it can not share audio flux between applications simply by connecting all it's clients together, you not only need any sound server, but pro audio class one.

There are three of them, two meant for pro-audio:

  • PulseAudio is the de-facto standard for playback and multimedia, such as videos, browser, music and games. It was not conceived for pro-audio and lacks the capability to achieve low latencies and sync applications.
  • JACK has been developed with all the needs of pro audio and has been in use all over the world for many years and is therefore very stable and mature. Pro-Audio applications are written for the JACK API.
  • PipeWire is under heavy development and is presented as a replacement of JACK and PulseAudio at the same time for the audio part. It also handles video routing, which is not described in this article. At the moment version numbers indicate a beta development state.

The sound server setup strongly depends on the use case as well as on the workflow and capabilities of some application interaction. The JACK Audio Connection Kit was designed to share audio between applications and access an audio device simultaneously by providing the synchronous execution of clients while maintaining constant low latency.

This layout illustrates a layer model of the sound server setups to be discussed:

  #PipeWire-only       #JACK-only

 ┌──────────────┐   ┌──────────────┐
 │ Applications │   │ Applications │
 ├──────────────┤   ├──────────────┤
 │   PipeWire   │   │     JACK     │
 ├──────────────┤   ├──────────────┤
 │     ALSA     │   │     ALSA     │
 └──────────────┘   └──────────────┘

PipeWire-only

The newer PipeWire framework aims to replace JACK as well as other sound servers for the sake of simplicity. Thus, it's recommended to first go for a PipeWire-only setup implementing support for JACK clients by installing pipewire-jack and using the vanilla Arch Linux kernel.

JACK-only

The principle of versatility allows you to employ JACK and the #Realtime kernel with further #System configuration to achieve low latencies for advanced use cases known as JACK-only setup. Using JACK as the only sound server requires any software, that is intended for interaction and audio device access, to run as a JACK client.

Unfortunately, popular desktop applications such as Firefox or most games either dropped JACK support or never implemented it. For that reason this setup should be used for a dedicated pro audio system where non-JACK software can be neglected. If you still need to use software that can't connect to JACK, refer to Professional_audio/Examples#Advanced_sound_server_setups after following the setup described here. Before installing and running JACK you should ensure it can access your audio device.

Is PulseAudio or something else grabbing my device?

$ lsof +c 0 /dev/snd/pcm* /dev/dsp*

or

$ fuser -fv /dev/snd/pcm* /dev/dsp*}}

If your audio device isn't listed, it may be used by PulseAudio (which was probably installed as dependency of another application). Remove those alongside PulseAudio, if you're not intending to use Professional_audio/Examples#PulseAudio+JACK in order to make PulseAudio release your audio device.

As JACK version 1 is planned to be "slowly phased out" [1], doesn't support Symmetric Multiprocessing (SMP), lacks D-Bus and Systemd integration you'd want to use version 2 which is available as jack2 package in the official repositories. If you're going to use a JACK control GUI or a Systemd user service for Starting the audio graph, also install jack2-dbus.

More details in JACK_Audio_Connection_Kit#Comparison_of_JACK_implementations

The article on JACK describes a GUI-based and a shell-based example setup as a point of reference for your own scenario. Parameter values of JACK are discussed in detail in the #JACK parameters section and may depend on other system factors covered by the #System configuration section later on.

JACK parameters

Note: The following guidelines should support finding best possible parameter values for running JACK without audio drop-outs (xruns) when using the #JACK-only or #PulseAudio+JACK sound server setup type. Due to differences depending on the hardware, whether a #Realtime kernel is used or not, and if further #System configuration is applied, there is no general preset.

The aim here is to find the best possible combination of buffer size and periods, given the hardware you have. Frames/Period = 256 is a sane starter. For onboard and USB devices, try Periods/Buffer = 3 before lowering both values. Commonly used values are: 256/3, 256/2, 128/3, 128/2.

Also, the sample rate must match the hardware sample rate. To check what sample and bit rates your device supports:

$ cat /proc/asound/card0/codec#0

Replace card0 and codec#0 depending on what you have. You will be looking for rates or VRA in Extended ID. A common sample rate across many of today's devices is 48000 Hz. Others common rates include 44100 Hz, 96000 Hz and 192000 Hz.

A prerequisite for the next parameter is Configuring PAM limits to enable realtime scheduling for users (e.g. by installing the realtime-privileges package and adding the user to the realtime group).

Is PAM-security and realtime working?

See: Realtime for Users#PAM-enabled login (Pay special attention especially if you do not run SDDM, GDM or SLiM.)

Almost always, when recording or sequencing with external gear is concerned, realtime is a must. Also, you may like to set maximum priority (at least 10 lower than system limits defined in /etc/security/limits.d/99-realtime-privileges.conf; the highest is for the device itself).

Start jack with the options you just found out:

$ /usr/bin/jackd -R -P89 -dalsa -dhw:0 -r48000 -p128 -n2

qjackctl, cadence, patchage and studio-controls-gitAUR can all be used to as GUIs to monitor JACK's status and simplify its configuration.

Note: Once you set up JACK, try different audio applications to test your configuration results. For example, do not spend days trying to troubleshoot JACK xrun issues with LMMS if the problem is with the latter.
Further reading: Linux Magazine article (2006) for basic understanding on JACK parameter finding

Latency verification

JACK parameters are most significant for controlling the round-trip delay (RTD). In the context of this article that is the overall time it takes for an audio signal to be recorded, processed and played back. The next subsection deals with theoretical background on the sources of latency adding up to the RTD. If you are already familiar with that, you can go to #Measuring_latency to verify your RTD or skip this section completely.

Latency sources

Consider a typical recording situation of a singer performance. The voice is being captured with a microphone as it propagates trough the air with the speed of sound. An analog-to-digital-conversion enables the electrical signal to be recorded by a computer for digital signal processing. Finally, a digital-to-analog conversion returns the signal to be played back at the singer's headphones for monitoring similar to stage monitor system usage.

In that voice recording situation there are five significant latency sources constructing the RTD and occuring in the following order:

  1. Sound propagation through the air from the mouth of the singer
  2. Analog-to-digital conversion
  3. Digital signal processing
  4. Digital-to-analog conversion
  5. Sound propagation through the air to the ear of the singer

The first and last latency source is hard to change as a particular distance is technically necessary to create an intended sound during recording or playback, respectively. Additionally, when using closer miking for capturing and headphones for monitoring both sound propagation latencies are typically within the range of a few microseconds which is not noticeable by humans. Thus, an objective for RTD minimization is to reduce the other sources of latency.

Conversion latency

In theory JACK maintains a constant low latency by using fixed values (frames, periods, sample rate) for sampling and buffering of audio to be converted analog-to-digital and vice versa. The latency occurring in the capturing process is described by the following equation:

Lc = n / f

Lc: Capture latency in milliseconds (ms), n: Frames or buffer (multiples of 2, starting at 16), f: Sample rate in Hertz (Hz).

The playback latency is also employing the periods value:

Lp = n * p / f

Lp: Playback latency in milliseconds (ms), n: Frames or buffer (multiples of 2, starting at 16), p: Periods, f: Sample rate in Hertz (Hz).

As already stated before the capabilities of the audio interface define working combinations. You have to trial and error to find a setup. Sure, it's a trade-off between xrun prevention and achieving low latency, but recent audio interfaces can be used at high sample rates (up to 192 kHz) to deal with that requirement. The audio flux of JACK clients in the digital domain is about zero and thus, negligible for latency measurements [2].

See FramesPeriods in the ALSA wiki for more information.

Measuring latency

Once you have set up #JACK parameters you might want to verify the RTD described above. For example, using a frames or buffer size of n = 128, a periods value of p = 2, and a sample rate of f = 48000 results in a capture latency of about Lc = 2,666... ms and a playback latency of about Lp = 5,333... ms summing up to a total round-trip delay of RTD = 8 ms.

Note: This latency value is comparable to a typical monitoring situation on stage using speakers with a distance to the performer's ear ranging between 2 m and 3 m according to the equation for the speed of sound in air. Performers experienced with on stage monitoring are typically used to such latencies.

The jack_delay utility by Fons Adriaensen measures RTD by emitting test tones out a playback channel and capturing them again at a capture channel for measuring the phase differences to estimate the round-trip time the signal has taken through the whole chain. Use an appropriate cable to connect an input and output channel of your audio device or put a speaker close to a microphone as described by JACK Latency tests.

For example, running jack_delay for a JACK-only setup using a cable connection between the ports playback_1 and capture_1 (the description may differ depending on your hardware) to close the loop, as well as the values discussed before yields the following insights:

$ jack_delay -O system:playback_1 -I system:capture_1
capture latency  = 128
playback_latency = 256
Signal below threshold...
Signal below threshold...
Signal below threshold...
  422.507 frames      8.802 ms total roundtrip latency
       extra loopback latency: 38 frames
       use 19 for the backend arguments -I and -O
  422.507 frames      8.802 ms total roundtrip latency
       extra loopback latency: 38 frames
       use 19 for the backend arguments -I and -O
  422.506 frames      8.802 ms total roundtrip latency
       extra loopback latency: 38 frames
       use 19 for the backend arguments -I and -O
  422.507 frames      8.802 ms total roundtrip latency
       extra loopback latency: 38 frames
       use 19 for the backend arguments -I and -O
<output omitted>

As the output indicates further optimization of JACK can be done by using the parameters -I 19 and -O 19 to compensate for the reported extra loopback latency in the chain:

$ /usr/bin/jackd -R -P89 -dalsa -dhw:0 -r48000 -p128 -n2 -I19 -O19
More details can be found in the Ardour Manual page about latency and latency compensation.

System configuration

You may want to consider the following often seen system optimizations:

# echo 2048 > /sys/class/rtc/rtc0/max_user_freq
# echo 2048 > /proc/sys/dev/hpet/max-user-freq
  • Reducing swappiness (aka swap frequency, set to 60 by default) to e.g. 10 will make the system wait much longer before trying to swap to disk (see wikipedia:Paging#Swappiness). This can be done on the fly with sysctl vm.swappiness=10 (see sysctl(8)) or setup permanently, using a configuration file (see sysctl.d(5)) such as:
/etc/sysctl.d/90-swappiness.conf
vm.swappiness = 10
  • Increasing the maximum watches on files (defaults to 524288) to e.g. 600000, that inotify keeps track of for your user, can help with applications, that require many file handles (such as DAWs). This again can be done on the fly with sysctl fs.inotify.max_user_watches=600000 or in a dedicated configuration file:
/etc/sysctl.d/90-max_user_watches.conf
fs.inotify.max_user_watches = 600000

You may also want to maximize the PCI latency timer of the PCI sound card and raise the latency timer of all other PCI peripherals (default is 64).

$ setpci -v -d *:* latency_timer=b0
# setpci -v -s $SOUND_CARD_PCI_ID latency_timer=ff

E.g. SOUND_CARD_PCI_ID=03:00.0.

The SOUND_CARD_PCI_ID can be obtained like so:

$ lspci | grep -i audio
03:00.0 Multimedia audio controller: Creative Labs SB Audigy (rev 03)
03:01.0 Multimedia audio controller: VIA Technologies Inc. VT1720/24 [Envy24PT/HT] PCI Multi-Channel Audio Controller (rev 01)

Realtime kernel

"Realtime" in the context of an operating system is defined that the results of a computation are available within a fixed period of time. Only in a broader sense does it mean "time running simultaneously with reality", for example, that a sound is produced immediately in response to musical user input. The latter is called "low latency" and it's setup is one of the main goals of this articles.

Since a while ago, the stock Linux kernel (with CONFIG_PREEMPT=y, default in Arch Linux vanilla kernel) has proven to be adequate for low latency operation. Latency in an operating system context is the time between the moment an interrupt occurs in hardware, and the moment the corresponding interrupt-thread gets running. Unfortunately, some device drivers can introduce higher latencies. So depending on your hardware, drivers, and requirements, you might want a kernel with hard realtime capabilities.

Pros and cons

The RT_PREEMPT patch by Ingo Molnar and Thomas Gleixner is an interesting option for hard and firm realtime applications, reaching from professional audio to industrial control. Most audio-specific Linux distributions ships with this patch applied. A realtime-preemptible kernel will also make it possible to tweak priorities of IRQ handling threads and help ensure smooth audio almost regardless of the load.

Note: Currently, there are known limitations for using a realtime kernel with other specific applications typically related to Virtualization (such as Xen and KVM). If you also need those capabilities, consider installing the realtime kernel in addition to the vanilla Arch Linux kernel and creating a second boot loader entry for booting the appropriate kernel on demand.

Installation

There are ready-to-run/compile patched kernels available in the Unofficial user repository and Arch User Repository (AUR) as well as in the Arch Build System (ABS).

Tip: Probably the most straightforward method for installing a Realtime kernel is to use the realtime repository from the list of unofficial user repositories in order to circumvent compilation on your own, as well as induced efforts and possible issues.

From the AUR itself, you have the following options:

Compilation

If you are going to compile your own kernel using the Realtime kernel patchset, remember that removing modules/options does not equate to a "leaner and meaner" kernel. It is true that the size of the kernel image is reduced, but in today's systems it is not as much of an issue as it was back in 1995.

See HOWTO setup Linux with PREEMPT_RT properly for further general instructions.

In any way, you should also ensure that:

  • Timer Frequency is set to 1000Hz (CONFIG_HZ_1000=y; if you do not do MIDI you can ignore this)
  • APM is DISABLED (CONFIG_APM=n; Troublesome with some hardware - default in x86_64)

If you truly want a slim system, we suggest you go your own way and deploy one with static /devs. You should, however, set your CPU architecture. Selecting "Core 2 Duo" for appropriate hardware will allow for a good deal of optimisation, but not so much as you go down the scale.

General issue(s) with (realtime) kernels:

  • Hyperthreading (if you suspect, disable in UEFI settings)

Applications

Arch Linux provides the package group pro-audio holding all relevant (semi-) professional applications. All applications in the pro-audio package group are JACK clients. Also lv2-plugins, ladspa-plugins, dssi-plugins and vst-plugins are subgroups of the pro-audio group.

Tip: See Pacman/Tips and tricks#Listing packages for listing members of and Pacman#Installing package groups for installing package groups.

An overview and brief information on some applications is found in List of applications/Multimedia#Audio. Especially the categories Digital audio workstations, Audio effects and Music trackers, as well as Audio synthesis environments and Sound generators, provide examples of pro audio software for e.g. recording, mixing, mastering, and sound design. Other categories include Scorewriters, Audio editors, Audio converters, and DJ software.

Packages not (yet) in the official repositories can be found in proaudio. Browse the list of packages to find the application you need or request packaging of your desired applications via GitHub.

Hardware

The majority of sound cards and audio devices will work with no extra configuration or packages, simply set the sound card jack is using to them and restart.

This is not true for all devices, and so special cases are also listed.

M-Audio Delta 1010

The M-Audio Delta series cards are based on the VIA Ice1712 audio chipset. Cards using this chip require that you install the alsa-tools package, because it contains the envy24control program. Envy24control is a hardware level mixer/controller. You can use alsa-mixer but you will save yourself some hassle not to try it. Note that this section has no information on MIDI setup or usage.

Open the mixer application:

$ envy24control

This application can be more than a bit confusing; see envy24control for guidance on its use. That said, here is a very simple working setup for multitracking with Ardour.

  1. On the "Monitor Inputs" and "Monitor PCMs" tabs, set all monitor inputs and monitor PCMs to around 20.
  2. On the "Patchbay / Router" tab, set all to PCM out.
  3. On the "Hardware Settings" tab, verify that the Master Clock setting matches what is set in Qjackctl. If these do not match you will have xruns out of control!

M-Audio Fast Track Pro

The M-Audio Fast Track Pro is an USB 4x4 audio interface, working at 24bit/96kHz. Due to limitation of USB 1, this device requires additional setup to get access to all its features. Device works in one of two configuration:

  • Configuration 1, or "Class compliant mode" - with reduced functionality, only 16bit, 48kHz, analogue input (2 channels) and digital/analogue output (4 channels).
  • Configuration 2 - with access to all features of interface.

Currently with stock kernel it runs in configuration 2, but if you want to make sure in what mode you are, you can check kernel log for entries:

usb-audio: Fast Track Pro switching to config #2
usb-audio: Fast Track Pro config OK

The interface also needs extra step of configuration to switch modes. It is done using option device_setup during module loading. The recommended way to setup the interface is using file in modprobe.d:

/etc/modprobe.d/ftp.conf
options snd_usb_audio vid=0x763 pid=0x2012 device_setup=XXX index=YYY enable=1

where vid and pid are vendor and product id for M-Audio Fast Track Pro, index is desired device number and device_setup is desired device setup. Possible values for device_setup are:

device modes
device_setup value bit depth frequency analog output digital output analog input digital input IO mode
0x0 16 bit 48kHz + + + + 4x4
0x9 24 bit 48kHz + + + - 2x4
0x13 24 bit 48kHz + + - + 2x4
0x5 24 bit 96kHz * * * * 2x0 or 0x2

The 24 bit/96kHz mode is special: it provides all input/output, but you can open only one of 4 interfaces at a time. If you for example open output interface and then try to open second output or input interface, you will see error in kernel log:

cannot submit datapipe for urb 0, error -28: not enough bandwidth

which is perfectly normal, because this is USB 1 device and cannot provide enough bandwidth to support more than single (2 channel) destination/source of that quality at a time.

Depending on the value of index it will setup two devices: hwYYY:0 and hwYYY:1, which will contain available inputs and outputs. First device is most likely to contain analog output and digital input, while second one will contain analog input and digital output. To find out which devices are linked where and if they are setup correctly, you can check /proc/asound/cardYYY/stream{0,1} . Below is list of important endpoints that will help in correctly identifying card connections (it easy to mistake analog and digital input or output connections before you get used to the device):

EP 3 (analgoue output = TRS on back, mirrored on RCA outputs 1 and 2 on back)
EP 4 (digital output = S/PDIF output on back, mirrored on RCA outputs 3 and 4 on back)
EP 5 (analogue input = balanced TRS or XLR microphone, unbalanced TS line on front)
EP 6 (digital input = S/PDIF input on back)

This .asoundrc file enables 24-bit IO on the fast-track pro (and I'm sure it could be modified to work with other 3-byte usb devices) within the context of jack's 32-bit interface while routing default alsa traffic to jack outputs on the audio interface. Alsa will be in S24_3BE mode but jack can plug S32_LE data in and out of the interface and other alsa programs will be able to plug almost anything into jack.

### ~/.asoundrc
### default alsa config file, for a fast-track pro configured in 24-bit mode as so:
### options snd_usb_audio device_setup=0x9
### invoke jack with: (if you use -r48000, change the rate in the plugs as well)
### $jackd -dalsa -P"hw:Pro" -C"hw:Pro,1" -r44100

## setup input and output plugs so jack can write S24_3BE data to the audio interface

pcm.maud0 {
	type hw
	card Pro
}

#jack_out plug makes sure that S32_LE data can be written to hw:Pro
pcm.jack_out{
	type plug
	format S32_LE
	channels 2
	rate 44100
	slave pcm.maud0
}

pcm.maud1 {
	type hw
	card Pro
	device 1
}
## jack_in plug makes sure that hw:Pro,1 can read S32_LE data
pcm.jack_in {
	type plug
	format S32_LE
	channels 2
	rate 44100
	slave pcm.maud1
}
#####
# route default alsa traffic through jack system io

pcm.jack {
    type jack
    playback_ports {
        0 system:playback_1
        1 system:playback_2
    }
    capture_ports {
        0 system:capture_1
        1 system:capture_2
    }
} 
pcm.amix {
	type asym
	playback.pcm "jack"
	capture.pcm "jack"
	}
pcm.!default {
	type plug
	slave.pcm amix
}

PreSonus Firepod

  1. Startup: Either from command line or QjackCtl, the driver is called firewire.
  2. Specs: The card contains 8/8 preamp'ed XLR plus a stereo pair, in total 10 channels.
  3. Linking: Cards can be linked together without any problems.
  4. Hardware Settings: Nothing particular, tweak the settings in QjackCtl to your likings.

Volume levels are hardware and routing can be done through QjackCtl, even with more cards linked together, this is not a problem. The ffadomixer does not work with this card yet, hopefully in the future we can control more aspects of the card through a software interface like that.

PreSonus AudioBox USB

  1. Startup: It is called "USB" by ALSA.
  2. Specs: Two mono TRS+XLR in, two mono TRS out, MIDI in and out, plus separate stereo headphone jack. Knob controls for both inputs, for main out, and for headphone, four in all.
  3. Hardware: Works very well, audio and MIDI too. No software mixer controls at all.

Tascam US-122

This does not apply to the US-122L

  1. Required packages: alsa-tools alsa-firmware fxloadAUR
  2. udev rules: create the following rules file, then reload udev rules, Udev#Loading new rules
/etc/udev/rules.d/51-tascam-us-122.rules
SUBSYSTEMS=="usb", ACTION=="add", ATTRS{idProduct}=="8006", ATTRS{idVendor}=="1604", RUN+="/bin/sh -c '/sbin/fxload -D %N -s /usr/share/alsa/firmware/usx2yloader/tascam_loader.ihx -I /usr/share/alsa/firmware/usx2yloader/us122fw.ihx'"
SUBSYSTEMS=="usb", ACTION=="add", ATTRS{idProduct}=="8007", ATTRS{idVendor}=="1604", RUN+="/bin/sh -c '/usr/bin/usx2yloader'"

Plug in the unit The device should now be working, there are no software mixer controls

RME Babyface

It works very well at low latencies (~5ms) with alsa-utils, jack2 and linux-rtAUR. Running on ALSA only with the standard kernel may cause crackling at lower latencies.

To be recognized and work, the firmware version of the Babyface needs to be >= 200, which introduces the Class Compliant Mode. To enter Class Compliant Mode hold the "Select" and "Recall" buttons while connecting the Babyface to the computer via USB. It should now be recognized.

To check if it is recognized:

$ grep -i baby /proc/asound/cards

For more info about the Class Compliant Mode visit RME's website, they have PDF which covers all the functionality.

The Babyface does not need any special Jack Settings. But if you want to use the built in MIDI In/Out then you need to set the "MIDI Driver" to "seq" and optionally disable "Enable Alsa Sequencer Support" to use it in combination with other MIDI Devices (a USB Midi Keyboard for example).


Get help

Mailing lists

  • Arch Linux Pro-audio Discussion about real-time multimedia, including (semi-)pro audio and video.
  • Linux Audio User The Linux pro-audio related mailing list with much traffic and a huge subscriber community of users and developers.

IRC

  • #archlinux-proaudio - Arch Linux pro-audio channel
  • #lau - General Linux Audio channel for users
  • #jack - Development and support related to JACK audio system
  • #lv2 - Development and support related to the LV2 plugin format
  • #ardour - Discussion and support relating to the Ardour DAW
  • #opensourcemusicians - Large general OSS musician discussion channel

See also

Rewriting notes


structure discussion:

--this.ven (talk):

Thoughts on article structure:

  • Shorten hardware section by moving and linking specific hardware to separate articles within the Category:Sound
  • Link to different setups (JACK-only, PulseAudio+JACK, PipeWire) for use cases (or combinations) on subpages of Professional audio and point out configuration that is additional to the articles of those sound systems

--Jujudusud (talk):

Thoughts on article structure:

  • Getting started:
    • Explaining the low latency operation concept.
    • Explaining how the latest vanilla kernel (and the archlinux distro) is already optimised for low latency audio.
    • Explaining the synchronous execution of all clients needs.
    • Finish the explanations with "Difference between needs and wants":
      • Low latency only for live or recording or any operation that requires human intervention without latency.
      • playback or mixing do not need ultra low latency.

Everything else should be placed in the following sections.

  • Choice of a sound server

ALSA alone cannot synchronise all the clients, you need a sound server for that. With only one application and the proper configuration, you can achieve the (low) latency you wanted without x-runs.

    • pulseaudio is not a sound server for pro audio, only for multimédia purposes as synchronisation of multiclients is not implemented.
    • JACK has been developped for pro audio requirements, it synchronises multiclients with predictable latency. We do not need to talk about JACK 1 JACK 2 jackd here because it is the same "thing" from the musician chair side.
    • Pipewire is designed to replace JACK + pulseaudio (and add a vidéo implementation) and presents itself has JACK to the JACK clients, but it is a beta version and there is a lack of some essential things in it.

link to "unmuting in alsa" : Advanced Linux Sound Architecture#Unmuting the channels

  • System tweaks
    • Swappiness or no swap choice

To be continued...

Use cases:

--Jujudusud (talk):

Use:

  1. Desktop,
  2. recording demos with like 5 audios simultaneously,
  3. Jamulus playing with a band through the internet,
  4. virtual guitar and/or bass amp,
  5. virtual instrument.

Hardware:

  1. desktop tower,
  2. intel i7 2500k + intel integrated graphic,
  3. no wifi, no bluetooth,
  4. usb 2 and usb 3 sata3 ssd pci-e 3 motherboard,
  5. 24" @ 1920x1200 LCD screen DVI,
  6. Presonus Audiobox USB audio interface.

System' sound/MIDI:

  1. ALSA audio + bridge ALSA->PulseAudio->JACK (plugin) Always on,
  2. PulseAudio + bridge ->PulseAudio sink (capture + playback),
  3. JACK,
  4. Cadence + Catia,
  5. ALSA MIDI + A2J midi bridge (export hardware + start with JACK).

To be updated...

--this.ven (talk)

Use (still sorted from high to low latency requirements):

  1. everyday desktop for web browsing etc.
  2. composing and ear transcribing music
  3. mixing and mastering with lots of software processing (plugins)
  4. guitar amp simulation and virtual instrument (drums)
  5. live playing with other musician over the internet using JackTrip
  6. recording 2 simultaneous tracks (with software monitoring)

These setups are used in combination: 2+3, 4+5, 4+6, 4+5+6

Hardware:

Software:

--upacesky:

Desktop setup for audio mastering

Hardware:

  • Tower PC, AMD ryzen (no idea about the generation etc.)
  • Internal Soundcards: RME HDSPe AES & RME HDSP MADI (ExpressCard with PCIe Adapter) -External converters
  • SSD as a system disk, HDD for storage and backups

Softwares:

  • Ubuntu tweaked for audio, so it has the official low-latency kernel and tons of plugins
  • Jackd + qjackctl
  • Pulseaudio bridged to jackd for everyday stuff (on jack startup)
  • RME control as a digital mixing board for all my inputs and outputs

Use case:

  • Audio mastering using a floss pipeline and (mostly) DIY hardware. In this setup, I do not really care about latency, I just start ardour, throw a bunch of plugins and hardware inserts, make it sound darn good and export the result.
  • I edit the radio show "Libre à vous" in ardour in order to transform it into a podcast.
  • Recording some friends (mostly overdubs, with low latency)

Mobile audio setup

Hardware:

  • Laptop Schenker Via Pro
  • AMD Ryzen™ 7 4800H with Radeon™ Graphics × 16
  • 32Go RAM
  • RME Babyface Pro in Class Compliant mode

Softwares:

  • Manjaro Gnome
  • Pipewire
  • Helvum as a pipewire Patchbay (similar to jack patchbays) audio Softwares and Plugins

Use case:

  • Audio recording on the go, I can run this setup for hours without a power source.
  • Podcast editing
  • Everyday audio
  • A lot of linuxaudio testing

--Nh:

Hardware:

  • CPU: AMD Ryzen 5 5600X (12) @ 3.700GHz
  • GPU: AMD ATI Radeon RX 480
  • Memory: 32020MiB
  • RME Hammerfall / Multiface 1 PCI through generic PCI-Express adapter

Software:

  • Jack2 with PulseAudio and Alsa bridges through Cadence (no custom setup, just clicking the buttons in Cadence). Sadly with dbus (see below)
  • Standard Arch Linux kernel with pacman -Sy realtime-generic-setup
  • Music production with synths, sampling and recording, mostly live recording through midi keyboards or actual instruments.
  • Sequencing with Laborejo or Ardour (jack mode)
  • "Awesome" Window Manager

Use cases:

  • General purpose computer for desktop, office, games, browser, programming etc.
  • Also for audio production. Jack is permanently running.

Variants:

  • I also have a laptop with nearly the same system, just less installed software (no office, no games etc.). This is only for recording. I use the same RME device, but with an older laptop that supports the laptop interface card. This uses qjackctl and pure jack2, no pulseaudio, no dbus and no bridges.
  • Before the pandemic I ran a Desktop setup without pulseaudio, without bridges and without dbus. It used two sound interfaces: the RME Multiface with jack for recording and the internal motherboard sound device for browser, listening to music, games etc. The two outputs were connected outboard with an analogue mixer and there was no crosstalk in software between these two, at all. The software mixing for "consumer audio" was done by ALSA dmix, which worked very well. In the end I switched to the cadence based setup above because one specific video conference web-tool I needed for work was not working.