A: There are different mailing lists. Visit Resources at linuxaudio.org and Lists
A: For some uses, it can be helpful to run a realtime (RT) kernel, but generally this isn't necessary anymore. See the following JACK FAQ entry: Do I need a realtime kernel to use realtime scheduling?
In Linux kernels 3.0 and later, many of the additionally required realtime patches have been incorporated as standard. For those who are recording Audio, a standard non-realtime kernel may be sufficient for your needs, and running Jack with a non realtime kernel will work fine.
You need to configure your system, however, to allow JACK to use realtime scheduling.
This wiki has some more articles and general information about real time operation.
Those who produce a lot of MIDI I/O, may want to use a Linux kernel with non-standard timer interrupt frequency (aka “tick rate”). The standard frequency is set at 250 Hz, and realtime kernels are generally set at 1000 Hz. You may still have to use a realtime kernel to obtain accurate MIDI playback using the higher timing setting.
A: It's likely, that the sample-rate of the programs you're using doesn't match. Decide for a samplerate and make sure all applications actually use it. When running a sound-server (jack), make sure it uses the same samplerate. (For example when running fluidsynth, set the -r parameter appropriately)
Some noises can be removed by surpressing specific frequencies, by applying EQs or Filters. Audiofile editors as audacity and rezound offer different solutions for noise removal.
Related articles
Applications
Live noise has many causes, including ground-loops, and other equipment near and far injecting static of many kinds. This includes including weak but audio-active USB signals, PC fan noise, firewire, et cetera, into powerline, ground, and thence into the system. There are many approaches to this, and often more than one approach is needed.
Related articles
For moderate to new hardware, TSC is the best hardware timing sources. Old hardware may have timing issues with multi-core CPU where HPET (high-precision-event-timer) is preferable. Then there is a software layer (in the kernel) to make available the hw-timers to the applications, through different interfaces. One example is the usual system-timer. An implementation, that tries to squeeze everything out of the hardware is the “HR timer” (high-resolution-timer). The higher the timer-resolution, the higher is the possible accuracy of audio/midi-processing. For midi processing it is recommended to increase the system-timer frequency from 250Hz (current default) to 1000Hz. The hr-timer offers even higher frequencies. In order to save power at high frequencies, there's a so called tickless-timer feature in the kernel, which only does timer-ticks (function calls) at (user-)defined times (nano-seconds). For best performance, timer interrupts should be given a high scheduling priority (see: priority settings, rtirq).
How to know, if a TSC / HPET (hardware) is available?
dmesg | grep -i tsc dmesg | grep -i hpet
How to get a list of available timers?
cat /proc/asound/timers
How to config kernel for HPET?
# cat .config | grep -i hpet CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_HPET=y CONFIG_HPET_MMAP=y # cat .config | egrep -i "hrt|hr_t" CONFIG_SCHED_HRTICK=y CONFIG_SCx200HR_TIMER=m CONFIG_SND_HRTIMER=m CONFIG_SND_SEQ_HRTIMER_DEFAULT=y CONFIG_NO_HZ=y CONFIG_HZ_1000=y
Related Articles: Article at kerneltrap.org http://btorpey.github.io/blog/2014/02/18/clock-sources-in-linux/
.
.
In /etc/modprobe.d/alsa-base.conf (debian based distro) one can give an option line as:
options [sound-driver-name] index=[number]
When a driver handles more than one device, you have to specify multiple values for the index option, like this:
options snd-usb-audio index=2,3
How do I specify order of *several* USB soundcards in alsa-base.conf?
If you have several soundcards of one type (=the same driver), you can additionally specify product-ids, as follows:
Look at the output of “lsusb” and “lsusb -n” for the vendor/product IDs of the devices, then specify these IDs in the vid and/or pid options, in hexadecimal. For exampe, if your first USB device has IDs 0123:4567 and the second 89ab:cdef, use the line
options snd-usb-audio index=2,3 pid=0x4567,0xcdef
.
Instead of 'hw:a.b' (hw:1,0) you can use 'hw:DEVICE_ID' which will tell the command
cat /proc/asound/cards
1 [UA25EX ]: USB-Audio - UA-25EX
here you would specify: hw:UA25EX
full command for jackd: /usr/bin/jackd -P70 -u -dalsa -dhw:UA25EX -r48000 -p512 -n3 -M -Xseq
A:
A: A buffer is not filled in time for the requesting software to use it. Sound data does not arrive fast enough so that the requesting software has a continuous stream of data, in other words, the requesting software runs out of sound data. This is because some part of the system is not fast enough to keep up.
An obvious fix for this is increasing the period size. If you're running jack with 128, for example, and you're getting regular X-runs, then increasing the size to 256 may help immediately, and solve the problem.
Jack-Midi has been introduced to extend/replace alsa-midi with:
They currently co-exist.
kindly provided by Fons Adriaensen (2008-09-23 at linux-audio-user _AT_ lists.linuxaudio.org)
To understand how all this fits together you need to know the following.
1. The bottom layer: ALSA audio and ALSA raw midi.
On most (nearly all) Linux systems these are the drivers handling audio and midi devices respectively. A program can use these directly, but then it is limited to connecting to hardware devices only.
2. Interconnecting applications and hardware: Jack and ALSA midi sequencer.
Jack can interconnect audio programs that are written to use it to each other and to an audio card. To talk to the audio card Jack uses the ALSA driver in most cases. This is what you see in the 'AUDIO' tab in qjackctl.
The ALSA midi sequencer does the same for midi. It can connect applications to each other and to physical midi interfaces (raw ALSA ports). This is what you see in the 'ALSA' tab of qjackctl.
3. Jack midi replacing ALSA midi sequencer.
For a programmer the ALSA midi sequencer can be hard to use. It has had serious problems with timing, mainly because of lack of high-resolution timer support in Linux until recent times. This has resulted in the development of midi-in-Jack, which can (almost) be used as a replacement for the ALSA midi sequencer. It has its pros and cons. This is what you see in the 'MIDI' tab in qjackctl.
Currently the two MIDI routing systems coexist, and this leads to some confusion.
In qjackctl you have three options for midi-in-Jack:
1. 'None' - this means that Jack will not use any ALSA midi devices. Applications that use midi-in-jack (e.g. Aeolus) will still show up in the 'MIDI' tab, but you can't connect them to any physical ALSA midi ports, only to other apps (if there are any other).
2. 'Raw' - this means that Jack will grab the raw ALSA (hardware) midi devices, and convert them into Jack midi ports with rather useless names. The same devices are still shown in the 'ALSA' tab, but you will notice you can't connect them there anymore - they are usually supporting only one client, and Jack has already taken them. This means that applications that only support connecting to ALSA midi sequencer can't be connected to physical midi devices anymore. In the dreams of the Jack midi developers, such apps will soon cease to exist, and if that happens the 'raw' option is the normal one to use.
3. 'Seq' - this means Jack will convert *all* ALSA sequencer ports into Jack midi ports. The original ones remain accessible in the 'ALSA' tab. The Jack-midi to ALSA-seq bridge is only included in the ALSA backend, not in the FreeBoB/FFADO firewire backend. a2jmidid or similar apps are then the solution.
Example: Aeolus has both an ALSA midi sequencer port, and a midi-in-Jack port. You will see Aeolus in both the 'MIDI' and 'ALSA' tabs. If you use 'Raw', you will have to use the Jack connection to connect Aeolus to a keyboard. If you use 'Seq' you can make the connection in either system.
Also if you use 'Seq' there will be two Jack-midi ports for Aeolus: the Jack-midi port that Aeolus creates, and a Jack-midi copy of the ALSA sequencer port of Aeolus, shown as system:playback_#, with # some number.
Don't use the latter. What happens if you do that is that the midi data from your keyboard will follow a rather long route: Raw ALSA → Jack port → Jack port → ALSA sequencer → Aeolus.
The most direct route is still the one in the 'ALSA' tab: Raw ALSA → ALSA sequencer → Aeolus.
.
.
A:
.
Devices following the USB 1.1 standard are usually supported. Some require additional firmware to be loaded however.
(on debian/ubuntu: apt-get install midisport-firmware alsa-firmware-loaders)
Support for USB 2.0 devices is also increasingly common.
.
A: First one has to distinguish between native Linux VST plug-ins and VST plugins built for other operating system (usually Windows). There is a growing number of native Linux plugins, which are available in VST format (see “Further resources” below) and an also growing number of host software for Linux supports native Linux VST plugins (see list below). Also there are some hosts or additional tools, which allow to run Windows VST plugins on Linux.
Windows VST plugins often come as two versions built for either 32-bit or 64-bit platforms. Some of the aforementioned tools only support 32-bit plugins, some both versions.
If a Windows VST plugin doesn't work with any of the tools listed below, it is also possible to run a Windows VST host program under Linux via Wine and route its audio output to JACK (with or without WineASIO).
Note: Instead of VST, you may prefer to use open plugin technologies like LV2, LADSPA, and DSSI.
Linux VST hosts:
Open Source:
Proprietary:
Note: Some Linux plugin hosts only provide VST support, if you enable it at compile time with appropriate options.
Linux-Hosts with Windows VST support:
Windows VST hosts:
Running Windows VST hosts on Linux
Further resources: