Re: [2.6 patch] schedule obsolete OSS drivers for removal

[Lee Revell <rlrevell@joe-job.com>]

On Thu, 2006-01-05 at 19:47 +0100, Tomasz Torcz wrote:
> On Thu, Jan 05, 2006 at 01:36:20PM -0500, Lee Revell wrote:
> > On Thu, 2006-01-05 at 12:43 +0100, Florian Schmidt wrote:
> > > On Thu, 05 Jan 2006 02:16:35 -0500
> > > Lee Revell <rlrevell@joe-job.com> wrote:
> > > 
> > > > On Wed, 2006-01-04 at 11:37 +0100, tapas wrote:
> > > > > ALSA's kernel level OSS emulation (as opposed to aoss) cannot provide
> > > > > software mixing. As aoss cannot provide OSS emulation to all OSS apps
> > > > 
> > > > Why not?
> > > 
> > > I did write it out before. aoss is a LD_PRELOAD hack. Apps/libs that
> > > resolve the system call symbols at build time cannot be made to use
> > > these calls from a different lib (which is what LD_PRELOAD tries to do).
> > > A famous example is libc for which a workaround was added (as libc
> > > offers its own mechanism to intercept fopen() et al.). Others can lurk
> > > in the background, too. It would even be trivial to write an app that
> > > aoss will not work with - ever (unless the code be modified - which is
> > > not an option for closed source apps).
> > > 
> > > It simply cannot ever work with _all_ apps (as opposed to kernel level
> > > OSS emu  which can be made to work with _all_ apps (at least in
> > > principle)).
> > > 
> > 
> > OK so you can contrive an example.  Have we ever seen a real world app
> > where aoss can't work?
> 
>   Skype. Earlier Quake 3 Arena (now Q3A is open source with SDL sound,
> so it had native ALSA).
>   They're more widely used that musical software for which ALSA seem to
> be written. People needing <1ms latency are "obscure corner cases" in
> real world.
> 

It's not that aoss "can't work" for these, it certainly has some bugs.
But the examples you gave are both proprietary apps.  Obviously we can't
waste our time debugging them.

No one has even been able to provide a test case using an app we have
the source to.

Lee