Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

In alsamixer I can select either PCM Out or IEC958 In (that's my S/PDIF input) but not both. Is there a solution?

Note: I need stereo sound, so selecting IEC958 In for one channel, and PCM Out for the other is not an option.

I even tried OSS4, but it's the same: cannot hear S/PDIF input and PCM Out simultaneously. I feel like I'm missing something obvious and I would really appreciate any help.

The reason why I want this is the following: I have two computers, and use them both. However, to fully utilize secondary computer I need to hear its sounds without manually switching channels in alsamixer (yes, I know it is possible to write a script and assign it to a shortcut, but this does not solve my problem).

share|improve this question
add comment

1 Answer

up vote 1 down vote accepted

I have finally found 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 JACK

apt-get install qjackctl jackd2

Configure 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 (http://alsa-project.org/main/index.php/Asoundrc).

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 [i]not[/i] affect sound quality in my case, so I ignore them.

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.

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 (http://science.su/stuff/linux/sound/jack/without_alsa_jack_plugin/asound.conf). 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 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 even with relatively large buffer_size - 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 for 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 (http://pf.natalenko.name). Author does not provide deb files, but links to somebody's site who does (http://kernel.night-leshiy.ru) - 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 microseconds 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.

BFS is not the best scheduler, but it works much better then scheduler in vanilla kernel 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 (http://code.google.com/p/rifs-scheduler/downloads/list) if you up to compiling your own kernel. If you are, install kernel-package and read this howto (http://vanilja.org/kernel).

Hope my experience will be useful to somebody.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.