From: Peter Ujfalusi <peter.ujfalusi@ti.com>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: alsa-devel@alsa-project.org, patches@opensource.wolfsonmicro.com,
Liam Girdwood <lrg@ti.com>
Subject: Re: [PATCH 1/2] ASoC: Allow drivers to specify how many bits are significant on a DAI
Date: Tue, 17 Jan 2012 15:18:35 +0100 [thread overview]
Message-ID: <4F15833B.2000808@ti.com> (raw)
In-Reply-To: <20120117131950.GF2944@opensource.wolfsonmicro.com>
On 01/17/2012 02:19 PM, Mark Brown wrote:
> For the CODECs if you look at what they're doing you'll probably find
> that the device is actually operating at a fixed sample size internally
> and converting the data somehow at the interface (zero extension being
> one option when converting up, but more fancy approaches are also
> possible). This is fairly obvious when you think about how things are
> likely to be implemented in hardware, it's going to increase complexity
> a lot to be able to genuinely switch the entire chip from one sample
> size to another.
It is mostly true. DAC33 can be configured to operate internally 16bit
or 24msbit/32bit for example.
But none of this matters really for application. If the codec works
internally with 32/64 or whatever, it does not matter for the
application. What matters is that if it sends data in 32bit only 24msb
will be actually going to be taken, and the rest will be ignored at the
interface level. What happens within the codec is out of the scope.
Applications like PulseAudio can do digital volume control. For them it
is important to know if they can operate on the full 32 bit, or only the
24msbit will be taken into account by the HW at interface level.
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.
> On the CPU side specifying significant bits would normally only be
> appropriate on PDM interfaces as they have most of a DAC or ADC in them
> to move between the sampled and PDM formats. I'd be surprised to see
> anything else setting these flags, most of the hardware is just passing
> the data straight through.
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
8bit lsb. This can make difference for PA when applying the digital gain
in SW.
--
Péter
next prev parent reply other threads:[~2012-01-17 14:18 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-16 18:41 [PATCH 1/2] ASoC: Allow drivers to specify how many bits are significant on a DAI Mark Brown
2012-01-16 18:41 ` [PATCH 2/2] ASoC: 24 bits are significant on the WM8996 audio interfaces Mark Brown
2012-01-16 22:26 ` [PATCH 1/2] ASoC: Allow drivers to specify how many bits are significant on a DAI Girdwood, Liam
2012-01-16 22:42 ` Mark Brown
2012-01-17 8:56 ` Peter Ujfalusi
2012-01-17 8:55 ` Peter Ujfalusi
2012-01-17 11:38 ` Mark Brown
2012-01-17 13:06 ` Peter Ujfalusi
2012-01-17 13:19 ` Mark Brown
2012-01-17 14:18 ` Peter Ujfalusi [this message]
2012-01-17 14:56 ` Mark Brown
2012-01-17 16:08 ` Peter Ujfalusi
2012-01-17 16:44 ` Mark Brown
2012-01-17 17:55 ` Peter Ujfalusi
2012-01-17 18:17 ` Mark Brown
2012-01-17 18:51 ` Peter Ujfalusi
2012-01-17 18:59 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F15833B.2000808@ti.com \
--to=peter.ujfalusi@ti.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=lrg@ti.com \
--cc=patches@opensource.wolfsonmicro.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).