From owner-freebsd-multimedia@FreeBSD.ORG Thu Apr 28 17:02:53 2005 Return-Path: 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 2A33416A4CE for ; Thu, 28 Apr 2005 17:02:53 +0000 (GMT) Received: from torrent.cc.mcgill.ca (torrent.cc.mcgill.ca [132.206.27.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CAFF43D5F for ; Thu, 28 Apr 2005 17:02:52 +0000 (GMT) (envelope-from mat@cnd.mcgill.ca) Received: from mailscan2.cc.mcgill.ca (mailscan2.CC.McGill.CA [132.216.77.249])j3SH2fMN004920; Thu, 28 Apr 2005 13:02:43 -0400 Received: from cube.cnd.mcgill.ca (cube.CND.McGill.CA [132.216.25.196]) j3SH2OUk029085; Thu, 28 Apr 2005 13:02:24 -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 j3SH28jT023539; Thu, 28 Apr 2005 13:02:11 -0400 Received: from localhost.localdomain (acid [127.0.0.1]) j3SH28Tq015765; Thu, 28 Apr 2005 13:02:08 -0400 Received: (from mat@localhost) by localhost.localdomain (8.12.11/8.12.11/Submit) id j3SH1sVK015764; Thu, 28 Apr 2005 13:01:54 -0400 Date: Thu, 28 Apr 2005 13:01:54 -0400 From: Mathew Kanner To: Alexander Leidinger Message-ID: <20050428170154.GG14507@cnd.mcgill.ca> References: <20050306184416.5603976c@Magellan.Leidinger.net> <20050307030419.GC951@kt-is.co.kr> <20050308.121415.847025091.kazuhito@ph.noda.tus.ac.jp> <426F409D.6010007@elischer.org> <426F4280.9030206@elischer.org> <426F49C3.1020009@elischer.org> <20050427184115.GC11709@cnd.mcgill.ca> <20050428110656.wqnp94nnwosc80ck@netchild.homeip.net> <20050428112754.GB14507@cnd.mcgill.ca> <20050428142007.11hjbs1pcgws4g0w@netchild.homeip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050428142007.11hjbs1pcgws4g0w@netchild.homeip.net> User-Agent: Mutt/1.4.2i Organization: I speak for myself, operating in Montreal, CANADA cc: FreeBSD Multimedia cc: Julian Elischer cc: Mathew Kanner Subject: Re: uaudio patch, X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2005 17:02:53 -0000 On Apr 28, Alexander Leidinger wrote: > Mathew Kanner wrote: > > > I realise I'm the only one whose taken this position so I'll > >withdraw it. But for the record, this is my reasoning, what the heck > >are you going to do with this informaiton: it doesn't help you. > > If you want to go to the soundcard directly, without any conversation, you > need to know what you can use. But this doesn't help. At all. > > > Other > >interesting but often usesless information is printed in boot_verbose. > >The listed capablities are often way beyound what our sound interface > >can offer. > > Just because it can't offer it _yet_, it doesn't mean we don't teach the > interface to use it later. And parts of this improvement can be addressed > from both sides (step by step). But this doesn't help. At all. (Because it isn't an interface, it's only text output). Expanding our abilities for different formats and flagging which ones are hardware based is *completly* serperate project. > > > If you want to know what avaiable then connect to the > >sound device and issue an ioctl like every other app. > > If I have an app which plays some audio files. And if I have the opportunity > to generate the right file with a conversation program which converts > "something" (e.g. text to speach) but doesn't knows about an output device, > and I want to generate the right output, I have to know what I can use. A > human being which just knows about tools, but not about ioctl(), I need > something which tells me what I can use. Do we have an app which does this? > Do we need such an app, or would it be convenient to just look at "cat > /dev/sndstat"? I'm not sure I %100 understand here but I think we should have an app (say mixer) whihc will IOCTL for the caps and report to the user. This is a reporting tool only. Apps that need to know will IOCTL as usual. > > > Anyway, as a general concept, I think we should start > >expanding our using sysctls. > > I think it depends. For status/capabilities/static like output, we should > look at enhancing existing interfaces (if they fit into the big picture of > what we want to add), like our "sound status device". > > For general "mode switching" (whatever this means) which doesn't fit into > the > 4Front-OSS model, sysctl looks like a nice candidate. But another nice > candidate would be a "sndctl" program which may interact with the device > over /dev/dspX.ctl orsomething like this. Oo, a nice thought. > > Is there something specific you have in mind regarding the sysctl proposal? Yes, for now we need commit Kazuhito HONDA patch for uaudio that provices sysctls for all available mixer/device settings. I have a dream (just a dream, I doubt I'll ever achieve it) is that our sound model is based on what the uadio standard provides. When an app wants to know that caps they get a descriptor just like what uaudio gives. Their format has quite a bit of thought behind it and its very flexible. Really, one could take that uadio description and convert it and run it through 'dot' and get a block diagram of the soundcard. That block diagram is usually only available in comments in the source. --Mat