Date: Mon, 02 Nov 1998 13:07:59 -0800 From: grady@xcf.berkeley.edu (Steven Grady) To: multimedia@FreeBSD.ORG Subject: Re: How can we switch to a higher-level audio interface? Message-ID: <199811022107.NAA04481@hub.freebsd.org> In-Reply-To: Your message of Mon, 02 Nov 1998 12:26:26 -0800 <199811022025.MAA29067@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Sorry to reply to my own e-mail, but in thinking about things some more,
I had a couple additions to the list of approaches. So v0.2 version:
Changes:
Added approach of tcl library
Added approach of just porting programs which play entire files
Added disadvantages about source-less distributions
Added ads/disads about event-loops in ports
====
Change the device driver so that multiple access is allowed.
Advantages: no applications need to be changed. Addresses the
most obvious problem with the least amount of effort.
Disadvantages: terrible design -- that kind of functionality should
_not go in a device driver. Doesn't address all the
problems. Not beneficial outside the FreeBSD world.
Dangerous -- bugs in tricky algorithms could cause system
to crash.
Implement a dynamically-loadable device driver that allows multiple
access.
Advantages: no applications need to be changed.
Disadvantages: Still not a good design. Doesn't address all the
problems. Not beneficial outside the FreeBSD world. Requires
additional non-trivial work to make the sound driver dynamic
(although I think this should be done by someone anyway).
Still dangerous.
Port all the applications to use NAS (or rplay, kaudioserver, etc.).
Advantages: Moves to more X-like model.
Disadvantages: SERIOUS porting effort. Locks into one audio API
(which may not end up being standard). Such major changes
may not be accepted back into code base by original
developers. Existing APIs are still fairly low-level. Chosen
audio interface must be debugged (both client and server),
potentially enhanced to support all existing device-level
functionality. Porting may involve fundamental changes
to support asynchronous event handling. No port possible
for sourceless programs (e.g. x11amp).
Develop toolkit-level API, port all to use that API, implement
on top of one or more audio server formats. Ultimately, create
multiple language bindings.
Advantages: Moves to more tk-like model. Programs that use
audio in a simple way (e.g. playing a sound) may require
very simple changes, promoting acceptance by original application
developers. Eases cross-platform (i.e. beyond UNIX) implementations.
Easy to switch low-level interfaces to use the best (most
robust and/or functional). Conceivably possible to avoid
changing event loop when porting code, by forking (yecch).
Disadvantages: SERIOUS development effort. Non-trivial porting
effort. For audio-intensive applications (timidity, speak freely,
etc.), not likely to be accepted back into original codebase
(until toolkit becomes established). Proliferation of
libraries either bloats code, or causes installation
problems (with dynamic libraries). No port possible
for sourceless programs (e.g. x11amp).
Develop toolkit-level TCL extension on top of existing server interface.
Port simple applications to use TCL.
Advantages: Moves most to tk-like model. Possible to develop very
clean interface, since TCL already uses event loop. Potentially
extensible to other platforms that use tk -- perl, etc. New
applications can be developed quickly.
Disadvantages: Restricted initially to TCL code. Audio output only
sharable with other applications that can use TCL.
Standardize on NAS (or whatever) in FreeBSD, port simplest
audio programs (those that currently invoke "cat $* > /dev/audio",
or something similar) to use "auplay" (or equivalent for
appropriate server).
Advantages: Ports are trivial. Least amount of effort.
Disadvantages: Many interesting programs (timidity, speak freely,
x11amp, etc.) do more than just cat a file. Audio output only
sharable with other applications that use NAS. Possibly choose
wrong server to standardize on (since trivial programs don't
exercise interface enough to reveal lack of robustness/functionality).
--
Steven
"Like all reputable surgeons, I charge by the pound..."lsmo
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-multimedia" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199811022107.NAA04481>