On Thu, Jan 8, 2015 at 12:27 PM, Brent Busby <brent(a)keycorner.org> wrote:
On Thu, 8 Jan 2015, Arve Barsnes wrote:
On 8 January 2015 at 15:10, Len Ovens <len(a)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.