From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <73ab23d94e5572e651d06f5ced559ade@quanstro.net>
From: erik quanstrom <quanstro@quanstro.net>
Date: Thu, 13 Aug 2009 20:00:54 -0400
To: 9fans@9fans.net
In-Reply-To: <4A84A60C.9050201@orcasystems.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] audio standards -- too many to choose from
Topicbox-Message-UUID: 480e24de-ead5-11e9-9d60-3106f5b1d025

> However if you are instead suggesting that it will take time to support
> other formats other than signed 16-bit little-endian samples.  I have no
> problem with a driver developer initially starting there leaving it
> incomplete.  At least someone has the potential to add such support.

i don't believe i've expressed any preference for one
audio format over another.  all i've said, is that one format
is better than many.

>
> > it also will make the interfaces much bulkier because you have
> > to make accomidations for the quirks of n formats.
> >
> > you're right, there is a cost.  simple is expensive.
> >
> > - erik
> I don't see the complexity, the interface merely needs to allow device
> drivers to provide the information such as "I support x y z", the
> application can query a "features" file, select a format and write back
> through the interface configuring the hardware.  The interface need not
> have any predetermined knowledge of available formats.  The only issue
> would be for each device driver to agree to call the same format by the
> same name, "s8 s16le s24be".

i think you're ignoring the complexity.  suppose we wish to
support 10 formats.  suppose that i have devices that support
all 10 formats.  then there are 90 different conversions to do
to fill in the gaps.  now suppose that we pick a format.  then
we need to write 10 conversions.  also each driver potentially
needs 1 conversion.  if we want to write things like audio
mixers or whatnot in software, we only need to support 1 input
and 1 output format.

the expense is that this is going to cost cycles.  it may be
a little impractical, but computers are pretty fast these days.
i think it might just work.

this is exactly the same problem that unix finds itself in supporting
n character sets rather than translating on the way in.  it's really a
great example of optimizing your problem.  unix has unwitting made
an small problem unsolvable (at least well).  (cf. gnu grep.)

- erik