I experienced a curious problem. My platform is a S3C2410 with a PCM3006 codec connected through I2S. The soc trigger function calls 3 other triggers functions: - first the codec function - then the platform function (that starts dma) - last the the i2s trigger function (that starts i2s peripheral). The dma start function programs and starts the dma peripheral, but the transfer doesn't start because the i2s peripheral isn't started yet. The s3c2410 specific dma start programs the 1st transfer, but before programming the 2nd start it waits about 30ms (2^18 count) in a closed loop for 1st transfer to start. After that delay anyway it fails to program the 2nd transfer. After that, when the i2s trigger function is called the 1st samples' group starts, but nobody preprograms the 2nd sample group in the dma peripheral. When the 1st group ends the dma interrupt service routine is called , but it's too late and the 1st samples' group is repeated twice. I tested 2 solutions: - In the soc trigger function, call the i2s trigger function BEFORE the platform trigger function. I don't know if this solution could broke other platforms, but it's the more correct way to solve the problem. - (platform specific): In arch/arm/plat-s3c24xx-dma.c, at the end of s3c2410_dma_getposition() function, insert a call to s3c2410_dma_started(). That function is periodically called by alsa-lib when playing, and permits dma to program the 2nd buffer before (but it's not guaranteed) the 1st group is completed. With this solution, the programming of DMA till waits for the closed loop. I think this is a patch, but not the correct solution. I wonder if other architectures that use DMA suffer the same problem, so that the 1st proposed solution could help them, too. Davide