[alsa-devel] WM9712 - Big and little endian format conversion.
I have three areas specifying audio formats. The WM9712 AC97 codec is S16_LE. My DMA hardware is S32_BE. All samples need to be in 32b words even if they are 8,16,24b. The cpu's AC97 system sends the first 20 big endian bits down the AC97 link in the proper order.
How can I force the DMA engine setting to override what the codec is saying? Or should the codec be changed to specify all bit lengths and both endians?
My DMA platform:
static const struct snd_pcm_hardware psc_dma_hardware = { .info = SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID | SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_BLOCK_TRANSFER | SNDRV_PCM_INFO_BATCH, .formats = SNDRV_PCM_FMTBIT_S32_BE, .rate_min = 8000, .rate_max = 48000, .channels_min = 1, .channels_max = 2, .period_bytes_max = 1024 * 1024, .period_bytes_min = 32, .periods_min = 2, .periods_max = 256, .buffer_bytes_max = 2 * 1024 * 1024, .fifo_size = 512, };
CPU DAI: static struct snd_soc_dai psc_ac97_dai_template[] = { { .name = "%s analog", .suspend = psc_ac97_suspend, .resume = psc_ac97_resume, .playback = { .channels_min = 1, .channels_max = 6, .rates = SNDRV_PCM_RATE_8000_48000, .formats = SNDRV_PCM_FMTBIT_S8 | SNDRV_PCM_FMTBIT_S16_BE | SNDRV_PCM_FMTBIT_S24_BE | SNDRV_PCM_FMTBIT_S32_BE, }, .capture = { .channels_min = 1, .channels_max = 2, .rates = SNDRV_PCM_RATE_8000_48000, .formats = SNDRV_PCM_FMTBIT_S8 | SNDRV_PCM_FMTBIT_S16_BE | SNDRV_PCM_FMTBIT_S24_BE | SNDRV_PCM_FMTBIT_S32_BE, }, .ops = &psc_ac97_analog_ops, },
Codec:
struct snd_soc_dai wm9712_dai[] = { { .name = "AC97 HiFi", .ac97_control = 1, .playback = { .stream_name = "HiFi Playback", .channels_min = 1, .channels_max = 2, .rates = WM9712_AC97_RATES, .formats = SNDRV_PCM_FMTBIT_S16_LE, }, .capture = { .stream_name = "HiFi Capture", .channels_min = 1, .channels_max = 2, .rates = WM9712_AC97_RATES, .formats = SNDRV_PCM_FMTBIT_S16_LE, }, .ops = &wm9712_dai_ops_hifi, }, {
On Wed, May 13, 2009 at 01:55:43PM -0400, Jon Smirl wrote:
I have three areas specifying audio formats. The WM9712 AC97 codec is S16_LE. My DMA hardware is S32_BE. All samples need to be in 32b words even if they are 8,16,24b. The cpu's AC97 system sends the first 20 big endian bits down the AC97 link in the proper order.
How can I force the DMA engine setting to override what the codec is saying? Or should the codec be changed to specify all bit lengths and both endians?
In this specific case there's now a standard define for the AC97 codecs to use for the formats in current ASoC, add all the formats supported by your CPU to that and all the AC97 codecs will pick it up automatically. It's called SND_SOC_STD_AC97_FMTS, defined in the DAI header file.
On Wed, May 13, 2009 at 1:59 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Wed, May 13, 2009 at 01:55:43PM -0400, Jon Smirl wrote:
I have three areas specifying audio formats. The WM9712 AC97 codec is S16_LE. My DMA hardware is S32_BE. All samples need to be in 32b words even if they are 8,16,24b. The cpu's AC97 system sends the first 20 big endian bits down the AC97 link in the proper order.
How can I force the DMA engine setting to override what the codec is saying? Or should the codec be changed to specify all bit lengths and both endians?
In this specific case there's now a standard define for the AC97 codecs to use for the formats in current ASoC, add all the formats supported by your CPU to that and all the AC97 codecs will pick it up automatically. It's called SND_SOC_STD_AC97_FMTS, defined in the DAI header file.
Which tree is this in?
On Wed, May 13, 2009 at 2:08 PM, Jon Smirl jonsmirl@gmail.com wrote:
On Wed, May 13, 2009 at 1:59 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Wed, May 13, 2009 at 01:55:43PM -0400, Jon Smirl wrote:
I have three areas specifying audio formats. The WM9712 AC97 codec is S16_LE. My DMA hardware is S32_BE. All samples need to be in 32b words even if they are 8,16,24b. The cpu's AC97 system sends the first 20 big endian bits down the AC97 link in the proper order.
How can I force the DMA engine setting to override what the codec is saying? Or should the codec be changed to specify all bit lengths and both endians?
In this specific case there's now a standard define for the AC97 codecs to use for the formats in current ASoC, add all the formats supported by your CPU to that and all the AC97 codecs will pick it up automatically. It's called SND_SOC_STD_AC97_FMTS, defined in the DAI header file.
Which tree is this in?
I found it in broonie/for-2.6.31 I rebased my series on to that branch
-- Jon Smirl jonsmirl@gmail.com
On Wed, May 13, 2009 at 02:08:19PM -0400, Jon Smirl wrote:
On Wed, May 13, 2009 at 1:59 PM, Mark Brown
In this specific case there's now a standard define for the AC97 codecs to use for the formats in current ASoC, add all the formats supported by your CPU to that and all the AC97 codecs will pick it up automatically. It's called SND_SOC_STD_AC97_FMTS, defined in the DAI header file.
Which tree is this in?
It's in -next now so it can be seen in Takashi's tree and mine as well - it's commit 33f503c96c976fd585dedb76514ca6cb286e60d9.
On Wed, May 13, 2009 at 2:14 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Wed, May 13, 2009 at 02:08:19PM -0400, Jon Smirl wrote:
On Wed, May 13, 2009 at 1:59 PM, Mark Brown
In this specific case there's now a standard define for the AC97 codecs to use for the formats in current ASoC, add all the formats supported by your CPU to that and all the AC97 codecs will pick it up automatically. It's called SND_SOC_STD_AC97_FMTS, defined in the DAI header file.
Which tree is this in?
It's in -next now so it can be seen in Takashi's tree and mine as well
- it's commit 33f503c96c976fd585dedb76514ca6cb286e60d9.
Adding S32_BE works for me:
#define SND_SOC_STD_AC97_FMTS (SNDRV_PCM_FMTBIT_S16_LE |\ SNDRV_PCM_FMTBIT_S32_LE |\ SNDRV_PCM_FMTBIT_S32_BE)
On Wed, May 13, 2009 at 2:18 PM, Jon Smirl jonsmirl@gmail.com wrote:
On Wed, May 13, 2009 at 2:14 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Wed, May 13, 2009 at 02:08:19PM -0400, Jon Smirl wrote:
On Wed, May 13, 2009 at 1:59 PM, Mark Brown
In this specific case there's now a standard define for the AC97 codecs to use for the formats in current ASoC, add all the formats supported by your CPU to that and all the AC97 codecs will pick it up automatically. It's called SND_SOC_STD_AC97_FMTS, defined in the DAI header file.
Which tree is this in?
It's in -next now so it can be seen in Takashi's tree and mine as well
- it's commit 33f503c96c976fd585dedb76514ca6cb286e60d9.
Adding S32_BE works for me:
#define SND_SOC_STD_AC97_FMTS (SNDRV_PCM_FMTBIT_S16_LE |\ SNDRV_PCM_FMTBIT_S32_LE |\ SNDRV_PCM_FMTBIT_S32_BE)
Would it work to just put every format here and let the format be controlled by the platform and CPU DAI?
On Wed, May 13, 2009 at 02:20:46PM -0400, Jon Smirl wrote:
On Wed, May 13, 2009 at 2:18 PM, Jon Smirl jonsmirl@gmail.com wrote:
Adding S32_BE works for me:
#define SND_SOC_STD_AC97_FMTS (SNDRV_PCM_FMTBIT_S16_LE |\ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SNDRV_PCM_FMTBIT_S32_LE |\ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SNDRV_PCM_FMTBIT_S32_BE)
Would it work to just put every format here and let the format be controlled by the platform and CPU DAI?
Not quite - there's a bunch of things like the S/PDIF stuff which will almost certainly not do anything constructive in one of the generic AC97 slots without the CODEC and/or CPU doing magic to them. Also note that the core now fixes up CODEC formats on registration so both _BE and _LE variants always get set if one is set. That means that for preference I'd use the _LE variants here since it's what all the existing CODEC drivers are doing.
We should probably also squash all the 20 and 24 bit variants together, I need to go and check that there's nothing that'll get confused by that.
participants (2)
-
Jon Smirl -
Mark Brown