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