[alsa-devel] Software mixer at kernel level
tiwai at suse.de
Tue Feb 10 09:10:25 CET 2009
At Tue, 10 Feb 2009 01:50:54 -0500,
Brendan Pike wrote:
> Sean McNamara wrote:
> > You are welcome to do whatever you want on your system, but don't assume that everyone wants what you want.
> > </rant>
> > _______________________________________________
> Or you could just avoid all this mess with Linux audio for the time
> being and use a hardware mixing device instead. I realize laptop users
> are going to bitchslap me for saying that but its true.
> The whole buggy software mixing situation with regards to applications
> not working correctly or as intended is frustrating. OSS4 does it at
> the kernel level because it tries to be transparent to all the
> applications which think the device has hardware mixing capabilities. I
> realize OSS4 can be buggy for some but its implementation is far more
> compatible instead of the cocktail of sound servers and software
> mixing routines we have in ALSA right now.
> Some apps out there require direct access to /dev/dsp or whatever, what
> are we going to do? Hope somebody updates the program? (usually not
> going to happen with older closed source games or whatnot). Take UT99
> for example, rarely does this ever work with any software mixing period.
Well, we can categorize the demands:
A. OSS-style access needed just because of fixed, binary-only things
B. OSS-style access needed because of old written codes
C. OSS-style access needed because of resource reduction (without
The original question was about C.
However, in this case, it's not guaranteed whether a kernel-side
mixing requires less resources. A server solution could be in less
amount, depending on the implementation. Nevertheless, one certain
thing is that this question is not for generic desktop uses, but for a
pretty limited use-case.
Honestly, I don't mind if anyone introduces a kernel-side thing for
that limited purpose like C for his own project. But, this won't hit
the mainline, anyway...
For other cases, the resource usage isn't *THAT* big problem at all.
The only question is whether it works reliably or not.
It seems that hooking via LD_PRELOAD doesn't work always. Another
interesting approach for the OSS fixed devices is to route via a new
FUSE char-driver extension by Tejun. This is of course more layer
onto the existing setup, but it just works for cases A & B.
More information about the Alsa-devel