snd-aloop
is loaded. This virtual soundcarddevice, as its name indicates, sends back the output signal ofapplications using it back to itself, so one has a chance to e.g. recordthis signal from the same device. Simply imagine that you have aphysical link between one OUT and one IN of the same device.snd-aloop
is loaded, you canverify that the sound card has been created:pcm_substreams
(8 by default). You can always set it to 2 onlyif you wish at loading time. As an example, here is my ALSA moduleconfig file (/etc/modprobe.d/sound.conf
on my debian-based DAW)snd-aloop
if neededlinux-headers-xxx
andmust match the installed kernel (package linux-image-xxx
).build-essential
installed:snd-aloop
in /etc/modules
. (Ifyou wish, you can give the loopback soundcard another name than'Loopback' in a modprobe option but I kept the default throughout theentire HOWTO and there is no need to change it.)hw:Loopback,0
hw:Loopback,1
hw:Loopback,0,0
the audio will be available as input in thecorresponding subdevice hw:Loopback,1,0
because the whole point forthis card is to send the signal back to itself.hw:Loopback,i,n
becomes an input signal from hw:Loopback,j,n
withasoundrc
file$HOME/.asoundrc
but make sure beforethat you are not overwriting an existing asoundrc file (back up whateveryou have if it already exists).aplay
for example). The idea is that an ALSAapp using the default device we have just created will not spit errormessages and will play along nicely. Try for example lmms
using theALSA default :)alsa_in
listens to. The 'cloop' client we createdcan now be connected to the jack system output ports and o miracle, youwill hear your ALSA app :)-q 1
as an option to alsa_in/out. This has to dowith the resampling quality. At 2.3ms latency, 96kHz s.r. on a 2 x 2.4GHz dual core CPU system and using Jack2, I get a low CPU usage (1-2%)and the quality is reasonable. If you push it to 2, 3 or 4, the CPU willincrease quite a lot at small buffering / latencysystem:capture_3
to ecasound:playback_1/2
.