Date: Mon, 3 Nov 1997 06:31:03 +0100 (MET) From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> To: multimedia@freebsd.org Subject: audio modules for various applications Message-ID: <199711030531.GAA17080@labinfo.iet.unipi.it>
next in thread | raw e-mail | index | archive | help
Hi,
with both Amancio's and my driver now being in the source tree, I
think this is a good time to revise the audio modules used by
various applications.
I went through this a couple of months ago, and noticed that several
audio modules were not -- in my opinion -- very high quality, often
misusing features of the device driver or using redundant call. In
other cases (e.g. full duplex support for the SB16 with vat/rat)
the OSS API was unable to support the desired features so I add to
implement and use new ioctl() calls.
As a result, I have rewritten some of these modules specifically
for my audio driver. At this point, however, a merge is abviously
necessary.
Basically my idea is to use the OSS API as much as possible, and
revert to calls specific of my audio driver only when the same
thing cannot be expressed using the OSS API. Ideally, my "soundcard.h"
should be a superset of the OSS one, and should include some unique
macro to distinguish it from OSS. The typical audio module needing
the use of new API calls should be something like this:
int have_new_driver = 0 ;
...
/* near open time... */
#ifdef SOME_NEW_IOCTL
if (ioctl(fd, SOME_NEW_IOCTL, &foo) >= 0)
have_new_driver = 1 ;
#endif SOME_NEW_IOCTL
/* where new features need to be used */
#ifdef SOME_NEW_IOCTL
if (have_new_driver) {
... use the new API ...
} else
#endif
{
... use the OSS API
}
The above should allow the code to compile with both drivers, and to be
able at runtime to detect either one.
Hopefully this should be restricted to the smallest possible set of
programs.
Since many programs already work unchanged with the OSS API and my
driver, I would like to focus on vat, nas, timidity and speak_freely
which are the ones for which I have a replacement driver. Of
course if others have noticed a poorly written audio module (e.g. one
which causes the app to eat a lot of CPU because of the use of
busy-wait loops, or one which does not check for short reads/writes or
other abnormal conditions) this is a good chance to fix them.
So I would like to know if there are users of Amancio's driver who can
help on this.
Cheers
Luigi
-----------------------------+--------------------------------------
Luigi Rizzo | Dip. di Ingegneria dell'Informazione
email: luigi@iet.unipi.it | Universita' di Pisa
tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy)
fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/
_____________________________|______________________________________
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711030531.GAA17080>