LinuxMusicians

I'm curious... why do you prefer Jack? Does it make any difference in a case like this? In my view it only adds one layer of complexity...

How can I use multiple soundcards with JACK?

JACK is fundamentally designed to be a component in a pro-audio/music creation environment and standard operating practice for such setups involves using only a single digital sample "clock" (something counting off the time between audio samples). This means that trying to use multiple independent soundcards is problematic, because each soundcard has its own sample clock, running independently from the others. Over time, these different clocks drift out of sync with each other, and cause glitches in the audio. You can't stop this drift, although in some cases the effects may be insignificant enough that some people might not care about them.

Thus in an ideal world you should not use multiple independent soundcards but instead use a single device with a single clock and all the inputs, outputs and other features that you need.

Of course, a lot of people don't live in an ideal world, and believe that software should make up for this. Accordingly, JACK offers several ways for you to use more than 1 device at a time.

1. Use the alsa_in and alsa_out clients (Linux & ALSA only)

If you are using JACK on Linux and want to use additional devices that have ALSA driver support (i.e. most PCI, USB and Bluetooth devices), then this is the best option.

alsa_in and alsa_out are two clients written by Torben Hohn that make a single specified ALSA device appear as a set of JACK ports. They both use Erik de Castro Lopo's libsamplerate library to do any resampling required to keep the audio in sync as the clocks of each device drift over time.

To use them, you start JACK as normal. Then you start an instance of alsa_in or alsa_out for each additional device (and "direction") that you want to use. alsa_out will create a set of ports representing the playback capabilities of the device, and alsa_in will represent the capture/recording capabilities. These two clients must be run inside a terminal window - there is no GUI for either of them. They both take arguments very much like those of the JACK ALSA backend, with some additional controls that affect the way that resampling is done. Full details are available in the man pages for each client, which you can read in a terminal window with the command man alsa_in (this page covers both clients, since their arguments are identical).

Note that you can use these clients even if you are running JACK with a FFADO-supported device. The requirement for ALSA support only applies to the extra devices you want to use, not the one that JACK itself is using.

...

Source: http://jackaudio.org/multiple_devices

$ man alsa_in

$ arecord -l

$ alsa_in -j line_in_nvidia -d hw:NVidia,0,1 -v -c 2

Some people recommend zita-ajbridge over alsa_in/out, if you want to check it out. http://apps.linuxaudio.org/apps/all/zita-ajbridge

Zita-ajbridge provides two applications, zita-a2j and zita-j2a. They allow to use an ALSA device as a Jack client, to provide additional capture (a2j) or playback (j2a) channels. Functionally these are equivalent to the alsa_in and alsa_out clients that come with Jack, but they provide much better audio quality. The resampling ratio will typically be stable within 1 PPM and change only very smoothly. Delay will be stable as well even under worst case conditions, e.g. the Jack client running near the end of the cycle

luster wrote:Thanks, briandc. Zero probably wouldn't have been too bad.

Using information gained from the latency test suggested at:

http://manual.audacityteam.org/man/Latency_Test

I set the latancy correction in Audacity to -24.69ms to achieve within-one-sample recording time matching. This is at 48kHz sample rate on a dual-core 3GHz machine w/8GB RAM, using a Peavey PV8usb mixer as the master audio device in KXStudio 12.04.1. I used a mic > mic input on the mixer for the latency test.

Without that setting, it was off by about 25ms.

luster wrote:Have you checked all the mixers installed on your system to ensure that all unused inputs are muted?

briandc wrote:I would directly ask the guys at the audacity forum. They answer usually within the same day and are very kind and helpful

Nachei wrote:

luster wrote:Have you checked all the mixers installed on your system to ensure that all unused inputs are muted?

Yes, I think I did at some point, but I've tried again anyway just in case. Alsamixer shows two devices:

1) HDA Intel (inbuilt sound card)

I tried setting to 0 (+muting when available) ALL parameters, even Master. The bleeding persists just the same.

2) USB Codec (G-Track)

It only has 1 parameter available, called PCM I think. Whenever I mute it, I cannot listen to the music playing during the recording process; but the bleeding is not modified. Also, I tried to intermittently mute/unmute this Alsa element, and the bleeding in the background is still continuous, no chopping related to my on-off action.

This test of mine assumes that "all the mixers", in your message, refers to all the Alsamixer parameters existing. I also made a stripsearch through the computer's menus, and a find command, in case you meant that there is some other program along the mixing chain, but nothing relevant seems to show. Am I missing something?

briandc wrote:I would directly ask the guys at the audacity forum. They answer usually within the same day and are very kind and helpful

Thank you very much for the direct link. However, the first thing I found there was a red warning saying that Audacity version 1 is no longer supported. I checked and, alas, The Audacities in my different installations are 1.3.9. and 1.3.11-beta (Unicode). Installing a new version of Audacity is a complex task; my both Audacities came bundled with different Puppy Linux distributions. The good part was not having to install anything, but the other side of the coin with Puppy Linux is that, being so lightweight, you usually have a long journey through dependencies hell whenever you want to install something. So I think I'll try exhausting the other simpler options first.

Another thing, regarding blacklisting modules, it is funny to see how my question fell immediately into the 'void of silence' again. Could someone drop a couple of lines on the issue? I don't mean to be bitching, but I wonder why does EVERYBODY keep silence about it. Is it a touchy subject in any way? (As a refresher, my idea was disabling the modules of the inbuilt sound card and use G-Track for everything sound related, in order to detect if the problem stems from that internal sound card being faulty.) Thank you guys.

I've repeated my AB tests and the results are consistent with yesterday's: output sent through G-Track= track recorded with bleeding and chopping, output sent through internal Alsa, track recorded fine. So I guess the problem gets solved like that, if not with the bonus of understanding what is going on...