Re: ALSA doesn't speak to JACKD

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Pablo, many thanks; you have just solved a problem for me :-)  A few of my system-generic audio was coming out distorted.  So here is what I have now.  So far, I have not been able to detect any reduction in latency or other performance, when compared to using jack-only audio.

My first step was to identify the alphanumeric name (as opposed to the number!) of the sound device I want to use for everything.  This is done thusly:
$ cat /proc/asound/cards
I received the following from the above:
 0 [HD2            ]: Prodigy71HD2 - Audiotrak Prodigy HD2
                      Audiotrak Prodigy HD2 at 0xef80, irq 10

You should have at least one item representing your sound card.  If not, your card is not configured completely to work with ALSA, and I'm afraid I cannot help :-)  Anyway, providing that your desired device is listed in /proc/asound/cards, it will have an alphanumeric name; the one you want is in the square brackets [].  So my card's ALSA name is "HD2".

My second step was to test Jack applications using this alphanumeric name.  In qjackctl setup, in the "Interface:" field, usually it reads either (default) or a numeric device number, e.g., hw:0.   In my case, I set this field to read hw:HD2.  Suddenly all sound on the machine began behaving a bit better.  I don't know entirely why, but I suspect the numeric-to-alphanumeric translation in ALSA either runs slow or gets confused or both.  No matter; alphanumeric is far better, the numerics do definitely get confused when USB audio is plugged in et cetera.  I ran in AVLinux just like this for a while; AVLinux gives me an MPlayer which will do Jack, which is nice, but some annoyances remained.

My third step was to get the ALSA2Jack plugin in.  This is a module for ALSA, which permits it to send output to Jack.  The idea is that we need two audio data paths.  The first is for general latency-irrelevant applications, jack-incompatible, which will run App-->ALSA-->Jack-->ALSAdevice.  The second is for latency-critical applications, which will run App-->Jack-->ALSAdevice.  If we set up the ALSA2Jack plugin's virtual device, as default audio device, and tell Jack to run all of its output direct to the ALSA sound device of explicit choice, we should get the best of both worlds.

So.  This being AVLinux (Debian), I then had to install package "libasound2-plugins", to get the ALSA2Jack plugin in.  Found it in Synaptic.

The last step was to implement an ALSA configuration file handling ALSA2Jack and also the Jack device IDs.  I am now using the below.  The only significant change you will need, is the ALSA mixer should be set to point directly to the alphanumeric name of my ALSA sound device.  Probably should reboot after changing it, just in case.  On the other hand, unlike many who use ~/.asoundrc, I use it as an /etc/asound.conf, which is just a bit different; I don't like the idea of sound configs changing at login, I want them nailed to the wall at boot :-)

J.E.B.

pcm.!default {
    type plug
    slave { pcm "jack" }
}

pcm.jack {
        type jack
        playback_ports {
            0 system:playback_1
            1 system:playback_2
        }
        capture_ports {
            0 system:capture_1
            1 system:capture_2
        }
}

ctl.mixer0 {
    type hw
    card HD2
}

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user

[Index of Archives]     [Linux Sound]     [ALSA Users]     [Pulse Audio]     [ALSA Devel]     [Sox Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux