On Sun, Dec 14, 2008 at 10:53:57PM +0000, Dieter wrote: > > > > Something of an idle question: According to audioctl, my azalia > > > > device only supports 16-bit audio, but according to the data sheet > > > > the codec also offers 20- and 24-bit audio. Are there any plans > > > > to add support for this? > > > > > > > > No, I have no idea what you would actually use this for. In particular, > > > > I doubt that the analog inputs and outputs offer anywhere near that > > > > dynamic range. Still, you'd think the codec designers included these > > > > capabilities for a reason. > > > > > > we could support 24-bit but there are bigger fish to fry, imo. > > > > hmm, this is even trickier than I thought. > > > > the problem is 20 and 24-bit formats are actually 20 and 24 bits > > of data in a 32 bit sample. internally audio(4) uses "precision" > > as the exact sample size. so, we have to distinguish between > > "padded" and non-padded formats in audio(4) first. > > > > btw, 32-bit formats should already be supported, afaics. they > > aren't "padded". > > Could one pretend that 20 and 24 bits are 32 bits with the lower bits > zero?
yeah, that's what envy(4) does. It works if the bits are MSB aligned, afaik most devices do that. A better approach would be to claim that ``precision'' is the number of significant bits and that the sample size is the smallest power of two that can hold ``precision'' bits. I don't think that what all apps expect, so for now only 8, 16, and 32 are reliable in the sun api. -- Alexandre
