> 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
