On 01/17/2012 03:56 PM, Mark Brown wrote:
On Tue, Jan 17, 2012 at 03:18:35PM +0100, Peter Ujfalusi wrote:
It is mostly true. DAC33 can be configured to operate internally 16bit or 24msbit/32bit for example.
Well, if it's doing something more complicated that doesn't fit in the framework then it shouldn't be doing that.
What do you mean? If user plays 16bit audio we configure the codec in 16bit mode. If it is opened in 24msbit/32 mode it is configured accordingly.
It does not give any useful information for application that the codec will upsample the 16bit data internally to 24 bits. It does not really matter for them since all 16bit data will be used by the codec.
Oh, I dunno - I'm sure someone could think of a use for it.
Sure it might be good to know, but it is something we do not have control over. There's a datasheet if someone is interested. Even if you could select the algorithm for the in HW resampling it could be configured via kcontrol, or via qos. For application it does not matter.
True, the CPU side mostly passes the data as it is, it does not care about msbits. For McPDM it is different since the internal FIFO in 24bit long word lines, so if application would use all 32bit we it will loose
Right, like I say that's because it's got most of a DAC in it.
The McPDM does not have codec, the internal FIFO has this layout which dictates the 24msbit. It just cuts the 8lsb.
8bit lsb. This can make difference for PA when applying the digital gain in SW.
Well, it saves it a bit of effort but that's about it.
This is not a point. If it does it's internal digital volume on the full 32bit resolution from which the HW just discards 8bits we will loose resolution. If PA knows that out of the 32bit only the 24bit msbit is going to be used it can apply the gain correctly. If we tell PA that the codec internally works in 24bit, and we play 16bit audio (in 16bit mode) PA needs to apply the gain in 16bit resolution. The information about the codec working internally in 24bit irrelevant.