[alsa-devel] Software mixer at kernel level

[Takashi Iwai]

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
   server)

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.


Takashi