Re: [9fans] audio standards -- too many to choose from

[James Tomaschke <james@orcasystems.com>]

erik quanstrom wrote:
>>> My list was only there to try and prove the point that Russ has
>>> made -- pick a most common format and stick with it. Convert
>>> everything else into it.
>> By this logic, I need to have my application to convert CDROM-XA ADPCM
>> audio from a device into PCM just to talk to an interface, which in turn
>> must convert it back into ADPCM to play it back because the DMA
>> transfers to the audio hardware buffer require ADPCM.
>
> the problem with supporting everything the hardware will
> do is that it's quite expensive in terms of development time.
> and that is the scarce resource that needs to be optimized.
Creative Labs made an EMU10K1x chipset, the "x" means that it came with
no hardware mixer.  The software driver had to perform the mixing before
sending it to the hardware.  A device driver that only exposes what the
hardware has is much more simple than one that patches missing
functionality in the software driver.

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.

> 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".

To support multiple mix buffers or audio channels, the interface only
needs to iterate information provided by the driver.  Again, there is no
requirement that initial device driver development need support all
possible features.