[vorbis-dev] Re: [vorbis] ao changes

[Kenneth Arnold]

On Sun, Aug 26, 2001 at 08:13:35PM -0700, volsung at asu.edu wrote:
> According to the very spartan design principle that a library (or program)
> should do only one thing and do it well, file output really doesn't belong in
> libao at all.  As Segher pointed out to me at one point (and correctly so),
> libaudiofile handle the audio file output problem better and much more
> completely than libao ever will.  One could rightly say that I should just
> chuck ao_open_file() entirely and tell everyone to use libaudiofile, which is
> available everywhere libao currently runs.
> 
> I bring this up because it highlights the quandary of file output in
> libao.  File output exists in libao because it is convenient, not because it
> "belongs" in the library.  Any API encompassing both will feel a little
> kludgy, so I don't pretend that the current API is ideal.

libao is actually very nice as a library -- it doesn't try to
reimplement a reinvented library structure with the huge numbers of
types, constants, options, parameters, etc. like I've seen many other
libraries and APIs do, but instead just gives you one little function,
ao_play, to do what you want, and a few other functions to set it all
up. Having file output integrated into this simple framework makes it
even easier for the end-user application writer to get audio output
functionality easily. Indeed the library is named liba[udio]o[utput],
which makes file output seem natural. Granted, it would take a lot of
work to bring libao to the generality necessary to fully implement
audio file output and would likely require sacrificing the simplicity
of the existing interface, and for what one usually needs to do with
an output audio file, libao already does it well.

> The old API was designed around the principle that any output driver *could*
> potentially be used with no options (in the ao_option sense) provided.  
> Options are for "tweaking knobs" inside the driver and should all have a
> sensible default value.  In the case of file output drivers--which in the old
> API were opened with the same function as live output drivers--this meant that
> the output filename had to be passed as an ao_option, and therefore had to
> have a default value (like "output.wav").

How about the default file extension we discussed earlier?

thx,


-- 
Kenneth Arnold <ken at arnoldnet.net> / kcarnold / Linux user #180115
http://arnoldnet.net/~kcarnold/



<HR NOSHADE>
<UL>
<LI>application/pgp-signature attachment: stored
</UL>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: part
Type: application/octet-stream
Size: 233 bytes
Desc: not available
Url : http://lists.xiph.org/pipermail/vorbis-dev/attachments/20010827/4746405d/part.obj