I dumped appl_ptr and slave_appl_ptr being sent to mix_areas - and the numbers flow around the ring buffer in a steady circle. Here are graphs of the data: http://www.caustik.com/alsa/scat-appl_ptr.gif http://www.caustik.com/alsa/scat-slave_appl_ptr.gif So it looks like those values are moving like they should. However, I do not know where to print the hardware pointer value. Where is that variable? Btw - I noticed that the kernel in core audio will manipulate some buffer pointers based on when the buffer is almost drained - is that relevant? caustik On 7/24/07, Takashi Iwai <tiwai@xxxxxxx> wrote: > > At Thu, 19 Jul 2007 12:59:32 -0700, > Aaron "Caustik" Robinson 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? > > It sounds unlikely a platform-specific problem but rather a problem of > the driver implementation. > > Note that the hw_ptr and appl_ptr tracked in pcm struct are within 0 > and (runtime->boundary_size - 1). It's not within 0 and > (buffer_size-1). So, basically it shouldn't overlap unless it goes > across the boundary close to long (32bit or more). > > > Takashi > > > > > 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 > > > _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
