Looking at snd_pcm_dmix_sync_area - if I dump all of the raw pcm data going into the "mix_areas" function call - the data is correct. However, by the time the data gets to the driver it is corrupted. Where does the data go between mix_areas and the driver? I can't seem to track down where next to check the data.
On 7/19/07, Aaron Caustik Robinson caustik@gmail.com wrote:
We have found that the problem exists because, at certain points in time, the hardware pointer and application pointer overlap. Basically the hardware is reading from the period buffer which is currently being written to. How might this be platform specific? Is there any debugging technique you think may help find the root cause?
On 7/10/07, Jaroslav Kysela perex@suse.cz wrote:
On Tue, 10 Jul 2007, Aaron "Caustik" Robinson wrote:
This is on an embedded ARM device, with a custom driver. That's interesting. I never thought about the cache angle. Is there any sort
of
hack I can put to check if that is the problem?
The cache flush method is quite CPU specific, you have to check datasheet. But it's only guess and the problem might be somewhere else. I would compare samples DMA ring buffer in the user space and kernel space again. Also, put a debug lines to dmix plugin to detect where are samples written (to which pointer/area in the DMA ring buffer). dmix assumes that playback is running forever and tries to mix data in actual ring buffer position.
Jaroslav
Jaroslav Kysela perex@suse.cz Linux Kernel Sound Maintainer ALSA Project, SUSE Labs