Project Weevil [was: maestro3 hardware volume control]

[Mathew Kanner]

On May 30, Scott Long wrote:
> Pyun YongHyeon wrote:
> 
> >On Mon, May 30, 2005 at 10:15:40AM -0400, Mathew Kanner wrote:
> > > On May 29, Scott Long wrote:
> > > > Pyun YongHyeon wrote:
> > > > >On Sun, May 29, 2005 at 01:28:59AM +0300, Panagiotis Astithas wrote:
> > > > 
> > > > It might be possible to examine the system SMBIOS table for the make 
> > and
> > > > model of the system and use them as keys for a quirk table.  Of course
> > > > it will only work for systems like laptops that have the M3 or A1 chip
> > > > embedded.  sigh.  I think that this all works in the Windows world
> > > > because the hardware maker provides a driver that is customized 
> > > > appropriately.
> > > 
> > > 	Sorry about hijacking this but what a opportune moment...
> > > 	Project Evil provides %75 of the infrastructure (the hard
> > > stuff no less) of what is needed to get audio drivers off the ground.
> > > 	Anybody want to start of proof of concept?  Perfect use for
> > > those CDs that came with your motherboard.
> > > 
> >
> >I don't know whether it's possible or not. I have no experience of
> >ndiscvt(8). Personally, I don't like to use Windows drivers as it
> >severely limits the driver to x86 based architectures. I think Linux
> >supports wide-ranges of audio hardwares than that of FreeBSD.
> >If we can pour our time on reading Linux driver we would get better
> >audio support, IMO.
> >
> > > 	--Mat
> >
> 
> We probably need to work on more modern sound infrastructure before we
> start thinking about supporting NDIS-style drivers.  While it might be
> possible to map a small subset of the driver functionality to our
> voxware API, it's really not going to help much in the long run.  I
> don't know what the correct answer is here for future direction either.
> ALSA has been the 'next big thing' for the past 5 years, but really
> doesn't seem to be living up to the promises.  Should we try to
> implement it anyways and use it as the foundation for our
> next-generation PCM framework, or should we moderize the newpcm API
> ourselves and hope that ports authors will follow us when/if ALSA does
> gain traction?

	Well, a mini-port interface for windows drivers would be
exciting --  I hold to the fantasy that some hot-shot hacker is going
to surprise us.
	As for ALSA, there's a chance that we could provide enough of
the kernel infrastructure to support their drivers.  I would see that
as a more feasible task that providing a userland library compatible
interface.  But as for the final assessment, there's something to learn
from what they've done -- we need more extensibility so we can provide
knobs for new features to the users.
	As for realistic plans, I think some of what we have is
excellent and we should try to keep it and modernize the sound
infrastructure in stages.  The first stage would be to redo the middle
layer buffering.  Then the front end kernel-userland and try to factor
out OSS support so we aren't so bound to it.  At the same, providing
the knobs for features that OSS didn't anticipate (either by sysctl,
or sndctl).  All the while, we keep our drivers intact.  This would
mean, as Pyun YongHyeon says,  that would have to 'pour our time on
reading Linux' so that we could maintain our drivers with surprises
the manufacturers throw at us.

	--Mat