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.
-- Péter_______________________________________________Alsa-devel mailing listAlsa-devel@xxxxxxxxxxxxxxxxxxxx://mailman.alsa-project.org/mailman/listinfo/alsa-devel
