Date: Mon, 30 May 2005 20:42:00 -0600 From: Scott Long <scottl@samsco.org> To: yongari@rndsoft.co.kr Cc: freebsd-multimedia@freebsd.org, Mathew Kanner <mat@cnd.mcgill.ca> Subject: Re: Project Weevil [was: maestro3 hardware volume control] Message-ID: <429BCEF8.2020101@samsco.org> In-Reply-To: <20050531023302.GC4879@rndsoft.co.kr> References: <4298F0AB.2090404@ebs.gr> <20050530032202.GC892@rndsoft.co.kr> <429A8DE9.10702@samsco.org> <20050530141539.GC23457@cnd.mcgill.ca> <20050531023302.GC4879@rndsoft.co.kr>
next in thread | previous in thread | raw e-mail | index | archive | help
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? Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?429BCEF8.2020101>