> [PCM Out] doesn't exist in jack. every program is represented and connects seperatly in jack.
It seems that JACK is my only option but the fact that PCM Out does not exist in JACK (and cannot exist) is a problem. Despite the fact that my sound card costs about $200 it doesn't support hardware mixing. Fortunately, I was able to solve this by using ALSA JACK plugin.> second, this should be easy to achive in jack. but, you digital ins/outs should appear in jack
After careful reading of the documentation and Googling it turns out JACK works exactly as it should. I'm supposed to add non-default devices manually - either by creating one big multichannel ALSA device, or by using alsa_in/alsa_out - these two didn't work for me too well no matter what period size I have used, so I created multichannel ALSA device.What confused me in the first place is the fact that nearly everywhere people talk about this only in context of "unifying" multiple sound cards - but in reality this is necessary to use multiple ALSA devices in one card too.> as you said, this can be achieved with alsa and .asoundrc, too
I do not think so anymore. ALSA does not allow to mix input(s) with output(s). It is possible to attempt to do so, but the result will be non-working ALSA device. PulseAudio have similar limitation.
Now, I will describe the solution. I tried many things, but all other configurations/method either gave me bad sound or worked similarly in practice, but were more complex. So I will give here the simplest solution that worked for me (and mention some alternatives which are likely to work at least for some people). I use Debian Testing, so some things I mention are Debian-specific. It should not be too hard to do the same in other distributions.Install JACKapt-get install qjackctl jackd2Configure ALSA
Run this command:sudo apt-get install libasound2-plugins
Here is my /etc/asound.conf
(you can put its contents in ~/.asoundrc - but /etc/asound.conf is better place because it is system-wide). As you can see, it's relatively simple. Device "all" is intended for JACK, and !default - for all non-JACK applications. It is important that the !default is of type plug and not jack, otherwise you will get all sorts of strange problems. You can easily adapt my asound.conf to your needs - it is hopefully obvious how to add or remove audio devices and channels. If not, read the documentation
.IMPORTANT NOTE: If your sound card is capable of hardware mixing, you do not need !default section with ALSA JACK plug-in to hear sound from non-JACK applications. If you are unsure what your card is capable of, run:
cat /proc/asound/card0/pcm*/info | grep count
If at least some devices have more than 1 subdevice, your card is capable of hardware mixing. If hardware mixing is available on your default channels, you can remove !default section from my example of asound.conf.
Only problem in my asound.conf is that analog input (typically microphone) cannot be used as mono if you specified stereo analog input like me. Another strange thing is that I get a lot of XRUNs in JACK but they do not
affect sound quality in my case, so I ignore them.Alternative ALSA configuration (NOT recommended!)
It is possible to write asound.conf without ALSA JACK plug-in, but in my case this resulted in bad sounds with frequent click-like artifacts on inputs despite very large buffer_size (sometimes few artifacts per minute, sometimes one artifact per few minutes) even after upgrade to PF kernel (later I'll explain what is it). No surprise here, because JACK must use your audio devices as directly as possible and this is not the case here. If you want to try this anyway for whatever reason, please see my /etc/asound.conf without ALSA JACK plug-in
. It is more complex than the first one, but I tried to make it as readable as possible. Before trying it, make sure that you are using the same period_size and periods in JACK and asound.conf. I leave this alternative configuration as an example to learn from (you can see how to use various types in asound.conf, how to upmix mono to stereo, etc.).Configure JACK
Here is screenshot of my JACK settings
in qjackctl. Most important settings are "Realtime", "Input device" and "Output device". Everything else is just an example of working setup.Upgrade to better kernel
It is good idea to try to migrate to RT kernel (eventually vanilla kernel will include similar real-time support, but for foreseeable future you have to use patched kernel if you want acceptable audio latency with no artifacts, especially from audio input(s) ). To try RT kernel in Debian Testing or higher you need just run this command (I assume you need NVidia driver; if not, install whatever driver you need instead):sudo apt-get install linux-image-3.4-trunk-rt-amd64 linux-headers-3.4-trunk-rt-amd64 nvidia-kernel-dkms
If RT kernel works for you, feel free to skip the rest of this message. With RT kernel you can hear perfect low-latency sound. But unfortunately many NVidia cards do not work with RT kernels, and mine was one of them (GeForce GTX 295), so I couldn't use RT.Note: with vanilla kernel I encountered click-like artifacts few times per minute in both analog and digital inputs - this was unacceptable, so vanilla kernel did not work for my purpose. If it works for you and you are OK with relatively high audio latency (buffer) you have to tolerate to get acceptable sound, you obviously do not need to change your kernel.
NVidia driver in Debian already contains modifications to work with 3.4 RT kernel, you do not need to modify it, but unfortunately it may give you black screen instead of your graphical interface. In this case, you have to uninstall RT kernel and try something else, for example PF-kernel
. Author does not provide deb files, but links to somebody's site who does
- this site written in non-English language, but whatever language it is, you do not need to understand it, just download deb files with pf kernel and its headers and install them with:sudo dpkg -i linux-*-pf*.deb
PF kernel contains BFS scheduler, and in my Xeon-based quad core workstation with 8 hardware threads (so the OS sees it as 8 CPUs) it reduced worse-case latencies of real-time processes (like JACK) from hundreds of milliseconds to few milliseconds (in my case less than 2ms). This is of course looks as very bad result if you compare with RT kernel (with worst-case latencies of real-time processes within 10-30 micro
seconds range) but MUCH better than vanilla kernel. Personally I use 128 buffer_size with 2 periods - that's ~5ms latency; in my case this is enough to prevent any artifacts in the sound after few hours of testing. With RT kernel even better results should be possible.Note: Yes, I know BFS is not the best scheduler, but it works much better then vanilla scheduler if you want low latency and RT kernel does not work for you. In case you want as small latencies as possible without RT kernel, there are improved BFS with O(1) complexity instead of O(n), and probably even better scheduler - RIFS. You can find them here if you up to compiling your own kernel. If you are, install kernel-package and read this howto.
Hope my experience will be useful to somebody.