Date: Thu, 07 Aug 1997 09:52:18 -0700 From: Amancio Hasty <hasty@rah.star-gate.com> To: Luigi Rizzo <luigi@labinfo.iet.unipi.it> Cc: multimedia@FreeBSD.ORG Subject: Re: [snddrv] proposal for ioctl change Message-ID: <199708071652.JAA04466@rah.star-gate.com> In-Reply-To: Your message of "Thu, 07 Aug 1997 16:55:06 %2B0200." <199708071455.QAA13987@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
Just take up with Hannu. By enlarge this group does not write any sound apps so Linux compatibility is very important Amancio >From The Desk Of Luigi Rizzo : > [foreword: I do not want to criticise the Voxware interface; there > is a reson why it is like it is. It's just that having rewritten the > sound driver from scratch gives me a good chance to cleanup the > interface...] > > I am revising the ioctl() interface in the sound driver. In the > voxware scheme, there are over 100 (yes one hundred) different > ioctls, plus about 30 aliases. The pcm interface alone has some 60 > calls and 20+ aliases. > > In most cases, there are several methods to specify the same actions > (most noticeably stereo). Moreover, often one has to issue several > calls (one to set speed; one to choose between signed, unsigned, > 8/16 bit, u/alaw/uncompressed...; another one to set stereo/mono) > to set the data format, and this is quite confusing both for the > programmer and the driver itself, since some combinations might only > make sense if specified all at once (e.g. some boards could do mono > faster than stereo, etc). > > > No wonder the current structure is quite messy, and I doubt the > programmer really knows how to use it in a sensible way. > > SO: > > I plan to work on a revised ioctl() interface, using only a handful of > calls for the pcm part, basically three pairs (get & set): > - one for the data format (all parameters in one call, including the > desired buffer size, measured in bytes or time) for each > supported channel (i.e. input, output, and if a board has more > independent channels, they will support all of them); > > - one to access the mixers (again, in one call one specifies > mixer, channel, volume, muting, active sources for play & rec...); > > - one (or little more) for timing-related issue, i.e. check how many > pending bytes are in the playout/record buffers, flush buffers, > record callbacks in case of mmapped buffers... > > I am inspiring to the nice work done on the meteor driver where, > at the beginning, there was a nice effort toward the reduction of > ioctls to set the board parameters. > > Are there objections or suggestions on the above ? > > In the process I will try to keep compatible with Voxware ioctls(), > (since I have already implemented many of them, it won't cost me much). > > 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?199708071652.JAA04466>