Date: Fri, 25 Jul 1997 02:34:03 -0500 (CDT) From: Tony Kimball <Anthony.Kimball@East.Sun.COM> To: brianc@pobox.com Cc: freebsd-multimedia@FreeBSD.ORG Subject: Re: sb16 request Message-ID: <199707250734.CAA03326@compound.east.sun.com> References: <19970724185907.39493@pobox.com> <199707242357.QAA16379@rah.star-gate.com> <19970725001344.59756@pobox.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707250734.CAA03326>