From owner-freebsd-multimedia@FreeBSD.ORG Tue May 31 11:29:40 2005 Return-Path: X-Original-To: freebsd-multimedia@freebsd.org Delivered-To: freebsd-multimedia@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D434C16A41C for ; Tue, 31 May 2005 11:29:40 +0000 (GMT) (envelope-from mat@cnd.mcgill.ca) Received: from drizzle.cc.mcgill.ca (drizzle.CC.McGill.CA [132.206.27.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A57C43D53 for ; Tue, 31 May 2005 11:29:40 +0000 (GMT) (envelope-from mat@cnd.mcgill.ca) Received: from mailscan2.cc.mcgill.ca (mailscan2.CC.McGill.CA [132.216.77.249]) by drizzle.cc.mcgill.ca (8.12.11/8.12.3) with ESMTP id j4VBTX8p011912; Tue, 31 May 2005 07:29:39 -0400 Received: from cube.cnd.mcgill.ca (cube.CND.McGill.CA [132.216.25.196]) by mailscan2.cc.mcgill.ca (8.13.0/8.13.0) with ESMTP id j4VBTLT8006263; Tue, 31 May 2005 07:29:21 -0400 (EDT) Received: from localhost.localdomain (acid.cnd.mcgill.ca [132.216.11.151]) by cube.cnd.mcgill.ca (8.12.11/8.12.11) with ESMTP id j4VBTADK006757; Tue, 31 May 2005 07:29:10 -0400 Received: from localhost.localdomain (acid [127.0.0.1]) by localhost.localdomain (8.12.11/8.12.11) with ESMTP id j4VBTAW2025874; Tue, 31 May 2005 07:29:10 -0400 Received: (from mat@localhost) by localhost.localdomain (8.12.11/8.12.11/Submit) id j4VBT9ri025873; Tue, 31 May 2005 07:29:09 -0400 Date: Tue, 31 May 2005 07:29:09 -0400 From: Mathew Kanner To: Scott Long Message-ID: <20050531112909.GB23984@cnd.mcgill.ca> References: <4298F0AB.2090404@ebs.gr> <20050530032202.GC892@rndsoft.co.kr> <429A8DE9.10702@samsco.org> <20050530141539.GC23457@cnd.mcgill.ca> <20050531023302.GC4879@rndsoft.co.kr> <429BCEF8.2020101@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <429BCEF8.2020101@samsco.org> User-Agent: Mutt/1.4.2i Organization: I speak for myself, operating in Montreal, CANADA Cc: freebsd-multimedia@freebsd.org, Mathew Kanner Subject: Re: Project Weevil [was: maestro3 hardware volume control] X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2005 11:29:41 -0000 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