Jack Bridge Software

• Jack 6.0 Bridge Software
• Jack 6.0 Computer Bridge Software
• Jack 6 Bridge Software
• Jack 6.0 Bridge Software
• Jack Bridge Software

The most recent version of Jacks bridge engine as well as Jacks Bali 2013 convention card. In Computer World Bridge Championship of 2013 at Bali, Indonesia, Jack played better and faster to keep his 2012 title from Lille, France. Now you can use the same methods with and against Jack. Complete support for Berry Westras teaching methods. Jack is one of the best computer bridge software products on the market. Only problem is you play and then take back your bids or cards, you can become spoiled. Then when you play in person, you may be to casual with bids and play. The ultimate bridge software tool for bridge players and bridge professionals. A Windows application designed to meet the specific needs of bridge players, bridge teachers, bridge game directors, and bridge publishers. BridgeComposer offers: Bridge Hand Editor; Double Dummy Solver; Quick entry of hands, bidding, etc. Random bridge hand generation.

June 2014 Jack 6. Computer bridge program Jack is the world champion of this Millennium. 4 The Jack Bridge. 4.1 Creating permanent Jack clients using alsain and alsaout; 4.2 Create scripts to automate bridge initialization via QjackCtl; 5 Alternative Setup: hardware and software based solution. 5.1 Adding extra h/w inputs in asoundrc; 5.2 Testing the new ALSA capture; 6 Measuring the latency introduced by the Loopback device.

By Thorgal - May 3rd 2010

Contents

• 2 The ALSA Loopback 'Sound card'
• 3 Building an asoundrc file
• 4 The Jack Bridge
• 5 Alternative Setup: hardware and software based solution
• 6 Measuring the latency introduced by the Loopback device

Introduction

Some people may use PCs where the Jack Audio ConnectionKit is running all the time. As one of theseusers myself, my DAW PC uses a very lightWM (fluxbox) without any of the audio layers provided by the morefeature rich WMs (like KDE or Gnome). I have jack started at login andhopefully, it never goes down until the next PC shutdown. Since I do notwant any other audio layer such as Pulseaudio, etc, in between Jack andALSA in my case (but it could well be FFADO for firewire devices), thishas the slight disadvantage of making non jackified applicationsunusable.

So how can one provide a permanent bridge between non jackifiedapplications and Jack? Well, there are different ways. One can bepurely hardware: enable another soundcard (e.g the onboard sound chip)and physically link it to your DAW sound-card if you are like me with adedicated audio h/w for DAW operations. Let this extra soundcard be thedefault (ALSA index 0) so that apps like flashplayer, skype, etc, use itby default. However, this may limit the number of h/w IOs of your DAWsoundcard for your pro work. I do not like this physical link because myRME Multiface II has only 8 analog mono INs, while the onboard soundchip (Intel HDA) has no digital output that I can link to the Multifacedigital input. I would be forced to patch two INs of the Multiface tothe stereo output of the onboard chip. It is too expensive to considerin terms of physical IOs.

The alternative is a software solution or a mix h/w - s/w (as used in myfinal setup). So, I was looking for a solution in the form of permanentJack clients, playback and capture ideally, or at least playback since Ican use the capture device of a second soundcard like the onboard chipor anything else (I will clarify this further down but it is notnecessarily an average setup). In terms of software solutions, the ALSAjack PCM plugin is in my opinion not ideal because the Jack client willdisappear as soon as the application stops outputting audio.Furthermore, this PCM plugin has not been updated (except lately byTorben Hohn but the patch is not widespread) and I found the pluginquite buggy / unstable in many situations.

It is not until recently, as I was fiddling with the ALSA Loopbackdevice, that I saw a way to achieve what I needed.

The ALSA Loopback 'Sound card'

The ALSA Loopback sound card is a virtual soundcard that is created oncethe ALSA kernel module 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.

By default, the Loopback sound card consists of 2 devices, each composedof 8 subdevices. Once the kernel module snd-aloop is loaded, you canverify that the sound card has been created:

Note that you can control the number of subdevices with the moduleoption 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)

As you can see, I do fix indexes even though ALSA and Jack can work withnames only. It is motivated by the special position that is index 0, theALSA default device that flashplayer will try to use.

Compiling snd-aloop if needed

Update: it may not be needed any longer as of kernel 2.6.38 ...

It may well be that the ALSA Loopback kernel module was not included inyour distribution's kernel package (it is the case in e.g. debian, asfar as I know). This is no bother as we can easily compile it. Note thatthere is no way around since the loopback ALSA module is not part of thekernel baseline in general. So unless your kernel packager had done thefollowing work, you will have to do it yourself ...

Warning: I tried alsa-driver 1.0.21 against 2.6.33.5-rt22 and while itcompiled fine, it would not load at all, even when forced. So don'twaste your time with this version combo.

Make sure you really don't have it installed. Better check that not :)

If modinfo reports nada, time to check that you have installed thekernel headers corresponding to your presently running kernel. I'llleave this to you as this is very distro dependent. In debian baseddistros, the package is called something like linux-headers-xxx andmust match the installed kernel (package linux-image-xxx).

Time to make a backup of the installed kernel modules. Example;

Prerequisite: you of course need a compiler and other tools. In debianbased distros, you can check that you have a package calledbuild-essential installed:

If not, just get it:

Now grab the alsa-driver source code (same version as your installedALSA, in my case 1.0.23 which I will use in my description) from theThe ALSA website, uncompress, untar itand cd to the alsa-driver top dir. Here is a command summary ...

Now you have to configure the source package for compilation. To helpyou, look at what ALSA modules are currently loaded:

And check what card they correspond to by typing

You will see a big list of possible cards. Pick the ones you areinterested in. As an example, this is how I configured the alsa-driversource on my DAW system:

and on my laptop:

So, feel free to configure it the way you want it. Once you haveconfigured the ALSA driver source, you just go through the usualsequence:

It will normally install all the compiled modules into the correctlocation of your kernel installation. Now check that the kernel knowsabout the loopback module:

Allrighty, time to load it. But before that, shut down all audio apps(including firefox). Once done, do this:

Now, see if it works:

If all was cool and dandy, just add 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.)

In case anything went wrong and you wish to go back to your previousALSA installation, no problem:

Understanding the ALSA Loopback sound card structure

Well, this is not too difficult to grasp. This virtual sound cardconsists of 2 devices:

• hw:Loopback,0
• hw:Loopback,1

If an application outputs its audio to one of the subdevices e.g. sayhw: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.

So the generic principle is that an output signal to subdevicehw:Loopback,i,n becomes an input signal from hw:Loopback,j,n with

Building an asoundrc file

The goal is to create a default ALSA plug device out of the Loopbackcard. For a complete software solution, we need one PCM playback, soALSA apps can send audio to it, one PCM capture, so ALSA apps can getaudio from it, and combine these 2 PCMs into a nice full duplex 'plug'device.

Note that the underlying goal is this: I want the audio of my jacksystem capture ports (from my RME card) to be available at the ALSAcapture device and vice-versa: hear from my jack system playback portswhat ALSA apps are playing back to the ALSA playback device. Tricky...

asoundrc definition

The asoundrc below should work in most situations.

In summary:

This asoundrc is very generic and one can of course tailor it in termsof sample rate, audio format, buffer size, etc. One can find therelevant parameters in the ALSA-libdocumentation.

Some html5 browsers (i.e. Firefox 30; Chrome 38) will fail to open the pcm.!default device for audio playback. This can be fixed by using pcm.card0 instead:

Here is an example applicable to my DAW. I left some notes so youunderstand the extra stuff I also removed unnecessary dsnoop's anddmix's because when you analyse things a bit more, you realize that someof the ALSA PCMs will only be used by one single client (alsa_in/out)so there is no need to use dmix / dsnoop. Dmix only makes sense for theALSA playback PCM because you can have more than one client outputtingto ALSA at the same time. Anyway, note the hardware parameters I haveadded so that it matches my RME Multiface II requirements. For the dmixbuffering parameters, read on below.

Testing our new default ALSA device

Save this asoundrc config into $HOME/.asoundrc but make sure beforethat you are not overwriting an existing asoundrc file (back up whateveryou have if it already exists).

OK, now we can test it from the command line. If jack is running on yourother hardware (RME card in my case), you of course will not hearanything since we have not bridged yet our default ALSA device to thejack graph.

You can use another app (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 :)

The Jack Bridge

OK, this is where it will get a little bit confusing because of theloopback nature of the virtual device ;)

Creating permanent Jack clients using alsa_in and alsa_out

Since we used subdevice 0,0 for playback and subdevice 0,1 for capture,remember that signals from these subdevices will be available byloopback to the corresponding subdevices, respectively 1,0 and 1,1 inthis case. So the trick for jack is to use alsain and alsaout on thelatter subdevices :) Brilliant ins't it ? :D

Let's do it from the terminal

I hope you start to see the underlying idea. Once these clients show upin the graph, when an ALSA app plays back to subdevice 0,0 (default ALSAdevice defined in our asounrdc), the signal will be available insubdevice 1,0, which 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 :)

In order to avoid the warning messages from alsa_in/out, you can addthe relevant parameters, e.g. (my case):

On the other hand, if you connect a jack system input port to the'ploop' client created by alsa_out, the signal is sent to loopbacksubdevice 1,1 which will be looped back to subdevice 0,1. This subdeviceis nothing but our ALSA capture device, defined in asoundrc :). So nowyou can record say your bass or guitar or voice (from your jackhardware) to an ALSA app that does not support jack. I tried skype, andit works just fine. You can also try the command line app calledecasound, which does support jack but also ALSA. It is a VERY convenienttool to have around (see further down).

The beauty of it is two-fold:

• permanence of the 'cloop' and 'ploop' clients (if you shut down yourALSA app, cloop and ploop will remain, always listening
• if jack crashes, it will bring down cloop and ploop but will notdisrupt the ALSA apps since they only talk to the loopback soundcardwhich is completely independent of the jack environment :D

Create scripts to automate bridge initialization via QjackCtl

The creation of the 'p/cloop' clients can be automated, together withtheir connection to jack system ports. Here is my script:

Jack 6.0 Bridge Software

Note that I used -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 / latency

In qjackctl (which I use, YMMV), go to Options -> Execute afterserver startup and add

OK, now that you have added all this, save the qjackctl config, quit andrestart it. Start jack, you should see the ploop and cloop clients inthe graph with the connections between the ports we chose in theloop2jack script.

Test it: open say lmms, load a demo project, play it :)

And voila! try skype, which you can record in ardour if you want (don'tforget to connect your jack system mic directly to the ardour trackwhich you had connected to the 'cloop' client or you will miss recordingwhat you are saying to the other person ;)

So this was a pure software solution and this has the benefit that allyour jack input ports are available to the ploop jack client so thatALSA apps can record the audio coming from these jack ports via thelooped-back device. Of course, the loop stuff has latency (the defaultdmix and dsnoop buffering is quite big), but who cares ? ... Wellactually, I did care a little so I revisited some things and estimatedthe latency added by the Loopback device. I also tweaked a hybridsolution where the ALSA capture PCM is using a real hardware (onboardchip or extra soundcard). Just read below.

Jack 6.0 Computer Bridge Software

Alternative Setup: hardware and software based solution

As mentioned in my introduction, I happen to have an onboard chip (IntelHDA) but also a USB webcam with a built-in mic. It would be a shame notto use their recording capability in some way, especially since I tendto use skype from my DAW PC quite often.

Adding extra h/w inputs in asoundrc

So instead of using the Loopback device for the ALSA capture (all thestuff related to 'ploop' in the previous asoundrc), I simply declaredthe extra h/w in the asoundrc. So I removed all the ploop stuffincluding the now useless Loopback subdevices used for ALSA capture andalsa_out, and added hw PCM devices on the Intel device and USB webcam.

Testing the new ALSA capture

This one was easy to test. I made sure that my asoundrc default cardused the 'usb' pcm capture (see above). I then fired up skype, set it touse the 'Default' device for everything. I fired QasMixer (a nice QT4based mixer if you don't know it) and controlled the capture level ofthe USB webcam from there (I do not let skype control my levels). Then Itried the skype test call and made sure it recorded my voice. The webcamis by the way a Logitech Webcam C310 which I am satisfied with. Worksout of the box in linux due to its class compliance with USB vid.

Note that the same thing can be done with the Intel HDA capture ('intel'pcm capture defined in the previous asoundrc) provided that you plug amic to its input jack of course :)

Measuring the latency introduced by the Loopback device

For measuring the latency, I had to be able to provide both Jack andALSA with a common audio source.

Playback only

First, I fired up jackd and alsa_in on 'cloop' (just as before). Then,I used ecasound as the middle-man for allowing the measuring of theeventual delay in ardour (which I am comfortable with, you can of courseuse another jack enabled recording software if you want).

Here is the ecasound command line, very simple:

Then in qjackctl, I connected a sound source like my microphoneavailable at system:capture_3 to ecasound:playback_1/2.

In ardour, I created two tracks: one mono track accepting audio from thesame system capture port, and a stereo track connected to the 'cloop'client. Indeed, since ecasound outputs to the default ALSA device, thecloop client should have the audio by loopback. I then recordedsomething in ardour so both tracks contained data coming from the sameaudio source. I compared the resulting waveform and observed a delay of120 ms when the dmix parameters are set to default.

Jack 6 Bridge Software

Another way is to use the click sound ardour provides, instead of amicrophone as mentioned above. Just connect the ardour click outputports to ecasound's input ports, and connect the click ports to one ofthe ardour tracks, the other one should still receive the cloop clientdata. If you fiddle with the dmix parameters in the .asoundrc, you willobtain various delays. It is therefore up to you to decide how theperiodsize and buffersize params must be set.

A 120 ms delay is not bad at all considering the huge buffering dmixconfigures by default. But remember that dmix really sucks at smallbuffering so you have to choose a reasonably large one. I ended up usingthe following:

This setting gives me a final Loopback latency of ~ 35ms, while dmixdoes a good job without choking.

Capture and Playback

If you are using the complete software solution (ALSA playback andcapture via cloop and ploop), then you can still use ecasound as anintermediate tool. Just fire it up in this way:

In qjackctl, connect the ardour click ports to the 'ploop' ports. Thiswill allow ecasound to record the ardour click via the looped-back ploopaudio. Then ecasound will output it to the default ALSA pcm playbackwhich alsa_in collects via the cloop client.

Jack 6.0 Bridge Software

In ardour, just like the setup above, have two tracks, one receivingthe internal ardour click directly, the other connected to the cloopports. Arm the tracks for recording, enable the click, activate thetransport. You will see audio data in both tracks, one is delayed ofcourse (the one connected to cloop). With my tuned asoundrc, I get anoverall Loopback latency well below 100ms (approximately 75ms). It isnot bad at all for the whole purpose of the Loopback bridge.

If low latency is a concern, don't use ALSA only apps, use jackifiedapps :D

Final word

I hope all this was clear enough. The idea behind this was to use a h/wcapture device instead of the Loopback device. This reduces the role ofthe Loopback device to ALSA playback only, and removes the need ofalsa_out, sparing some CPU and jack process cycles. At the moment, I amusing my USB webcam for capture because I only need ALSA capture forskype. The Intel HDA is available as well but I don't really need it. Itis connected to my patch panel though, so I can always use it if theneed comes (unlikely).

Troubleshooting

Jack Bridge Software

If you have pulseaudio on you machine, better kill it, overwise it doesn't work.