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@xxxxxxxxx> 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@xxxxxxx> 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@xxxxxxx> > > Linux Kernel Sound Maintainer > > ALSA Project, SUSE Labs > > > > _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
