How to automatically share/mix the audio device?

Question

I'm using Arch with LXDE on a Core i5. The sound card is an Intel 6 series / C200 controller (just a DMA engine, really.)  Most programs these days seem to use ALSA. This includes some simple programs I write, as well as utilities like "espeak."
If a program I've written happens to be playing some sound, while I try to use another program (say, "espeak") that also uses ALSA, only the first program works, and the second program errors out. This has all the convenience of using a Sound Blaster under Windows 3.1! :-)
Surely, there exists some configuration option or package or kernel module I can install to make the system mix any and all programs that use ALSA to play sounds? What am I missing?

Answer 1

I used to love hardware mixing sound cards ten years ago, but as CPUs get faster, it's gotten to the point where it doesn't matter, and certain things (like echo cancellation supported at the OS level) really require the OS to be in control.
Regarding re-initializing the device: I don't see why it would take a full second. DMA is fast, codecs are fast. I've written probably ten different sound card drivers in my life, and none has been even close to a second in setup time. However, I'd be perfectly happy if the only cause for going bit perfect is needing to output AC3 to the SPDIF output. For everything else, run the card at 48 (or whatever is preferred) and however many speakers are connected, and convert all the incoming audio. If the card can't detect speakers connected vs not, default to stereo, and let the user configure it if it's wrong. This will make things Just Work (tm)!
To be clear, a reasonable default behavior might be:
0) The lowest-numbered sound card is default, if not user-configured differently.
1) If the default card can detect speakers plugged in, configure itself for that set of speakers. If not, configure itself for stereo, if not user-configured differently.
2) Set the default playback frequency to 48 kHz if supported, else the highest frequency that's supported, if not user-configured differently.
3) When applications open the device, just say "yes" to whatever is requested, and do software re-sampling/mixing to the default format, if not user-configured differently.
4) If applications ask for formats, propose the default playback frequency at the default playback number of channels at floating-point sample format.
5) Use a 7-tap polyphase filter for resampling if not configured differently; this gives a great quality/performance trade-off using SIMD implementations. (15 years ago, we used a 4-tap Hermite interpolator, which had higher distortion and lower runtime cost on Pentium II, but time has moved on :-)
6) If a USB audio device or other hotplug device (such as bluetooth) is plugged in, switch to that device, if not user-configured differently. Note that with software mixing, nothing needs to change for applications that are already playing.
Pulseaudio? That would work, if it actually emulated the device driver interface that most applications actually use to play back sound. And it doesn't *have* to be a user-level process; doing mixing/converting in kernel space is perfectly fine assuming we have decent real-time support now. We don't even need to have interrupts disabled while doing it. Double buffers of 512 samples would be plenty for most cases and still have sufficiently low latency to not annoy game players or movie watchers.
Alternatively, the problem is that Linux applications still use the ALSA audio API rather than PulseAudio. But, given that that's the case, there are totally possible solutions that would make life a lot better on average, and no worse in the corner cases.
This is not rocket science -- it's technology that should have existed 15 years ago, and the fact that the Linux community at large hasn't bothered to solve it is a symptom of an attitude that's a barrier to meaningful desktop Linux adoption in the mainstream. And I'm saying this with love :-)
Is there a shim /dev/audio driver which can re-mix/re-route audio to a real hardware device, based on that device's capabilities? Or would the right dmix setting for alsa actually be able to accomplish this? (I imagine such a dmix wouldn't be able to adapt to things like detecting plugged in speakers/headphones, though)
Last edited by jwatte (2013-03-28 00:45:36)