Date: Mon, 23 Oct 1995 17:36:03 -0700
From: jordan@pongo.West.Sun.COM (Jordan Brown)
Subject: Item #296: Dev Ext: "sound" should specify a single data format


P1275 Openboot Working Group Proposal -- Proposal #:296 Ver 1.0

Title:          Tighter specification of "sound" devices

Author:         Jordan Brown

Date:           19 October 1995

Ed/Tech:        Technical

Synopsis:       Should specify *one* data format; all else is unneeded

Doc & Version:  Device Support Extensions v0.2

Procedural Note:

This proposal addresses some of the same issues that proposal 295
does, using an alternative strategy.  The two proposals are probably
mutually exclusive, and need to be considered together.

Problem:

As has been pointed out in proposal 295, the properties described
in the DSE doc do not fully or clearly describe the configuration
of an audio device.  Proposal 295 attempts to clarify these properties
by expanding them to include the entire breadth of the subject.

I am far from convinced, however, that this is truly the appropriate
approach to take to the problem.  Open Firmware is not a substitute
for OS device drivers.  Open Firmware device methods exist primarily
to support operations *until* OS drivers can be loaded.  As such, it
is not necessary (or, in view of memory issues, appropriate) for OF
drivers to attempt to offer all conceivable services.

Relatedly, a model where the OF device advertises a list of supported
features is not convenient for the expected client.  Such a model
(as is sort of present in DSE 0.2 and is proposed by 295) would
require that the client be prepared to convert its data from
whatever its storage format is into any of a large variety of
data formats that might be required by the target OF device.
Expected OF clients are bootstraps and installation programs, not
audio conversion toolkits!

Proposal:       

Instead, OF "sound" devices should offer a *single* data format, with
the same format required for all devices.  As an example, the DSE might
require that audio data be 8-bit linear 0-center monophonic 8Khz.  This
is a low-end format, but compact and quite sufficient for speech and
sound effects.  It may not be directly supportable on all hardware, but
it should be straightforward for the OF Fcode driver to convert from
this format into one of the formats supported by the hardware.  Where
the existing text and proposal 295 would require that clients be
prepared to perform any of a potentially large number of kinds of data
conversions, this proposal would require that the OF Fcode be prepared
to perform only a single conversion - from the standard format to an
appropriate hardware-supported format.

In addition, it is difficult to imagine any real requirement for
recording.  Memory and programming effort spent on support for "read"
is simply wasted.

Changes:

In section 6, append to the introductory text:
	In order to provide for universal support of a common data
	format, by default the audio data passed to _write_ shall
	consist of 8-bit monophonic samples encoded as signed linear
	values, sampled at 8000 samples per second.

	Note 1:  Some implementations of "sound" nodes may need to
	convert this data into a form acceptable to the audio hardware
	being supported.  It is not anticipated that this is an
	unreasonable requirement.
	
	Note 2:  An implementation may choose to supply additional
	properties, methods, and "open" arguments so as to support
	more advanced audio capabilities, so long as a default "open"
	results in _write_ interpreting the standard format.

In section 6.1 ("sound" device standard properties), delete the
definitions of "#channels", "sample-resolution", "sample-width", and
"sample-rates".

In section 6.2, delete the definition of "read".
In section 6.2, replace the text for "open" with:
	This Standard method prepares the "sound" device for subsequent
	writes.
In section 6.2, in the definition of "write", delete
	The sample rate is established by open.

[ P1275 Item #296 -- Received: Mon Oct 23 17:33:35 PDT 1995 ]