alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Lars-Peter Clausen <lars@metafoo.de>
To: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: alsa-devel@alsa-project.org, Mark Brown <broonie@kernel.org>,
	Liam Girdwood <lgirdwood@gmail.com>
Subject: Re: [PATCH] ASoC: tlv320aic3x: Correct S24_3LE support
Date: Fri, 13 Dec 2013 14:42:32 +0100	[thread overview]
Message-ID: <52AB0EC8.5020802@metafoo.de> (raw)
In-Reply-To: <52AB0BBD.2020001@ti.com>

On 12/13/2013 02:29 PM, Peter Ujfalusi wrote:
> On 12/13/2013 03:04 PM, Mark Brown wrote:
>> On Fri, Dec 13, 2013 at 02:58:19PM +0200, Peter Ujfalusi wrote:
>>
>>> -	case SNDRV_PCM_FORMAT_S24_LE:
>>> +	case SNDRV_PCM_FORMAT_S24_3LE:
>>>  		data |= (0x02 << 4);
>>>  		break;
>>
>> This should be adding the case for the new format rather than replacing
>> the old one shouldn't it?  They ought to turn out the same on the AIF so
>> the CODECs shouldn't care about the difference, ideally the core would
>> hide the difference from them.
> 
> Not really since the codec has only field to specify the data format. The
> codec can not support S24_LE (S24_LE is basically S32_LE msbits==24) since we

S24_LE is a 24 bit sample in a 32 bit word, but it is right aligned, so
there are 8 bits of leading padding, while with S32_LE msbits=24 you'd have
8bits of trailing padding.

> can not say to the codec to ignore the 8bit over the 24 bits of real data.
> In case of S24_3LE the I2S bus will have 24 clocks/per channel which can not
> be used to stream S24_LE either.
> 

Normally you'd expect the I2S core to only put the 24 bits of data onto the
bus for both S24_3LE and S24_LE (it might add necessary trailing padding if
the bit clocks per frame is > 24). A CODEC driver should really not have to
care about the in memory layout of the data since all it will see is a
serialized bit stream. I think ideally we wouldn't check for params_format()
but rather for snd_pcm_format_width(params_format()).

- Lars

  parent reply	other threads:[~2013-12-13 13:41 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-13 12:58 [PATCH] ASoC: tlv320aic3x: Correct S24_3LE support Peter Ujfalusi
2013-12-13 13:04 ` Mark Brown
2013-12-13 13:29   ` Peter Ujfalusi
2013-12-13 13:34     ` Mark Brown
2013-12-13 13:41       ` Takashi Iwai
2013-12-13 13:50         ` Mark Brown
2013-12-13 13:57       ` Peter Ujfalusi
2013-12-13 14:18         ` Mark Brown
2013-12-13 14:31           ` Peter Ujfalusi
2013-12-13 18:29             ` Mark Brown
2013-12-13 13:42     ` Lars-Peter Clausen [this message]
2013-12-13 13:49       ` Mark Brown
  -- strict thread matches above, loose matches on Subject: below --
2014-06-06 13:05 Peter Ujfalusi
2014-06-09 20:24 ` Mark Brown
2014-06-23 13:01   ` Peter Ujfalusi
2014-06-23 15:18     ` Mark Brown
2014-06-24  6:23       ` Peter Ujfalusi
2014-06-24  9:18         ` 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=52AB0EC8.5020802@metafoo.de \
    --to=lars@metafoo.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=peter.ujfalusi@ti.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).