Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 25 Sep 1997 23:16:20 -0300 (EST)
From:      Joao Carlos Mendes Luis <jonny@coppe.ufrj.br>
To:        luigi@labinfo.iet.unipi.it (Luigi Rizzo)
Cc:        current@FreeBSD.ORG
Subject:   Re: pcm device has a conflict with FreeBSD(98)? (Re: cvs commit: src/sys/i386/isa/snd
Message-ID:  <199709260216.XAA04366@gaia.coppe.ufrj.br>
In-Reply-To: <199709260047.CAA25457@labinfo.iet.unipi.it> from Luigi Rizzo at "Sep 26, 97 02:47:13 am"

next in thread | previous in thread | raw e-mail | index | archive | help
#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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709260216.XAA04366>