diff mbox

[alsa-devel] Please help in adding ams-delta support to ASoC

Message ID 200906091012.41800.peter.ujfalusi@nokia.com (mailing list archive)
State Awaiting Upstream, archived
Headers show

Commit Message

Peter Ujfalusi June 9, 2009, 7:12 a.m. UTC
Hello Janusz,

On Saturday 06 June 2009 20:42:12 ext Janusz Krzysztofik wrote:
> I'm not sure how that could happen, but I was wrong with some of those
> figures. After looking at the scope several more times I can only confirm
> that master clock really runs at 2MHz (0,5µs period). Frame sync is rather
> closer to 8kHz (~125µs period) than previously estimated 10kHz, with the
> same symmetric (50% fill) shape as before. But bit clock is very different
> from what I have seen before. It runs at 2MHz in 9µs long packets (18
> periods), those are repeated every half period of frame sync (~62µs /
> 16kHz), ie every frame sync edge, both rising and falling. There is also a
> signal present on codec data output: 4µs long packets (8 bits each?) every
> ~62µs (16 kHz).

I'm kind of bad at visualizing things, is it possible to put somewhere the 
screenshoot of the scope showing at least one sample?

>
> Is it possible that the codec speeks I2S, with 8-bit word, 1 word per
> frame, 2 channels at 8kHz each? Or 1 channel at 16 kHz? From what I can
> read in modem documentation, this should rather be one 8-bit channel at
> 8kHz. Anyway, can the transmission format I have seen ont the oscilloscope
> be matched against any format that mcbsp can be set with current code?

I have been looking for clues around the net, and it seams that the codec in 
question has stereo 16 bit format.

>
> I'm still far from understanding mcbsp, but I wonder what happens if the
> bit clock stops ater 18th bit while maybe mcbsp expects more. Perhaps this
> is the cause of dma interrupts not being generated?
>

Without actual OMAP1510 HW it is really hard to tell what can be the problem.
What I would do, if I had a HW:
1) See if the DMA actually was running and it is 'just' about the missing 
interrupt:
                break;


Than start a playback, and stop it with CTRL+C, see if the two pointers are 
different...

2) I would I think try to port the 2.6.28 pure ALSA version to the head of l-
o, with minimal (only the needed) changes and see if it is still working.
I know, this is a long shot, but at least we can be sure, that the problem is 
in the ASoC McBSP/DMA integration or it is something else.

Meanwhile I'll try to locate one OMAP1510 based board to try to help with this 
issue.

Comments

Janusz Krzysztofik June 9, 2009, 3:17 p.m. UTC | #1
Peter Ujfalusi wrote:
> I'm kind of bad at visualizing things, is it possible to put somewhere the 
> screenshoot of the scope showing at least one sample?

Good idea. I'll take some screenshots for future reference and let you 
know when available.

> I have been looking for clues around the net, and it seams that the codec in 
> question has stereo 16 bit format.

 From the very minimal mcbsp setup I get best audio experience with 
(using original omap-alsa based driver - see below), it looks like the 
codec speeks DSP (single phase), 16-bit mono @8kHz on output, but 8-bit 
stereo @8kHz on input. Capturing one channel only (the first one) I 
can't hear myself speaking, so audio from the microphone must be sent 
over the second input channel.

+static struct omap_mcbsp_reg_cfg mcbsp_regs = {
+       .spcr2 = FREE | XINTM(3) | XRST,
+       .spcr1 = RINTM(3) | RRST,
+       .rcr1 = RFRLEN1(2 - 1) | RWDLEN1(OMAP_MCBSP_WORD_8),
+       .xcr1 = XFRLEN1(1 - 1) | XWDLEN1(OMAP_MCBSP_WORD_16),
+};


+static snd_pcm_hardware_t vc_snd_omap_alsa_playback = {
+       .info = (SNDRV_PCM_INFO_INTERLEAVED | 
SNDRV_PCM_INFO_BLOCK_TRANSFER |
+                SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID),
+       .formats = (SNDRV_PCM_FMTBIT_S16_LE),
+       .rates = (SNDRV_PCM_RATE_8000 |
+                 SNDRV_PCM_RATE_KNOT),
+       .rate_min = 8000,
+       .rate_max = 8000,
+       .channels_min = 1,
+       .channels_max = 1,
+       .buffer_bytes_max = 128 * 1024,
+       .period_bytes_min = 32,
+       .period_bytes_max = 8 * 1024,
+       .periods_min = 16,
+       .periods_max = 255,
+       .fifo_size = 0,
+};
+
+static snd_pcm_hardware_t vc_snd_omap_alsa_capture = {
+       .info = (SNDRV_PCM_INFO_INTERLEAVED | 
SNDRV_PCM_INFO_BLOCK_TRANSFER |
+                SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID),
+       .formats = (SNDRV_PCM_FMTBIT_U8),
+       .rates = (SNDRV_PCM_RATE_8000 |
+                 SNDRV_PCM_RATE_KNOT),
+       .rate_min = 8000,
+       .rate_max = 8000,
+       .channels_min = 2,
+       .channels_max = 2,
+       .buffer_bytes_max = 128 * 1024,
+       .period_bytes_min = 32,
+       .period_bytes_max = 8 * 1024,
+       .periods_min = 16,
+       .periods_max = 255,
+       .fifo_size = 0,
+};

For other combinations of single/dual phase, sample size, mono/stereo, 
sound I get is much more distorted. Playing with polarisation and delays 
for getting still better experience remains on my todo list.

BTW, I can't see any way of specifying a similiar mcbsp setup in new 
omap asoc framework.

--------------
> --- a/sound/soc/omap/omap-pcm.c
> +++ b/sound/soc/omap/omap-pcm.c
> @@ -193,11 +193,15 @@ static int omap_pcm_trigger(struct snd_pcm_substream 
> *substream, int cmd)
>         case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
>                 prtd->period_index = 0;
>                 omap_start_dma(prtd->dma_ch);
> +               printk("omap_pcm_trigger START: DMA pointer at 0x%08x\n",
> +                       (unsigned)omap_get_dma_src_pos(prtd->dma_ch));
>                 break;
> 
>         case SNDRV_PCM_TRIGGER_STOP:
>         case SNDRV_PCM_TRIGGER_SUSPEND:
>         case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
> +               printk("omap_pcm_trigger STOP: DMA pointer at 0x%08x\n",
> +                       (unsigned)omap_get_dma_src_pos(prtd->dma_ch));
>                 prtd->period_index = -1;
>                 omap_stop_dma(prtd->dma_ch);
>                 break;
> 
> 
> Than start a playback, and stop it with CTRL+C, see if the two pointers are 
> different...

Both playback and capture start with their own but always the same value 
(something like 0x1101a0d0 for playback, 0xe101a0d0 for capture), and 
always stop with this value unchanged.

> 2) I would I think try to port the 2.6.28 pure ALSA version to the head of l-
> o, with minimal (only the needed) changes and see if it is still working.

Trying to use the new driver on the last l-o revision supporting both 
omap-alsa and omap asoc, I got a broken system that hanged up completely 
at sound device first access. The same for earlier and later l-o 
revisions I have ever tried, unlike mainline that at least does not 
hang. From all that I would conclude that porting the old driver could 
be just waste of time, as the problem is probably omap asoc related, not 
just omap, probably existed from the start of omap asoc life, and could 
be solved on any l-o or mainline revision, including those eariler l-o 
that supported both frameworks. But I can be wrong, of course.

Cheers,
Janusz
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Janusz Krzysztofik June 10, 2009, 2:20 p.m. UTC | #2
Janusz Krzysztofik wrote:
> Peter Ujfalusi wrote:
>> I'm kind of bad at visualizing things, is it possible to put somewhere 
>> the screenshoot of the scope showing at least one sample?
> 
> Good idea. I'll take some screenshots for future reference and let you 
> know when available.

Hi,

Some screenshots are available at http://www.icnet.pl/download/cx20442/

Cheers,
Janusz

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

--- a/sound/soc/omap/omap-pcm.c
+++ b/sound/soc/omap/omap-pcm.c
@@ -193,11 +193,15 @@  static int omap_pcm_trigger(struct snd_pcm_substream 
*substream, int cmd)
        case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
                prtd->period_index = 0;
                omap_start_dma(prtd->dma_ch);
+               printk("omap_pcm_trigger START: DMA pointer at 0x%08x\n",
+                       (unsigned)omap_get_dma_src_pos(prtd->dma_ch));
                break;

        case SNDRV_PCM_TRIGGER_STOP:
        case SNDRV_PCM_TRIGGER_SUSPEND:
        case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
+               printk("omap_pcm_trigger STOP: DMA pointer at 0x%08x\n",
+                       (unsigned)omap_get_dma_src_pos(prtd->dma_ch));
                prtd->period_index = -1;
                omap_stop_dma(prtd->dma_ch);