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?
you're missing the point, I guess I'm not clear. internally, audio would use 32 bits. that is the sample size. so when you query it with audioctl, it'll say it's using 32-bit, but really you are using 24-bit. we just need a clever way to distinguish this without causing a "flag day" API/ABI change in all the drivers/apps, etc. -- [email protected] SDF Public Access UNIX System - http://sdf.lonestar.org
