erik quanstrom wrote: >> 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. It's a matter of kernelspace vs userspace and freedom.
Nothing I have proposed prevents you from using a single format. Nothing I have proposed requires you to implement N formats or conversions. This is because I allow for your freedom to do so in userspace. Rather, your suggestion of forcing a single format, prevents my applications from using other formats, and it requires I implement conversions. This is because you limit freedom by placing a simple interface into kernelspace. If you desire a simple audio server to glue simple audio applications it can be done in userspace, a |filter program can be used by an audio server on top of the device driver. The scope of the complexity of which is completely up to you.
