From owner-freebsd-multimedia  Fri Jul 25 00:34:46 1997
Return-Path: <owner-freebsd-multimedia>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id AAA19728
          for multimedia-outgoing; Fri, 25 Jul 1997 00:34:46 -0700 (PDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
          by hub.freebsd.org (8.8.5/8.8.5) with SMTP id AAA19722
          for <freebsd-multimedia@FreeBSD.ORG>; Fri, 25 Jul 1997 00:34:43 -0700 (PDT)
Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id AAA00874; Fri, 25 Jul 1997 00:34:10 -0700
Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3)
	id DAA27872; Fri, 25 Jul 1997 03:34:09 -0400
Received: from compound.east.sun.com by suneast.East.Sun.COM (SMI-8.6/SMI-SVR4)
	id DAA16080; Fri, 25 Jul 1997 03:34:09 -0400
Received: (from alk@localhost) by compound.east.sun.com (8.8.6/8.7.3) id CAA03326; Fri, 25 Jul 1997 02:34:03 -0500 (CDT)
Date: Fri, 25 Jul 1997 02:34:03 -0500 (CDT)
Reply-To: Anthony.Kimball@East.Sun.COM
Message-Id: <199707250734.CAA03326@compound.east.sun.com>
From: Tony Kimball <Anthony.Kimball@East.Sun.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: brianc@pobox.com
Cc: freebsd-multimedia@FreeBSD.ORG
Subject: Re: sb16 request
References: <19970724185907.39493@pobox.com>
	<199707242357.QAA16379@rah.star-gate.com>
	<19970725001344.59756@pobox.com>
X-Face: O9M"E%K;(f-Go/XDxL+pCxI5<W_e*r7B8ojMD.5+qDgOp4/\gTQEgbOoBqf:Vtl*aW:<;9/
	UIVk'U^XhYg+v#r~*X<$Q=_ik@5:%E}pl]9|9|:]WLW8n:fLgg0~cfwWRBQxK/HSG0b1D/gljJC$qp
	b=HDF@+"H<|fXy`w#$8#6A"!F:>*gr[=FN@Y`cl1.Tn
Sender: owner-freebsd-multimedia@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Quoth Brian Campbell on Fri, 25 July:
: ...However, in the case of the SB16, the ioctl would have to
: fail.  Or claim success and not actually change the sample size of
: either the record/playback channel.  The question would then be,
: which channel actually got changed?

I would prefer, as Randall Hopper's post suggested, to think of the
ioctl as changing the data stream from 8-bit to 16-bit.  Let the
driver interface abstract away from the hardware.  When only 8-bit is
supported in hardware, extend it.  When only 16-bit is supported in
hardware, round it.

When two descriptors are being used, there is no ambiguity, and
the programmer has perfect control.  If Luigi does produce a driver
which supports two descriptors, this resolves the problem of
which channel to allocate, for the programmer can issue the ioctls
to each descriptor independently.

I think the only way to provide the ability to control the allocation,
i.e. to change it from default, in the single-descriptor interface is
to extend the interface.  That would be nice, but I think that having
a duplex capability is the first step: I shan't worry about getting
desert until the entre is on the table.