On Thu, Jan 8, 2015 at 12:27 PM, Brent Busby <brent@keycorner.org> wrote:

On Thu, 8 Jan 2015, Arve Barsnes wrote:

On 8 January 2015 at 15:10, Len Ovens <len@ovenwerks.net> wrote:

Just? Just routing all programs to alsa means each or any blocks all others.
One ends up with the mess that at least three audio servers have been tried
of which Pulse seems to be the one that has been chosen

I keep seeing people say this, but I have never noticed any program blocking the sound of any other. I can play sound from mplayer, audaciuos, audacity, firefox, whatever, all at the same time, never had pulseaudio installed, everything through alsa. What am I doing wrong? :p

I've been wanting to say the same thing up until now, but I thought maybe I was missing something stupid. I haven't had problems with exclusive sound access either, at least since the OSS days. If anything, that was one of the big improvements going to Alsa from OSS -- no more device contention between applications, no more need for horrible esound and artsd userspace daemons to try to multiplex streams for you. Now, apparently, even Alsa needs userspace help to deal with consumer audio. But why? It already worked!

it never worked at the device driver level. ALSA only ever did mixing in userspace via dmix, which works *most* of the time but is not reliable enough in the general case. it isn't super hard to find the corner cases that will cause dmix to goof.

old school consumer audio used to involve hardware level mixing, but this started dying out in the very early 2000's and is now completely gone. all devices now assume software is used to mix streams.