From owner-freebsd-current Thu Sep 25 19:16:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA29764 for current-outgoing; Thu, 25 Sep 1997 19:16:39 -0700 (PDT) Received: from gaia.coppe.ufrj.br (jonny@[146.164.5.200]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA29759 for ; Thu, 25 Sep 1997 19:16:35 -0700 (PDT) Received: (from jonny@localhost) by gaia.coppe.ufrj.br (8.8.7/8.8.7) id XAA04366; Thu, 25 Sep 1997 23:16:20 -0300 (EST) From: Joao Carlos Mendes Luis Message-Id: <199709260216.XAA04366@gaia.coppe.ufrj.br> Subject: Re: pcm device has a conflict with FreeBSD(98)? (Re: cvs commit: src/sys/i386/isa/snd In-Reply-To: <199709260047.CAA25457@labinfo.iet.unipi.it> from Luigi Rizzo at "Sep 26, 97 02:47:13 am" To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Thu, 25 Sep 1997 23:16:20 -0300 (EST) Cc: current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk #define quoting(Luigi Rizzo) // Date: Fri, 26 Sep 1997 02:47:13 +0200 (MET DST) ^^^^^^^^ Late night hacking ? :) // > Is it really needed to include support for ALL kinds of sound cards // > if I need just one ? This is not scalable. I would prefer a common // > framework for audio devices, and stubs for each card family. Maybe // > two separate frameworks, if synthesizer support is added someday. // // I understand your concern, but as long as there are going to be 2-3 // mainstream codecs and tens of different card which emulate these 2-3 // differing only in the attach routine, I do think mine is a reasonable // approach. My fear is that this limits the addition of a completely new codec sometime. A good implementation should not restrict the options. For example, I have once implemented an audio output from a D/A converter normally used for control systems. This has been done in the old days of DOS modplay, in which a assembler driver was easy to add and soundcards were a rarity around here. It's not something everybody would have, of course. But could make scientific signal processing more readily available with the same interface as audio cards. For most applications what is needed is some kind of constant rate sampling/output. Indeed, I've heard of some universities doing low frequencies spectral analysis with audio cards. // Audio cards are not as different as, say, ethernet cards, for which // having different drivers is reasonable because they are way different // from each other. And btw the "ed" and "de" driver now do the same That's why I talked about a framework (like controller snd0 ?) and devices. And even on ethernet devices there's a pseudo-device ether to collect commom routines. // I have been thinking on the structure for quite some time, it is not a // decision I took out of the blue. I didn't want to mean that. Sorry if I meant. Jonny PS: Am I wrong or your driver is 100Kbytes smaller than the previous one ? :) -- Joao Carlos Mendes Luis jonny@gta.ufrj.br +55 21 290-4698 jonny@coppe.ufrj.br Universidade Federal do Rio de Janeiro UFRJ/COPPE/CISI PGP fingerprint: 29 C0 50 B9 B6 3E 58 F2 83 5F E3 26 BF 0F EA 67