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: --- 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...
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.